AI agents are changing how teams work with Jira: searching issues, creating tickets, logging work, and moving tickets through workflows in natural language is becoming part of the daily routine. The standard protocol connecting agents to these capabilities is the Model Context Protocol (MCP), and Atlassian offers an official Remote MCP Server for Jira Cloud.
Meanwhile, Jira Data Center does not yet ship with native MCP support — the official Remote MCP Server covers Cloud deployments. And DC teams are exactly the ones whose data lives in their own infrastructure, behind their own network. To fill that gap, we built an MCP server that runs inside your Jira Data Center — as part of our app, AI for Jira. The same agent-driven workflows now run in DC, with every byte staying inside your perimeter.
60 seconds on MCP
The Model Context Protocol (MCP) is the open standard that lets AI clients — Claude Code, Claude Desktop, Cursor, and a growing list of others — call tools in external systems: search issues, create tickets, log work, transition a ticket through its workflow. An MCP server exposes those tools; an MCP client (your AI agent) discovers and calls them over JSON-RPC.
This post introduces one — built into AI for Jira, our AI integration app for Data Center.
What you get
Once AI for Jira is installed, the MCP endpoint lives at:
https://<your-jira-base-url>/rest/devpod_ai/1.0/mcp
It exposes a curated set of 25 tools, organized by domain rather than a raw dump of REST endpoints:
Domain | Tools |
|---|
Issues (11) | create, edit, get, search with JQL, list transitions, transition, create/edit metadata (so agents can discover valid fields before writing), issue links + link types, remote issue links |
Comments & worklog (2) | add comment, log work |
Projects & users (3) | visible projects, issue-type metadata per project, account ID lookup |
Sprints (4) | list, create, start, close |
Versions (3) | list, create, release |
Confluence & utility (2) | fetch Confluence page content, current date-time |
A few design decisions that matter in practice:
- Structured input schemas on the write path.
createJiraIssue, editJiraIssue, and transitionJiraIssue expose hand-written, named-field JSON schemas (e.g. projectKey, issueTypeName, assignee_account_id) instead of the generic arg0/arg1 blobs agents struggle with. Agents get arguments right the first time. - Metadata-first flow. The create/edit metadata tools let an agent ask "which fields does this project's Bug type actually require?" before it writes anything — dramatically fewer failed creates on customized Jira instances.
- Rich text your way. Description and comment bodies accept both
markdown and Jira wikiMarkup. - Sprint & version lifecycle, not just reads: an agent can set up and close a sprint or release a version when you tell it to.
Security: nothing new to trust
This is the part we're proudest of, because we took something away.
Authentication is 100% native Jira. The endpoint accepts exactly what your Jira already accepts — Personal Access Tokens (Authorization: Bearer …), HTTP Basic auth, or a browser session. All of it is handled by Jira's own platform filters before the request ever reaches the plugin. The plugin contains zero authentication code: no token storage, no key management, no custom login flow.
That means:
- PAT lifecycle — create, expire, revoke, audit — is Jira's own Personal Access Tokens page, maintained by Atlassian, not by us.
- Every tool call executes as the authenticated user. An agent can only see and touch what you can see and touch. Jira's project permissions, issue-level security, and workflow conditions all apply, untouched.
- No privileged service account to provision, rotate, or leak.
Full transparency on OAuth: we originally shipped a complete OAuth 2.0 authorization server inside the plugin — authorization code + PKCE, dynamic client registration, RS256 JWTs, tool-level scopes. Then we removed it. In a self-hosted DC environment, a third-party plugin signing its own tokens is a trust and audit burden your security team shouldn't have to accept when the platform's native chain already exists and is already trusted. So we deleted it, and MCP clients connect with a native PAT instead. (The evaluation notes are in our public docs.)
Admin gates, in order: MCP feature switch → valid license → allowed user group. Off by default, and you decide which groups can use it. The same allowed-group config governs the in-product AI chat, so it's one place to look.
Connect Claude Code in 3 steps
1. (Admin) Enable MCP. Install or upgrade AI for Jira from the Atlassian Marketplace, flip on the MCP switch in the admin console, optionally set the allowed group.
2. (User) Create a Personal Access Token. Avatar → Personal Access Tokens → Create token. Pick an expiry; copy the token once.
3. Point your client at the endpoint. For Claude Code:
claude mcp add --transport http jira-dc-ai https://jira.example.com/rest/devpod_ai/1.0/mcp \
--header "Authorization: Bearer <your-jira-pat>"
Or, for team/project sharing, commit a .mcp.json that reads the token from an environment variable:
{
"mcpServers": {
"jira-dc-ai": {
"type": "http",
"url": "https://jira.example.com/rest/devpod_ai/1.0/mcp",
"headers": {
"Authorization": "Bearer ${JIRA_DC_AI_MCP_TOKEN}"
}
}
}
}
Then just ask:
"What's blocking the ATMOS release this week? Summarize the open blockers and draft a comment on each one."
"Log 2h on DEMO-42 for today's API work, then move it to In Review."
Every action runs as you, under your permissions, visible in Jira exactly as if you'd clicked it yourself.
Compatibility
AI for Jira maintains dedicated branches for Jira 9, 10, and 11 — the mainline tracks Jira 10 LTS (10.3.x), with dedicated Jira 9 and Jira 11 lines. Your upgrade path doesn't get orphaned by an AI side-quest.
Honest current limitations
- Transport is JSON-RPC over HTTP POST (Streamable HTTP style); SSE streaming is not implemented yet, so clients that require server-sent-event streaming won't connect.
- Confluence access is currently read-only via a fetch tool.
Try it and tell us what breaks
If you're running Jira Data Center 9/10/11 and have been waiting to put an AI agent to work on real tickets, this is the fastest on-ramp we know of that keeps every byte inside your perimeter.
- 📦 AI for Jira on the Atlassian Marketplace: https://marketplace.atlassian.com/apps/1234138/ai-for-jira?hosting=datacenter
- 📖 MCP setup & auth docs:
<link-to-docs> - 💬 Questions, feedback, bug reports: drop them in the comments here or reach us at
<contact>
We'd especially love to hear which MCP clients you connect beyond Claude Code — that determines what we build next.
![Photo of [A9] William Kennedy](https://avatar-management--avatars.us-west-2.prod.public.atl-paas.net/557058:2787dbc5-5758-4142-a364-5ff139de3beb/c894312e-0181-4f44-a1cf-ac611beb001e/128)