What Can the Jira MCP Server Do? Tools, Permissions and Gaps

The Jira MCP server, which Atlassian calls the Atlassian Rovo MCP Server, lets an AI assistant search Jira with JQL, read work items with their comments, history, worklogs and attachments, create and edit work items, move them through workflow transitions, comment, log time, link items, and manage versions, sprints and boards. It can also delete work items and create projects, but those two groups are switched off until an Atlassian admin turns them on. Everything runs with the signed-in person’s own Jira permissions, and it works only with Atlassian Cloud.

This piece is about capability: what the tools are and what they can touch. For connecting it to Claude Code step by step, see Jira MCP with Claude Code. The tool names below are taken from Atlassian’s published supported-tools list↗ (opens in a new tab); the list changes, so treat your client’s own tool list as the final word.

How the tools are organised

Atlassian groups every tool into a permission group by intent. For Jira there are five: read_jira, write_jira, search_jira, delete_jira and manage_jira. The groups matter because admins can turn them on or off, and because they tell you at a glance how much risk a tool carries.

Tools are also either primary or deferred. Primary tools are returned in the normal MCP tool list and are always visible to the assistant. Deferred tools are found at run time through a discover tool that takes a plain-language query. So an assistant may not “see” a tool such as sprint management until it asks for it. Atlassian documents↗ (opens in a new tab) a ?tools=all parameter for gateways that need the whole list up front.

What it can read

The read group is the largest. The primary read tool is getJiraIssue, which fetches a work item by ID or key. Around it sit deferred tools for almost everything you can see in Jira’s interface:

• Projects and their structure: listJiraProjects, issue types and field metadata, components, versions, statuses and the transitions available on an item.
• Activity on an item: comments (listJiraIssueComments), the field-change history (listJiraIssueChangelogs), worklogs, links and remote links, and attachment download addresses.
• People: the current user, a user by account ID, a lookup by name or email, and who can be assigned an item.
• Boards and sprints: boards you can see, their configuration and the items on them, and active, future and closed sprints.
• Saved filters with their JQL, and dashboards.

Search is its own group, with one primary tool: searchJiraIssuesUsingJql. In practice this is the tool an assistant uses most, because it can turn “open bugs assigned to me in PAY, newest first” into JQL and run it.

What it can change

The write group has four primary tools, which cover the everyday work:

• createJiraIssue: create a work item.
• editJiraIssue: change its fields.
• transitionJiraIssue: change status through the workflow, or assign to a sprint.
• addOrEditJiraIssueComment: add or edit a comment.

Deferred write tools go further: log or edit time (addOrEditJiraIssueWorklog), link items, watch an item, upload an attachment, set entity properties, create or release versions, create, start and close sprints (manageJiraSprint), and create scrum or kanban boards (createJiraBoard). That last set is worth noticing. An assistant with write access can reshape a sprint, not only update a ticket.

Off by default: delete and manage

Two groups are disabled until an admin enables them. delete_jira holds deleteJiraIssue, deleteJiraComment and deleteJiraIssueAttachment, which Atlassian describes as permanent deletes. manage_jira holds createJiraProject and updateJiraProject. Leaving these off is a reasonable default for most teams: an assistant can do almost all useful work without them, and a mistaken delete is the one thing you cannot fix by editing.

Whose permissions it uses

The server acts as the person who signed in. Atlassian’s documentation↗ (opens in a new tab) says every action respects the authenticated user’s existing permissions and the server never grants access beyond what the user already has. That has two consequences:

• An assistant cannot see or change anything you could not. Your project permissions apply exactly as they do for you in the browser.
• An assistant can do anything your account can, within the enabled tools. There is no separate, narrower role for the assistant inside Jira. If you are a Jira admin, the assistant is working with an admin’s rights.

The client adds a second layer. Most assistants ask before calling a tool unless you pre-approve it, so a sensible pattern is to allow reads and searches freely and keep writes on ask. The general argument for that, and for starting read-only, is in MCP security best practices.

What admins control

• Which AI tools and domains may connect. By default↗ (opens in a new tab) Atlassian-supported domains are allowed; admins can block them all or authorise their own trusted domains.
• Which tool groups are enabled, including the delete and manage groups above.
• Whether API token authentication↗ (opens in a new tab) is allowed at all. OAuth sign-in is the default; token access for automation must be enabled by an organisation admin.
• IP allowlists, which Atlassian says apply to MCP requests as they do to other access.
• The audit log, which admins can filter for Rovo MCP user actions.

Gaps and edges

• Cloud only. The server connects to Atlassian Cloud apps; Jira Data Center and Server are not covered.
• Configuration is mostly out of reach. The published Jira tools read workflows, statuses and fields, but none edit workflows, custom fields, permission schemes or automation rules. Those stay in Jira’s admin screens.
• Token sign-in sees fewer tools. Atlassian notes that some tools, such as code search and Teams, need OAuth, and a support article↗ (opens in a new tab) explains that an API token without the right scopes can leave you with only a handful of tools.
• Some tools cost Rovo credits. Atlassian says certain tools, such as Teamwork Graph and search, draw on the organisation’s Rovo credits, up to 10 per call.
• No assistant identity. Because the assistant signs in as you, its changes are made with your account. If you need to tell your edits apart from your assistant’s later, that has to come from habit, such as a comment convention, not from Jira itself.

Beyond Jira

The same connection carries tools for other Atlassian Cloud apps your account can use. For Confluence there are primary tools to fetch, create and update content and to search, plus a long list of deferred ones for spaces, comments, versions, labels and page permissions. Jira Service Management, Bitbucket Cloud, Loom, Goals and Projects have their own groups. If you only want Jira, your client’s per-tool permissions are the practical way to narrow it.

When a smaller board fits better

Jira’s MCP server is broad because Jira is broad. If you would rather have a simpler board where the assistant works as a member with a role of its own, narrower than yours if you choose, and every change is signed with its name in the history, that is how fenbs is built. See fenbs vs Jira for a fair comparison, or roles and permissions for humans and AI agents for the idea behind it.