Atlassian Data Center

For: tenant administrators and plugin users.

Connect Jira and Confluence Data Center with tools generated from Atlassian's OpenAPI documents and authenticated through your tenant's application links. Jira webhooks become events in Orchestrator Zero.

An Orchestrator Zero connector for Jira and Confluence that a tenant runs itself. Atlassian's Rovo MCP server is for Atlassian Cloud only (use atlassian there), so this connector is our own: oz0 plugin import openapi wrote its two tools from the REST API documents Atlassian publishes, and import.sh writes them again.

Read 2026-10-17, with https://confluence.atlassian.com/adminjiraserver/jira-oauth-2-0-provider-api-1115659070.html (OAuth 2.0 for incoming application links) and https://confluence.atlassian.com/adminjiraserver/managing-webhooks-938846912.html (webhook secrets).

Functions

Each write asks a person by default through the plugin's suggested policy. An admin can switch that policy with a reason.

• Jira writes: create_issue, edit_issue, assign_issue, add_comment, update_comment, transition_issue, add_watcher and link_issues.
• Confluence writes: create_content (a page, blog post or comment), update_content and add_labels.
• Jira reads: search_issues (JQL), get_issue, get_comments, get_comment, get_transitions, get_issue_watchers, get_all_projects, get_project, get_create_issue_meta_project_issue_types, get_create_issue_meta_fields, get_edit_issue_meta, get_issue_link_types, get_myself, find_users, find_assignable_users, get_priorities, get_statuses, get_resolutions and get_server_info.
• Confluence reads: search_content (CQL), search_site, list_content, get_content, list_children, list_comments, list_attachments, list_descendants, get_history, list_labels, list_watchers, list_spaces, get_space, list_space_content and get_current_user.

The rest of both APIs, about 400 operations including administration, is not imported.

Each result is the HTTP status and Jira's or Confluence's answer as {status, body}.

Connect it

Each product is a connection of its own, atlassian-dc-jira and atlassian-dc-confluence, with the host it is served at. Two ways to sign in:

An incoming application link (OAuth 2.0, the default). In Jira (or Confluence): Administration, Applications, Application links, Create link, External application, Incoming. Give it the redirect URL that oz0 connection start atlassian-dc-jira shows and the permission Write. Then:

oz0 connection set atlassian-dc-jira --param host=jira.example.com --param client_id=<the link's client ID>
oz0 connection start atlassian-dc-jira   # paste the link's client secret, then sign in to Jira

The edge sends the client secret only to that host, keeps the token and refreshes it before it expires (Jira's last two hours, and each refresh replaces both tokens). Each call acts as the person who signed in.

A personal access token (the fallback). Where an application link is not possible:

oz0 connection set atlassian-dc-jira --param host=jira.example.com --param auth=token
oz0 connection start atlassian-dc-jira   # paste Jira's URL and a token of the account the connector acts as

The calls go only to the instance the connection was connected for; a changed host needs it connected again.

On a private network. Before each call the node resolves the instance's host and connects only to the addresses it checked. An instance on the company's network (a private address, as most Data Center instances are) is reached only once the tenant's egress allowlist names it:

oz0 tenant egress <tenant> <the entries listed now> jira.example.com confluence.example.com

An address of the node itself, its link or a cloud's metadata service is never reached by name; only an allowlist entry that names the address reaches it. A change of the allowlist reaches the connector's running tools by itself: no restart is needed.

Events. In Jira: System, WebHooks, Create a WebHook, with the URL https://<edge>/events/<tenant>/atlassian-dc-jira, the events you need (issue created, updated, deleted; comment created, updated, deleted) and a secret, which the tenant sets too, as a signing key bound to the edge's address: oz0 secret set ATLASSIAN_DC_JIRA_WEBHOOK_SECRET --signing --host <edge>:7443. The edge checks each delivery's X-Hub-Signature (sha256= and an HMAC-SHA256 of its body) before any node sees it. The events are issue and comment, with created, updated or deleted, and the issue's key as the subject.

Develop

uv lock && uv sync
uv run pytest                 # the imported servers against a fake of Jira and Confluence, the events, the import
OZ0_BIN=oz0 ./import.sh        # write the tools again from Atlassian's documents (checked by their SHA-256)
oz0 plugin pack . --list-tools # measure the listing again after a change, then oz0 plugin lint --verified .

Limits

• Every write asks a person by default; an admin who switches a write to Allow takes on what follows. Jira and Confluence take no idempotency key: a retried add_comment comments twice, and a retried create_issue creates two issues. A transition made twice is one change. So no write says it honours a key, and the platform makes each write once.
• A call over the instance's rate limit (HTTP 429) is not made again by the tool: the agent reads an error that says it is retryable and how long the instance asks to wait (its Retry-After).
• The AI label: add_comment's and update_comment's text, the description create_issue, edit_issue and transition_issue set, and create_content's and update_content's body start with the tenant's label in brackets, such as [AI agent], after the approval. Jira shows it as written in its wiki markup, Confluence as text before the page's first element. A description given as anything but text is refused, since it cannot carry the label.
  The label goes in one place per function: an issue's summary (its title) and other fields an edit or a transition sets carry none, and the person who approves the call sees them as they will be posted.
  assign_issue, add_watcher, link_issues and add_labels set a person, a link or label names, not text. With the tenant's label turned off, everything is posted as written.
• The host: Jira and Confluence must be served at the root of their host (https://jira.example.com/). An instance at a context path (https://example.com/jira) works with a personal access token, whose URL is pasted whole, but not with the application link's sign-in.
• Egress: the connector has no host of its own. Before each call the node resolves the connected instance's host and connects only to the addresses it checked. A public address is reached as it is; a private one (a company's own network) only once the tenant's egress allowlist names the instance (oz0 tenant egress); an address of the node itself, its link or a cloud's metadata service only when the allowlist names that address.
  On a node with sandbox tier 1 its tools run in the node's sandbox, whose egress proxy reaches the instance once its host is on the tenant's egress allowlist.
• Atlassian's documents describe answers loosely, so a result is not checked against them: it is the status and the body as Jira or Confluence sent it, up to 1 MiB.
• Two functions are larger than a model's usual tool definition, as Atlassian's documents describe their bodies: atlassian_dc_confluence.update_content (about 1,800 tokens) and atlassian_dc_jira.link_issues (about 1,750). The plugin's 46 functions come to about 18,500 tokens; an agent lists only the functions it needs.
• Atlassian's operation IDs are not names a model reads well (search_1, update_2), so import.sh names the functions; a POST that only reads (Jira's POST /api/2/search) is not imported, because a POST counts as a write.
• Jira Service Management Data Center publishes an OpenAPI document of its own (11.3), not imported in this version: a service request is a Jira issue, which the Jira functions read and comment on.
• No delegate agent: other plugins call the functions they were granted.
• Webhooks: Jira Data Center sends no delivery ID, so a redelivery counts once only when its body is the same. Confluence's webhooks are not read.
• Tested against a fake of Jira and Confluence Data Center, shaped from Atlassian's documents, not against a live instance. "Verified" means this project tested, pinned and secured the connector; Atlassian does not endorse it.