The connection is standard now. The permission model is not.
The Remote MCP Server exposes your Atlassian estate over the Model Context Protocol, so an assistant outside Atlassian can read and act on work items, pages, and service requests. Our work is scoping what external assistants can reach, and the identity work underneath it.
The Remote MCP Server lets external assistants read and act on your Atlassian data. What they are allowed to see is a permission question, and it is answered before the connection is made, not after.
What it is
The Remote MCP Server exposes your Atlassian estate over the Model Context Protocol, so an assistant outside Atlassian can read and act on work items, pages, and service requests.
It is for organizations that already have assistants in use and would rather connect them to a governed system of record than watch teams paste data into whatever tool is open.
What it does
It exposes what the identity can already reach
Scope is inherited from the connecting account, so the interesting question is what that account is entitled to.
It is a standard connection, not a custom integration
One protocol rather than a bespoke script per tool, which means one thing to govern instead of several.
It leaves a trail
Activity arrives attributable, provided the connection was made with an identity that has an owner.
Where it fits
L4, agents and automation, resting directly on L1. A connection is only ever as narrow as the account behind it. The server does not invent permissions; it exposes the ones the connecting identity already holds, which is why the identity model decides how much of your estate a given assistant can see.
What we do with it
Scope the connecting identity
Deciding what an assistant may reach starts with designing the account it connects as, rather than reusing an administrator credential.
Policy and guardrails
Written policy for what may be connected, by whom, and what evidence is kept.
Build what the protocol does not cover
Where the estate needs behavior the standard server does not provide, we build it on Forge inside the same permission model.
Where it earns its place
A carrier with assistants already in use
Teams are pasting ticket content into external tools today. A governed connection replaces that with something reviewable.
An engineering group connecting a coding assistant
Read access to the right projects, and nothing else, is a permission design problem rather than a configuration toggle.
A regulated organization that needs an audit trail
If an assistant touched a record, the question is which identity it acted as, and that has an answer only if one was designed.
Proof
Monthly SDK downloads of the Model Context Protocol, donated to the Linux Foundation in December 2025. The connective tissue is standard now.
Anthropic and the Linux Foundation, December 2025.
Of security leaders say they lack full visibility into the machine identities already running in their environment.
2026 CISO AI Risk Report, 235 large-enterprise leaders.
AI Innovator Finalist, 2026
Atlassian Partner Awards, 2026
Questions we get
Is this safe to turn on?
Which assistants can connect?
Do we need this if we already have Rovo?
Licensing
Access depends on your Atlassian entitlement and on which products the connecting identity is licensed for, so an edition change can quietly widen or narrow what an assistant can reach. That reconciliation sits with the rest of the estate in licensing and renewals.