The Jira MCP server, done for the enterprise.

Why not just give the agent an API token

The quickest way to connect an agent to Jira is to paste in a personal API token. It also fails every enterprise review, for three reasons. A token carries that person's full access, so the agent can see and change anything they can. There's no per-action audit of what the agent did versus what the human did. And a prompt injection hiding in an issue description can steer the agent into actions the token permits but nobody intended. An MCP server exists to put a governed boundary between the model and Jira. (New to the pattern? Start with what is an MCP server.)

The tools a Jira MCP server should expose

Expose capabilities, not the raw REST API. A practical, safe starting set:

• search_issues — run a scoped JQL query, filtered to projects the caller can access.
• get_issue — read one issue with its fields, comments, and transitions.
• add_comment — append a comment (a write — routed through approval).
• transition_issue — move status along an allowed workflow path (a write).

Notice what's not here: no "run arbitrary REST call," no delete, no permission or workflow administration. Every tool is the narrowest operation that does a real job, and the read tools are cleanly separated from the write tools.

The auth model that keeps it safe

Two identities, never one. The server holds its own credential — an OAuth 2.0 app or a service account with least-privilege project and permission scopes, not a personal admin token. Separately, each AI caller is authenticated, and the requested tool is authorized against that caller's own Jira access. The result: the agent can never do more in Jira than the person it acts for, and revoking the person revokes the agent.

Governing writes: approval and audit

Reads can run freely; writes cannot. A transition_issue or add_comment call should return a proposed change for a human to confirm, not execute silently — because the instruction to make that change may have come from text the agent read, not from a person. Every call, proposed or executed, lands in an immutable audit log with the caller, the tool, the arguments, and the outcome. That log is what lets you answer "what did the agent touch?" months later, and it's the same governance posture we detail on MCP security.

Build vs. off-the-shelf

Generic Jira MCP servers exist and are fine for a single developer on a laptop. The enterprise requirement is different: the server has to map to your permission scheme, honor your project boundaries, route writes through your approval flow, and feed your audit and SIEM. That's a build — usually a small one, but one where the security work is the point, not the wiring. We deliver governed MCP servers like this on MCP server development.

Frequently asked questions