How to connect Jira to OpenClaw

The ClawHub skill teaches OpenClaw about Jira, but the calls run through the ClawLink plugin and your connected account. Make sure Jira is connected in the dashboard, then start a fresh chat so OpenClaw reloads the tool catalog. If OpenClaw runs as a persistent gateway, restart it so the new tools register.

Reconnect Jira from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

Jira tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every Jira call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

Work through three causes in this order. First, scope: the OAuth grant carries a specific set of Jira scopes, and a partial approval on the consent screen leaves the connection active but unable to do a whole class of action, which is why reads succeed while writes fail. Reconnect and accept the full set. Second, project access: Jira permissions are per-project and per-scheme, so the connected account may simply not be a member of that project or may lack Edit Issues on that board even though it can read it. Third, and this is the cause the search results never teach, the agent may have passed a placeholder from documentation — an issue key like PROJ-123 or an id like 10001 lifted from an example — which Jira rejects with the same 403 rather than a not-found. Ask the agent to list real issues first and retry with a key from that result.

Ask the agent to diagnose it:

Call jira_get_current_user and jira_get_all_projects, tell me which account you are connected as and which projects it can see. Then run jira_check_permissions for the project that failed. Do not retry the failed call yet.

Atlassian began enforcing new points-based and tiered quota rate limits for Jira Cloud apps on 2 March 2026, and they apply to OAuth 2.0 (3LO) apps, which is what a hosted connection is. Worth knowing: API-token traffic was explicitly not part of that change and still runs under the older burst limits, so a script you wrote with a personal token may behave differently from the agent on the same site. Jira Cloud runs three independent limiters at once — a per-hour points quota where each call costs points according to how much work it does, per-second burst limits per endpoint, and a separate per-issue write limit that caps how often a single issue can be modified. The last one is the usual cause when an agent updating one ticket repeatedly stalls while everything else keeps working. Jira sends a Retry-After header with the 429; the fix is to batch the work rather than retry immediately, using jira_fetch_bulk_issues to read many issues in one call instead of looping.

Ask the agent to diagnose it:

Tell me which Jira tools you called in the last two minutes, how many times each, and whether any response included a Retry-After header. Do not call Jira again until I reply.

Tool schemas load on demand, so the first Jira call in a fresh session can arrive before the catalog does — retry once and it usually resolves. If the same name fails twice the name is wrong, not missing. The tools already carry the integration prefix, so they are jira_get_issue and jira_add_comment, and an agent adding another prefix produces a name that has never existed. This is a different problem from the one most search results address, which is a local MCP server missing from a desktop client's config file. There is no local server in this setup and no config file to edit.

Ask the agent to diagnose it:

List the Jira tools you actually have access to. Then tell me which one fetches a single issue by key and use that exact name.

Try reconnecting Jira and complete the consent flow in the same browser session. Partial OAuth approvals or switching accounts mid-flow can leave the connection incomplete.

Yes. ClawLink is the fastest way to connect OpenClaw to Jira: link your Jira account once in the browser and OpenClaw can call the Jira API through 94 ready-made tools — no custom code or token handling.

Paste the setup prompt from this page into OpenClaw. It installs the ClawLink Jira skill from ClawHub, then you click Connect in the dashboard to authorize Jira. OpenClaw calls the tools from the next message — no config files or API keys to manage.

About two minutes. Sign in, click Connect next to Jira in the dashboard, authenticate, and OpenClaw can use it from the next chat message.

The alternative to ClawLink is usually manual OAuth app setup plus your own token handling, permission troubleshooting, and tool plumbing for OpenClaw. That is fine if you want to build and maintain the integration yourself. Most teams just want Jira working from chat.

No. The connection uses Atlassian's OAuth flow, so you sign in and approve access to your Jira site and the credential lives on the ClawLink server rather than in a file on your machine. This is the practical difference from the setup most search results describe, which has you mint a token in Atlassian account settings and paste it into the agent's config. It also changes what happens when you leave a project or an admin revokes access: an OAuth grant stops working immediately, where a stale API token in a config file keeps working until someone remembers it exists.

The same ones your Atlassian account already has, scoped by what you approve on the consent screen. Jira's own permission model still applies on every call, so if your account cannot see a project, neither can the agent, and if you lack the Edit Issues permission on a board, the agent's update calls fail there too. That is the honest boundary to plan around: connect with the account whose access you actually want the agent to have, not an admin account you happen to be signed in as.

This integration targets Jira Cloud, the atlassian.net hosted product, because the OAuth flow and the REST endpoints behind these tools are Cloud's. Self-managed Jira Server and Data Center sit behind your own network and authenticate differently, so a hosted connector cannot reach them without you exposing the instance. If you are on Data Center, the honest answer is that a hosted OAuth service is the wrong shape and you want something running inside your own network.

Give it the issue key and say what you want changed. Jira keys like PROJ-1234 are unambiguous, and every write tool takes one, so a prompt that names the key cannot drift onto a neighbouring ticket. The failure mode to avoid is the open-ended instruction — asking the agent to "close the stale bugs" leaves both the selection and the definition of stale to the model. Ask it to run a JQL search first, show you the issues it matched, and only then act on the keys you confirm.

The ClawHub skill teaches OpenClaw about Jira, but the calls run through the ClawLink plugin and your connected account. Make sure Jira is connected in the dashboard, then start a fresh chat so OpenClaw reloads the tool catalog. If OpenClaw runs as a persistent gateway, restart it so the new tools register.