Jira MCP vs the Jira API: Which Should Your AI Use?

Use Atlassian’s MCP server when a person is asking an assistant to do Jira work in a conversation: find the open bugs, summarise a work item, file three issues from meeting notes. Use the Jira Cloud REST API when a program runs the same steps every time: a nightly sync, a CI job that transitions an issue on merge, a migration of two thousand work items. The MCP server signs the assistant in as you through a browser and offers a curated set of tools; the REST API takes a token or an OAuth app and offers the whole platform, including administration. Both act with a person’s Jira permissions. The general case, for any product, is in MCP vs REST API; this post is the Jira version.

The two routes side by side

• Address: the MCP server is one hosted endpoint, https://mcp.atlassian.com/v2/mcp, for all your Atlassian Cloud apps. The REST API is your site, https://your-site.atlassian.net/rest/api/3/..., or api.atlassian.com for OAuth apps.
• Who calls it: an MCP client such as Claude, ChatGPT, Cursor or VS Code, choosing tools mid-conversation. The REST API is called by code someone wrote and reviewed.
• Sign-in: MCP defaults to an OAuth sign-in in the browser. The REST API uses an API token, an OAuth 2.0 app, or a Forge or Connect app.
• What it exposes: MCP offers tools grouped as read, write, search, delete and manage. The REST API offers every documented endpoint, including workflows, custom field configuration, permission schemes and webhooks.
• Limits: REST has published rate limits. MCP documents credit use for some tools rather than a call budget.
• Where it runs: the hosted MCP server covers Atlassian Cloud only, not Data Center or Server, so this comparison is with the Jira Cloud REST API.

How each one signs in

The MCP server’s normal route is OAuth. You add the server to your client, a browser opens on Atlassian’s consent screen, you approve, and the client holds a token you never see. Atlassian admins decide which client domains may complete that sign-in, and Atlassian’s list of supported domains↗ (opens in a new tab) includes chatgpt.com and claude.ai.

For machines without a browser, the MCP server also accepts API tokens, but only if an organisation admin has switched that on. Atlassian’s token guide for the MCP server↗ (opens in a new tab) describes two kinds: a personal API token sent as HTTP Basic, and a service account key sent as a Bearer token, each created with the scopes for the apps you need. It lists the trade-offs too: some tools, such as code search and Teams, need OAuth; a token is not bound to one site, so the client has to pass the site’s cloud ID; and token connections are governed by IP allowlists rather than domain settings.

The REST API has had token access for years. Atlassian’s guide to basic auth for REST APIs↗ (opens in a new tab) describes your email plus an API token, base64-encoded in an Authorization header, and recommends it for simple scripts and manual calls rather than as its most secure option.

Tokens have grown tighter controls. Atlassian’s account documentation↗ (opens in a new tab) says you can create an API token with or without scopes and recommends scopes, and that a token expires between one day and one year after creation, one year by default. Revoking one stops it at once.

For anything other people will install, the REST route is an OAuth app. In OAuth 2.0 (3LO) for Jira↗ (opens in a new tab), requests go through api.atlassian.com/ex/jira/{cloudid}, the app asks for scopes such as read:jira-work and write:jira-work, access tokens expire, and refresh tokens rotate on each use.

# REST: a script reads one work item with a scoped API token
curl -u you@example.com:$JIRA_API_TOKEN \
  -H "Accept: application/json" \
  https://your-site.atlassian.net/rest/api/3/issue/PAY-412

# MCP: an assistant gets the tools, then you sign in with /mcp
claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp

What each one exposes

The MCP server is a selection. Atlassian groups its Jira tools by intent, keeps a few primary tools in the initial list and lets the client find the rest through a discover tool. It covers everyday work well: JQL search, reading work items with comments and history, creating and editing them, transitions, worklogs, links, versions, sprints and boards. Deleting work items and managing projects sit in two groups that are off until an admin enables them. The full list, group by group, is in what the Jira MCP server can do.

The REST API is the whole building. Next to issues, search (/rest/api/3/search/jql) and transitions, the v3 reference has groups for workflows and workflow schemes, custom field contexts and options, permission schemes and webhooks. If the job is to change how Jira is configured rather than what is in it, the published MCP tools do not reach it, and the REST API does.

Rate limits and cost

The REST API’s limits are written down. Atlassian’s Jira rate limiting page↗ (opens in a new tab) describes three layers: an hourly points quota that charges each call by the work it does, per-second burst limits per endpoint, and per-issue write limits of 20 writes in 2 seconds and 100 in 30 seconds. Going over returns 429 Too Many Requests with a Retry-After header and a RateLimit-Reason naming the limit you hit. The points quota applies to Forge, Connect and OAuth 2.0 apps; API-token traffic stays under the burst limits.

The MCP documentation talks about a different currency. Atlassian says some tools, such as Teamwork Graph and Rovo Search, consume Rovo credits from the organisation’s pool, up to 10 per call. If your organisation watches that pool, ask your admin before you let an assistant search in a loop.

There is a third cost that neither page mentions: the model’s context. Every MCP result the assistant reads takes up room in its working memory, so an assistant asked to touch five hundred work items will be slow, will summarise where you wanted exactness, and may lose track. A script does the same five hundred updates in a loop and logs every one.

When a script beats an assistant

• The steps are the same every time. Transition on merge, label on release, close stale items on Friday: write it once, review it once, run it forever.
• The volume is high. Hundreds of updates belong in a loop with retries that respect Retry-After, not in a conversation.
• The output must be exact. A report someone signs off, a data export, a migration: code gives the same answer twice; an assistant may phrase it differently.
• The endpoint is not a tool. Workflow schemes, field contexts, webhooks and permission schemes are REST-only today.
• Nobody is there. A scheduled job cannot complete a browser sign-in, so it needs a scoped, expiring token or an OAuth app either way, and at that point plain REST is the simpler contract.

When the assistant wins

• The question needs judgement. “Which of these bugs look like the same bug?” is a reading job, not an endpoint.
• You would otherwise write a one-off script for a one-off question. “Open bugs in PAY assigned to me, newest first” is one sentence to an assistant and ten minutes of JQL and curl for you.
• The input is messy. Meeting notes, a customer email or a stack trace become well-formed work items faster through an assistant than through a form.
• You want the guard rails Atlassian has built for it: the OAuth consent screen, admin control of which clients may connect, delete and manage groups off by default, and an organisation audit log that admins can filter for Rovo MCP actions.

Using both well

The two routes combine better than they compete. Ask the assistant, over MCP, to work out the JQL and try it on real data; when the answer is right and you need it every week, ask it to write the REST script, then review and schedule that. Give the script its own scoped token with an expiry and a name that says what it is for, so revoking it later breaks nothing else.

One thing neither route gives you is a separate identity for the assistant. Over MCP it acts with your account; with a personal API token, the script does too. On the MCP side, a service account key gives automation an account of its own, but an assistant you signed in yourself leaves changes under your name, so tell your team what convention marks its work.

The same question on fenbs

fenbs is a much smaller board than Jira, and it answers the question the other way round: MCP is the main door. The web interface and the MCP server call the same service, so a person and an assistant are allowed the same things and refused for the same reasons, and each change is recorded with the assistant’s name. A script or a scheduled job that cannot sign in uses a token issued by hand under Settings, with a name, the scopes you tick and an optional expiry, and calls the same MCP tools. The REST API page lists the endpoints, but API keys are not available yet; MCP covers the same ground in the meantime.