How to connect Jira to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

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.

Two causes account for nearly all of these, and they look identical from chat. The first is a placeholder argument: an agent that has not listed anything yet will guess a project key or issue id, and strings like YOUR_PROJECT_ID or PROJ-123 are structurally valid, so the call reaches Atlassian and comes back as a permissions failure rather than a bad-argument failure. The fix is to list first and act second. Ask the agent to run jira_get_all_projects or jira_search_issues, then retry using an id from the response. The second cause is account and site scope: your Atlassian login may reach several sites, but the OAuth grant covers the one you approved, and your Jira permissions inside that site are still yours. jira_get_my_permissions reports what the connected identity can actually do, which separates a wrong-id problem from a genuine permissions problem in one call.

Ask the agent to diagnose it:

Run jira_get_all_projects and show me the project keys you can see. Then run jira_get_my_permissions and report whether BROWSE_PROJECTS and CREATE_ISSUES are granted. Do not retry the failing call until both have returned.

This is a connect-flow error, not an API permissions error, and searching for the phrase is misleading because Google answers it with Atlassian's GDPR change that hides emailAddress in API responses. That change is real and unrelated. What this message means during connect is that the Atlassian identity you are signing in with has not confirmed its email address, so Atlassian will not complete the consent step. Verify the address from the confirmation mail Atlassian sent to that account, then start the connection again from the dashboard.

Ask the agent to diagnose it:

Run clawlink_list_integrations and tell me the exact status of the Jira connection, without retrying the connection.

Tool schemas load on demand, so the first Jira call in a fresh session can arrive before the catalog is in the agent's context. Retry once. If the same name fails twice, the name is wrong rather than missing: the error message lists the nearest real tools, and retrying with one of those works. The doubled-prefix shape (jira_jira_) is the most common invented name, and it usually means the agent concatenated the integration name onto a tool name that already carries it.

Ask the agent to diagnose it:

List the Jira tools you actually have available and tell me which of them creates an issue. Then 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 Hermes to Jira: link your Jira account once in the browser and Hermes Agent can call the Jira API through 94 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect Jira in the dashboard and Hermes can use it 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 Hermes Agent 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 Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want Jira working from chat.

Yes. The three routes people are usually told about all produce a credential you hold: an API token from id.atlassian.com, a Forge app that issues an appUserToken or appSystemToken, or a community MCP server that reads a token from a config file. ClawLink uses Atlassian's OAuth consent flow instead, so no token is created and nothing is written to your machine. You still authorize the connection, and you should: it is what lets Atlassian show the grant in your account settings and lets you revoke it there in one click. The practical difference is what happens six months later. A token you minted keeps working until you remember to rotate it, and it works from anywhere it leaks to. A consent grant is listed, attributable, and revocable from a screen you already have access to.

No. You do not register anything in developer.atlassian.com, and you do not deploy a Forge app. The Jira connection runs through an OAuth app that is already registered, which is why setup is a sign-in rather than a build. If you have been reading Forge documentation to solve this, that path exists to let an app act with its own identity across a site; it is the right answer for a product you are shipping to other Atlassian customers, and a heavy answer for letting your own agent file tickets.

The one you were signed into when you approved the connection. Atlassian scopes OAuth grants to the site you pick during consent, so an agent connected to your sandbox will keep returning empty project lists against production and vice versa. The fastest way to check is to ask the agent to run jira_get_all_projects and read the names back. If they belong to the wrong site, reconnect Jira from the dashboard while signed into the correct one, in the same browser session.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.