Claude for Jira Service Management: 16 JSM tools, none watch the queue

Atlassian did the thing everyone else is still promising

I build AI agents at eesel, which in practice means I read other people's tool specs for a living. The "can I point Claude at our helpdesk" question has been far and away the most common one in my inbox this year. The answer is usually some flavour of no.

When I checked Claude for Zendesk, what Zendesk had shipped was an MCP client, not a server. Freshdesk sits behind an early access programme. Gorgias has no marketplace listing for it at all. Help Scout did ship a real server, then made it read-only on purpose.

Atlassian just built it. On the Rovo MCP page there is a tile grid of AI clients, and Claude is one of four, sitting next to Cursor and VS Code and ChatGPT, each with an "Add now" button. A vendor pointing its own customers at somebody else's model, on purpose, on its own marketing page.

The access model is generous too. Atlassian's line is "Start for free. No credit card required." What v2 added is a meter on some calls: enriched Teamwork Graph calls, such as Rovo search and getTeamworkGraphContext, draw Rovo credits, mostly 1 to 10 per call. Throughput scales with your plan. Atlassian's v1-era figures were 500 calls per hour on Free, 1,000 on Standard, and 1,000 plus 20 more per user on Premium or Enterprise, up to a 10,000 ceiling. I couldn't find a v2 page that restates them.

So, this post is not a takedown. It is the thing I wish somebody had told me before I spent an afternoon expecting an agent on my service desk and getting a very capable assistant instead.

The four ways to connect Claude to Jira Service Management

There are four routes. They sort along one axis that matters more than all the others put together: whether the thing can put words in front of the person who raised the ticket, without someone prompting it.

The shape of that chart is the whole argument. The instant, official, free route is the one that cannot answer a requester. Same trade I found on Help Scout, though Atlassian arrives at it from a different direction. Help Scout deliberately shipped read-only. Atlassian has now pointed writes at the service desk too: create, transition, approve. Just not at the reply.

Route 1: the official server, start to finish

The endpoint is a single string:

https://mcp.atlassian.com/v2/mcp

Two warnings, before you copy an older config in from somewhere. Atlassian killed the legacy SSE transport: after 30 June 2026, https://mcp.atlassian.com/v1/sse is no longer supported. That date has passed already. So if you inherited a config from a colleague's blog post back in spring, it is dead, and the symptom will look like an auth failure rather than a deprecation. And the v1 endpoints (/v1/mcp and /v1/mcp/authv2) automatically start exposing v2 tools on 1 March 2027. v2 is a separate OAuth resource, so you sign in again.

For Claude Code it is a single command:

claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp

Then /mcp to run the OAuth flow. In Claude Desktop the path is Settings, Extensions, Browse extensions, Plugins, search Atlassian. And on claude.ai, the Atlassian listing sits in the connector directory, built by Atlassian. If you installed the v1 connector there, Atlassian says to remove it and reinstall the v2 one.

One implementation detail trips people up on the very first call. Every tool wants a cloudId, and the way you get one is getAccessibleAtlassianResources, which Atlassian describes as a required first call for any tool. Skip it, let Claude fire straight at searchJiraIssuesUsingJql, and the error coming back reads like a permissions problem. It is not one.

v2 also changed how tools appear. Only a few "primary" tools sit in Claude's tool list. The rest, including every JSM tool, are found through a discover tool and run through executeRead, executeWrite or executeDestructive. If Claude says it has no JSM tools, ask it to discover them.

The other thing worth knowing on day one: Claude reaches your MCP server from Anthropic's infrastructure, never from your laptop. True even in Claude Desktop. So if your Atlassian site sits behind an IP allowlist, the tool calls fail while the OAuth consent screen still appears quite happily, which is about the most confusing failure mode on offer.

Route 2: the 16 JSM tools in v2

Now, the part that changed since I first wrote this.

Atlassian's MCP page now claims 215+ tools across 10+ Atlassian apps. On the supported tools page, Jira gets 52, Confluence 65, Bitbucket 38. Jira Service Management gets 16: the four operations tools it had in v1, plus twelve request tools added on 20 October 2026.

That is a real service desk toolset now. Requests, request types, approvals and SLA signals all have a tool. What the published list still doesn't include is any tool to add a reply or an internal note to a request, or to manage queues, portal customers or portal configuration.

The token gate is gone too. In v1, Atlassian's supported tools page said the JSM tools "only support authentication via API token", so a normal Claude login surfaced none of them. In v2, Atlassian says JSM tools "support OAuth 2.1 and API token authentication." Your admin still has to allow the read_jsm and write_jsm groups, and searchJsmRequests, getJsmRequestResolverPlans and approveJsmRequestResolverPlans also need read_jira.

The other auth rules mostly converged. Bitbucket still wants a workspace linked to your organisation, and the Teams and code search tools are OAuth only. Almost everything else takes either method.

What can Claude actually reach in a service desk?

Requests, through the JSM tools, and the Jira layer underneath, through the generic Jira tools. A JSM project is a Jira project underneath, so listJiraProjects, getJiraIssue, searchJiraIssuesUsingJql, listJiraIssueTransitions, transitionJiraIssue, editJiraIssue, and addOrEditJiraIssueComment all operate on JSM work items quite happily.

That split still matters. Atlassian's own documentation is blunt about what a request type buys you: "If you create a work item without a request type, your requests won't have access to all Jira Service Management features." In v1, Claude was looking at the Jira layer underneath the service desk, not the service desk. In v2 it can see a request's customer-facing state and create requests with a proper request type. For comments, though, it is still on the Jira layer.

The sharpest version of that gap is comments. Over in the service desk API, customer visibility comes down to exactly one boolean on the comment body:

POST /rest/servicedeskapi/request/{issueIdOrKey}/comment
{ "body": "Hello there", "public": true }

public: true is a reply the requester sees on the portal. public: false is an internal note, agents only. No separate endpoint, no visibility object, just the flag. The MCP tool addOrEditJiraIssueComment is described only as "Add a comment, or edit an existing one", with nothing about visibility, which means you can't tell from Atlassian's docs whether the words Claude writes will reach the requester. On an IT desk that is not a missing nicety. It is the difference between a note to your colleague and an email to a director.

Worth knowing if you do take the API route later on: the service desk comment resource exposes only GET and POST. No PUT, no DELETE. Retracting a comment means dropping down to the Jira platform API at /rest/api/3/issue/{id}/comment/{id}, while holding either the Edit own comments or the Delete own comments permission. Plan the undo before you need the undo.

Route 3: the service desk REST API, if you are building it yourself

If you want queue-aware, SLA-aware, customer-visible behaviour that runs without a person prompting it, you write it against /rest/servicedeskapi/ yourself. That is a real project rather than a weekend, and there are three things that will shape the design more than you expect them to.

Rate limits are three systems at once, and Atlassian says your integration "must handle all three". A points-based hourly quota, per-second burst limits, then per-issue write limits on top. The default Global Pool is 65,000 points per hour shared across tenants; a per-tenant pool runs from 65,000 on Free up to 150,000 plus 30 per user on Enterprise, capped at 500,000. Burst defaults sit at 100 requests per second on GET and POST, and 50 on PUT and DELETE. Per-issue writes cap out at 20 in two seconds and 100 in thirty. Then one endpoint is dramatically tighter than all the rest: GET /servicedeskapi/servicedesk/{id}/customer is throttled to 5 requests per second, and it will be the first wall you hit on any customer backfill.

Silent permission failures. Atlassian documents that on GET /request/{id}/comment, "No permissions error is provided if, for example, the user doesn't have access to the service desk or request, the method simply returns an empty response." So an agent that reads no comments, then concludes there were none, goes on to answer the wrong question with total confidence.

Knowledge base access is search-only. GET /rest/servicedeskapi/knowledgebase/article gives you articles matching a query, per service desk or across all of them, and query is required. Nothing in that namespace fetches an article's full body, so grounding on your knowledge base means a second trip out to the Confluence API. The plus side: both KB endpoints are marked exempt from app access rules, unlike every request and comment endpoint.

What does one JSM reply actually cost?

A few cents in Claude tokens, against $0.30 to $1 for Atlassian's own AI per conversation or resolution. Here is where the no-reply limit gets financially interesting. Tokens are cheap, and what they buy is narrow.

A grounded reply runs to roughly 12,000 input tokens once you have pulled the ticket, the transitions and two Confluence pages, plus about 700 output tokens on the way back. On Claude Sonnet 5 at $2 and $10 per million, that is about 3.1 cents. Closer to 1.3 cents once prompt caching is doing its job at $0.20 per million cached read. On Claude Opus 5 at $5 and $25, the same reply lands nearer 7.8 cents.

Now the comparisons. Atlassian's own virtual agent, on Premium and Enterprise, includes 1,000 assisted conversations a month, then bills from $0.30 each after that, and a conversation that gets matched to an intent and then escalated to a human still bills. JSM is now sold as Service Collection, and its Customer Service AI agent bills $1 per AI agent resolution. Rovo credits are a separate meter again: Service Collection includes 250 per user per month on Standard, 700 on Premium, 1,500 on Enterprise, pooled across the org. Extra usage is on by default at $0.01 per credit, and Atlassian starts billing it on 3 December 2026. Enriched MCP calls draw from that same pool. The MCP tools still in beta don't consume credits yet, and Atlassian says they will once they are generally available.

One caveat before you take any per-conversation figure at face value, from an IT manager who took the issue to the product team directly:

"One example: virtual agent will count a ticket as "successfully deflected" if the user gives up responding and it auto closes. That's not a successful deflection, that's an awful user experience."

u/Goose-tb, r/ITManagers

That is worth checking against whatever tool you pick, ours included. A deflection rate that counts abandonment as a win is measuring the wrong thing, and it is the number most likely to be quoted back at you in a renewal meeting.

Plug your own numbers in:

The honest reading of those three numbers: the token column is cheapest because it buys the least. No reply tool, no visibility flag, nothing watching the queue, and no way to test itself before it meets a real requester. Comparing that to a per-request price is comparing a research assistant to an agent. Useful. Not the same job.

The admin side, and why it will say access denied

Four separate things all have to be true before a single tool call lands. Each of them fails differently.

1. The AI domain has to be allowed. Atlassian ships a default list of AI partner domains, Claude and ChatGPT included. Admins can allow it or block it, but Atlassian is explicit that "You cannot block individual domains. You can only allow or block the entire domain list." To permit Claude and refuse the rest, switch the list off and add the domains you trust yourself.
2. The IP has to pass the allowlist, and this one is nasty, because "the OAuth 2.1 consent screen may still appear for users connecting from blocked IPs, but tool calls will fail". The connection looks successful right up to the moment it does nothing.
3. The auth method has to be permitted. API-token auth is an org-wide switch. In v1 that switch decided whether the JSM tools existed for you at all; in v2 it only decides whether token-based clients can connect. Domain blocking, notably, does not apply to API-token connections.
4. Network egress has to reach *.atlassian.net, since the server renders interactive Jira and Confluence widgets inside the AI client via iframes.

On top of all that, a Permissions tab now lets org admins allow or block Read, Write, and Search independently per app, and Atlassian says permissions set there take precedence over settings in Connected Apps. There is also an "Apply to future additions" toggle. Which quietly means newly-added permissions can inherit an allow, with nobody reviewing them. If you happen to be the person signing off on access reviews, that toggle is worth a look. Since 29 September 2026 there is also an MCP control in Data Security Policies, with overrides by app, space and classification level.

Two compliance facts to hand your security team before they think to ask. The server stores and caches no Jira or Confluence content, and it runs strictly inside the signed-in user's permissions, which is a better default than most connectors ship with. But Atlassian lists Rovo MCP as outside its HIPAA scope, earlier MCP docs said FedRAMP wasn't supported either, and it is Cloud-only, no Data Center or Server path published. For plenty of regulated IT service desks, those sentences end the evaluation there and then.

What people are actually running into

The loudest complaint is not about tools or credits. It is that the token keeps expiring. One Atlassian Community thread titled "The MCP Auth expires too fast" runs from October 2025 to March 2026 with roughly 16,500 views and no resolution, and it is full of Claude Code users:

"Bump! I need to reauthenticate sometimes once an hour, sometimes once every 10-20 minutes. This morning I authenticated the MCP connection then sent my prompt, 12 minutes later claude code was getting a 401 response and I only had a single terminal session open. This is basically unusable, I guess I'll just need to build some custom tools to utilize the API."

Aaron Kirn, Atlassian Community

A Community Champion in the same thread put the cause plainly: the server issues short-lived OAuth tokens, external clients cannot refresh them automatically, and long-lived tokens have not shipped. Two things follow from that if you are running agents rather than chatting.

Parallel sessions fight each other. Several people report that authenticating in one window silently de-authenticates the others, which makes any multi-agent workflow painful. And the newer /mcp endpoint fails more quietly than the old one: one user noted that /sse at least threw a 401 you could catch, where the replacement "just silently fails". Atlassian's own troubleshooting page now says the same: "If your token expires, your session will silently fail." If you are wiring up retries, catch the empty result, not just the error code.

Tool quality has its own thread, and this is the part I did not expect. An Atlassian PM working on the MCP server replied on Reddit, on the record:

"Tool quality - the problem you mention where the Jira create tool doesn't respect required fields is something we just need to fix. We've been moving quickly to release a broad range of tools, and now we need to go back and fix some of those pain points. Tool descriptions included. You'll see some improvements here soon Context bloat - we acknowledge this is a problem as well. There are many more tools we want to provide but the current design is already at it's limit."

u/atlassiadam, Atlassian PM, r/mcp

v2's discover and execute design is Atlassian's answer to that context-bloat point: a few primary tools up front, the rest found on demand.

Credit anxiety is the other big theme, and it is mostly about Rovo rather than MCP. One Bitbucket user reported a single pull request review eating almost half of a monthly allowance:

"Rovo had a look at the PR and made a few suggestions and in doing so appeared to use 965 of my 2000 credits with 760 being marked as 'Code review in Bitbucket', I'm not sure where the other 205 went?? Either I'm doing something amazingly wrong or that's not value for money at all."

Chris Mingay, Atlassian Community

An Atlassian product manager replied in that thread and agreed the maths was heavy, which is fair, and unusually candid. The same worry turns up on Reddit, where a Standard-plan user did the comparison out loud:

"advertised ($0.01 per credit after the initial 2000), copilot is a mere $10 for 300 claude 4.5 requests why is it so expensive? the free tier..."

Rovo Dev credits, r/RovoDev

That same poster described burning three quarters of 2,000 credits inside a couple of hours, across no more than 30 requests.

That context matters more now than when I first wrote this. Enriched MCP calls draw from the same Rovo pool as Chat and Agents, and extra usage starts billing on 3 December 2026. If you want to compare the wider field, I've rounded up Rovo alternatives.

How would I actually decide?

By the job. If your goal is analysis, QA, incident writeups, or asking questions across Jira and Confluence in one place, install the connector today. It is the best free Jira AI plugin I have tested this year. Free to connect, official, the permission model is sound, and you can keep it read-only the first time you point an AI at a production desk by blocking the write groups. Strongest free thing in the category, and I would not talk anyone out of it.

If your goal is on-call or request admin, the JSM tools earn their keep. Acknowledging and escalating alerts, approving requests and moving them along, straight from a chat window, is a real workflow, and it no longer needs an API-token conversation with your admin.

If your goal is clearing tier-1 requests so your team stops answering the same VPN question, the connector is not that tool, and no amount of prompting is going to make it one. What you need is something that runs when a request arrives, speaks /rest/servicedeskapi/, knows the difference between a public reply and an internal note, handles escalation cleanly, and can be tested on real requests before it ever meets a new one. My roundup of the best AI for ITSM covers the field if you want to shop it properly.

eesel AI for Jira Service Management

That last job is the one we build for. eesel joins your service desk as an AI agent, not a widget bolted on the side. It runs when a JSM issue is created or gets a new comment, with no prompt needed. eesel sets up the Jira Automation rule that sends those events for you. Then it can reply to the requester, leave an internal note, assign, label, transition, or update fields like priority and due date.

A few specifics, so you know what you're getting:

• It reads your Jira and Confluence live. Issues come in through JQL search as it works, and the AI agent for Confluence side searches and opens your pages while it answers. Nothing is copied in. It connects with one Atlassian API token, so it sees only what that one account can see.
• It works beyond the ticket. Someone can ask it in Slack or Microsoft Teams to file or update an issue, and the AI agent for Jira does it.
• Most teams start with internal notes. The agent drafts, a human sends, and actions need approval until you trust them. Then you let it reply.
• Know the limits. It doesn't answer JSM's portal chat widget conversations, and it can't delete issues or change watchers, links or attachments.

The part I would care about most, evaluating this on a live desk, is testing. You test it on real questions before it goes live, fill whatever gaps that exposes, then launch once you trust the answers. We built it that way because we have watched confident-sounding bots give wrong answers on other people's queues, and a dry run is the only honest way to find that out first.

For a sense of what that looks like on an internal support desk: InDebted runs JSM for a 5 to 10 person IT team supporting hundreds of employees across five markets. Their knowledge comes in from Confluence and from a Slack bot:

"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."

Jason Loyola, IT Team, InDebted, eesel case study

Today they are at 15% of incoming Jira tickets deflected, with 55% as the target once the knowledge base fills out. A real number from a real desk, not a demo figure. And the honest part is that it started at 15%, not at 55%.

Pricing is one fixed monthly price, from $299 for 500 credits. One credit is one request rather than one reply, so a fifteen-message back and forth still counts as one credit. No per-seat fee, and every integration is included. You can try it free with 100 credits, no card needed.

If your service desk lives somewhere other than JSM, the same agent runs on Zendesk, Freshdesk, Gorgias, Help Scout and other helpdesks.

Use the Atlassian connector for the thinking. For the answering, use something that watches the queue and speaks the service desk API. Different jobs, and the good news is that in 2026 you no longer have to pick just one.