Atlassian rovo MCP server: permissions, scopes and the mistake everyone makes first

On this page#

• What Atlassian Rovo MCP server actually gives an agent
• The config, line by line
• Scoping it down
• What breaks in a real repo
• When not to connect it at all
• FAQ

What Atlassian Rovo MCP server actually gives an agent#

The Atlassian Rovo MCP server gives an AI coding agent a controlled path into the Jira and Confluence data your authenticated account can access. It can retrieve work context and, where permitted, perform supported actions. It should not become an unrestricted bridge between your repository and the entire company workspace.

MCP—Model Context Protocol—is a standard for connecting an AI application to external tools and data through a client-server interface. In this setup, your coding agent is the MCP client; Atlassian operates the remote server; OAuth establishes whose Atlassian permissions apply.

The useful capabilities fall into two categories:

• Read context: find Jira issues, inspect issue details, search Confluence content, and retrieve relevant pages.
• Take actions: create or update supported Atlassian objects when the authenticated user and server tools allow it.

That sounds straightforward. The first mistake everyone makes is authenticating with their normal, highly privileged daily account and treating the OAuth prompt as sufficient scoping. It is not. OAuth controls delegated authorization; it does not repair an Atlassian permission model that already gives the user access to too much.

The boundary should be explicit:

| The agent may need | The agent should not receive by default | |---|---| | Issues for the repository’s project | Every Jira project visible to an administrator | | Selected engineering documentation | HR, legal, finance, or incident-management spaces | | Comment or transition permissions for a defined workflow | Project administration or broad content deletion | | Read access for planning and implementation | Write access merely because the server supports it |

MCP’s architecture separates the host, client, server, and underlying data source. That separation matters operationally: connecting a server does not make its output trustworthy, and exposing a tool does not mean every agent run should be allowed to call it.

Photo by panumas nikhomkhai on Pexels.

The config, line by line#

Use a repository-local MCP configuration only if your client supports remote HTTP servers and keeps OAuth credentials outside the file. The configuration should name the integration clearly, declare the transport explicitly, and contain no copied bearer token. Authentication belongs in the client’s protected credential flow, not in Git.

{
  "mcpServers": {
    "atlassian-rovo": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/mcp"
    }
  }
}

Line by line:

1. mcpServers is the client’s registry of available MCP connections. Putting the entry here makes the server discoverable; it does not authorize a tool call by itself.

2. atlassian-rovo is a local identifier. Keep it stable and descriptive so approval logs, agent instructions, and onboarding notes refer to the same name.

3. type: "http" declares a remote HTTP transport. If your client uses different field names for remote MCP connections, translate the structure rather than inventing an executable wrapper.

4. url points the client at the remote MCP endpoint. Do not append project keys, space identifiers, credentials, or speculative query parameters.

After adding the entry, start the client’s connection flow and complete OAuth in the browser. OAuth 2.0 is the authorization framework used to grant limited access without placing the user’s password in the MCP configuration.

Never commit:

• Access or refresh tokens
• Session cookies
• Exported authorization headers
• Personal Atlassian credentials
• A second configuration containing “temporary” secrets

A configuration that connects successfully is only the transport layer. The repository still needs an operating policy: which Atlassian objects are in scope, which tools require confirmation, and what evidence must appear before the agent writes anything. PairFoundry’s Agent Operating Kit is the appropriate next step when that policy needs to be repeatable across a team rather than living in one engineer’s prompt history.

Scoping it down#

Scope the connection at the Atlassian permission layer first, the OAuth grant second, and the agent policy third. The correct target is the smallest identity that can read the repository’s project context and perform explicitly approved workflow actions. Anything broader is convenience purchased with an invisible blast radius.

Start with an Atlassian account whose existing access matches the repository:

• Grant access only to the relevant Jira projects.
• Grant access only to the required Confluence spaces.
• Remove project and space administration unless the workflow truly requires it.
• Prefer read-only access for initial rollout.
• Add write capabilities one workflow at a time.
• Require interactive confirmation for mutations.

The official MCP reference servers are useful for understanding the protocol boundary, but they do not decide your organization’s authorization policy. The MCP server exposes tools; Atlassian permissions determine what the authenticated identity can reach; the client decides when the agent may invoke a tool.

Narrowing access has real costs. The agent may fail to resolve cross-project dependencies, miss a design page stored in another space, or be unable to transition an issue after completing work. Those are acceptable failures. A denied request is visible and repairable; silent overreach is neither.

Do not fix every authorization error by expanding the account. Record the missing object, explain why the repository workflow needs it, and grant the smallest additional permission. If the team is still learning these boundaries, use PairFoundry’s free foundations track before enabling writes.

Photo by Jakub Zerdzicki on Pexels.

What breaks in a real repo#

Two failures matter most in a production repository: the agent retrieves plausible but wrong Atlassian context, or it mutates the right object at the wrong time. Both failures can occur while authentication, transport, and tool execution are working perfectly. “The MCP call succeeded” is therefore not a valid acceptance criterion.

Failure scenario 1: the wrong issue becomes authoritative#

A repository contains several services with similar names. The agent searches Jira, selects a matching issue from another project, and uses its acceptance criteria to change code.

The failure criterion is simple: the returned issue is not tied to the current repository by an invariant you can verify. A title match is not an invariant.

Require at least one repository-owned anchor before using retrieved context:

• An approved project key
• An issue key supplied by the user or branch convention
• A repository link recorded in the issue
• A component or service identifier defined by the team

If no anchor matches, the agent must stop and present candidates. It must not choose the most semantically similar result. The MCP architecture transports context; it does not prove that the context belongs to the current task.

Failure scenario 2: a valid write violates workflow order#

The agent finishes a patch and immediately transitions the Jira issue or posts a definitive completion comment. The tool call is authorized, but tests have not passed, review has not occurred, or the local changes have not been pushed.

The failure criterion is: the Atlassian mutation claims a state that the repository cannot yet demonstrate.

Tie every write to observable evidence:

• Comment only after the referenced artifact exists.
• Transition only after the repository’s required checks pass.
• Never claim deployment from a local build.
• Include commit or pull-request references only when they are real.
• Ask for confirmation before destructive or externally visible actions.

For more integration patterns, use the PairFoundry MCP servers hub. For packaged workflows beyond this integration, see the PairFoundry packs overview.

When not to connect it at all#

Do not connect the Atlassian Rovo MCP server when the task has no recurring need for Jira or Confluence context, when the available identity cannot be narrowed, or when agent-generated writes would bypass a required human control. Manual copying is clumsy, but sometimes it is the safer interface.

Leave it disconnected when:

• The repository handles regulated or unusually sensitive data and the authorization boundary is unresolved.
• The only available account has organization-wide administrative access.
• The agent needs one issue once; paste the relevant text instead.
• Jira fields or Confluence pages contain untrusted instructions that the team has not accounted for.
• The workflow cannot distinguish draft output from an authoritative status update.
• Nobody owns token revocation, access review, and offboarding.

The decisive question is not “Can the client connect?” It is “Can the second engineer explain exactly what the agent can read, what it can change, and what evidence gates each change?” If the answer is no, the integration is not ready.

Photo by Daniil Komov on Pexels.

Related reading#

• Docker MCP server — what it can actually reach, and what it should not
• Setting up MongoDB MCP server without giving it your whole repo

FAQ#

What does Atlassian Rovo MCP server do?#

It exposes supported Jira and Confluence capabilities to MCP-compatible AI clients, subject to the authenticated user’s Atlassian permissions and the client’s tool controls. In a coding workflow, its best use is retrieving bounded project context and performing narrowly approved updates—not giving an agent general authority over the company workspace.

Does Atlassian Jira have a MCP server?#

Jira can be accessed through the Atlassian Rovo MCP server as part of the Atlassian connection. Treat that as a remote tool boundary, not as a Jira database connection. The agent receives supported MCP tools and only the access available to the authenticated Atlassian identity.

How to install Rovo MCP?#

For a remote MCP connection, add the server entry to your client’s MCP configuration, declare HTTP transport, use the remote endpoint, and complete the OAuth flow. There should be no package installation or committed token in the repository configuration. Client-specific field names may differ, so preserve the security model when translating the example.

How to connect Jira to MCP server?#

Configure the Atlassian Rovo MCP endpoint in your MCP client, authenticate through OAuth, and verify access with a read-only Jira query tied to an approved project key. Before enabling writes, confirm that the account cannot reach unrelated projects and that mutations require explicit approval or repository-backed evidence.

What can you do with the Atlassian MCP?#

You can retrieve supported Jira and Confluence context and perform supported actions allowed by the authenticated account. The valuable workflow is constrained: inspect the correct issue, obtain relevant documentation, and update status only after verifiable repository events. Broad searching and automatic workflow transitions are technically convenient but operationally unsafe.