Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

MCP in claude code cannot write confluence pages

stefan_lutter
Contributor
July 17, 2026

We observed that in claude code, we are no longer able to write to confluence. That was some weeks ago perfectly working.

It seems that after authentication the following permissions are not present:

  • Create and update comments on content
  • Create and update pages

Has anybody also that issue or a solution for that? Maybe after some update of the MCP?

5 answers

0 votes
stefan_lutter
Contributor
July 20, 2026

After reading the hints from Gabriela (many thanks!), for me the following workaround fixed the issue:

Remark

Gabriela mentioned that this work around seems not to work for everyone, for me it worked.

From that same thread, adding Atlassian as a plain HTTP MCP server pointed at https://mcp.atlassian.com/v1/mcp restored the write tools for a few people.

Configuration for workaorund

I added in my ~/.claude/settings.json the following entries - I have the settings in my user profile:

"mcpServers": {

  "atlassian-write": {
    "type": "http",
  }
}
I did not remove the entry for the plugin:
"enabledPlugins": {
  "atlassian@claude-plugins-official": true
}
After changing the configuration you need to /reload-plugins in claude.
Furthermore you need todo a reconnect for the Atlassian plugin. After that you can check the permission at https://id.atlassian.com/manage-profile/apps. There should be e.g. Create and update pages for Claude Code (plugin:atlassian:atlassian).
0 votes
Gabriela - LeanZero
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
July 19, 2026

For the endpoint: claude mcp list prints each server with its URL right on the line, so you'll see what the Atlassian one actually points at. claude mcp get atlassian gives you the full definition, or it's the url field in ~/.claude.json.

Your server-side read is right, and it isn't the endpoint or the plugin version. It's tracked as issue #204 on atlassian/atlassian-mcp-server: write_confluence is dropped from the consent screen itself, so a fresh grant comes back read-only and no rollback or re-auth brings it back. Still open, no Atlassian response yet. My earlier authv2 note was off, by the way, that one isn't deprecated, only /v1/sse is.

Two things worth trying. From that same thread, adding Atlassian as a plain HTTP MCP server pointed at https://mcp.atlassian.com/v1/mcp restored the write tools for a few people. And leave the colleagues who still have write alone, re-authenticating them now burns the good grant until Atlassian fixes the consent screen.

0 votes
Miguel Santos
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 17, 2026

Thanks for sharing this. I'm seeing the same behavior as well. It was working fine before, but now the write scopes for creating and updating Confluence pages don't seem to be included after authentication. I'll try reauthorizing the app and checking the MCP endpoint and org permissions. Hopefully it's just a recent change rather than a permanent limitation.

0 votes
Gabriela - LeanZero
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
July 17, 2026

Those two lines are OAuth scopes on the grant, so the fix lives on the auth side. Create and update pages is write:page:confluence, Create and update comments is write:comment:confluence, and your token came back without them. Worth ruling out a Confluence space permission too, but the wording you quoted is the consent-screen scope labels, which points at the grant. Three things strip them, roughly in the order I'd check.

First, a stale grant. An existing authorisation keeps its old scopes until you re-consent, so if the write scopes were added or changed after you first connected, your old grant sails on without them. Revoke it at id.atlassian.com under connected apps, then reconnect from Claude Code and watch the consent screen actually list the write scopes before you accept. This is the one that fixes it most often.

Second, the endpoint. If your client points at the older mcp.atlassian.com/v1/mcp/authv2, that path hands back the read and search scope set without write. The current one is mcp.atlassian.com/v1/mcp. The /v1/sse endpoint is gone entirely after 30 June.

Third, an org-level block. There's a newish admin surface at Administration, Rovo, Rovo MCP server, Permissions tab, where Write can be set to Allowed or Blocked for the whole org. Atlassian's own doc calls that tab the primary way to control MCP access now, which lines up with your "worked weeks ago" timing. If the first two don't do it, that's the one to have your org admin check.

One naming thing that's costing you search results. The Remote MCP Server was renamed the Rovo MCP Server, so the newer material is under that name.

stefan_lutter
Contributor
July 19, 2026

@Gabriela - LeanZeroWhere can I see, which endpoint is used?

Here is an update what I tried so far to fix the problem with the help of claude and some additional remarks:

  • I observed that we have at least two colleagues, where write is still possible
    • even after reconnect.
  • I observed that one colleague had an older version of the MCP plugin, so I also tried a rollback (which was manually done by copying some files/adapting configuration files).

Here is a summary from claude for that discussion (some of the conclusions were take by claude!):

MCP Confluence Write Scope Issue

Root Cause Identified

The Atlassian MCP server at `mcp.atlassian.com` stopped issuing two OAuth scopes in new authentication grants:

 

- "Create and update comments on content"
- "Create and update pages"

 

These scopes are required for the Confluence write tools (4 tools), which is why 36 tools are visible instead of 40. Users who authenticated before the change still have the scopes; anyone who re-authenticates now loses them.

What We Ruled Out

- Plugin version — both `f22e7075136a` (v1.1.3) and `9b52fb18e184` connect to the same server; version doesn't affect scopes
- Atlassian permissions — user is org admin with full Confluence access
- Reinstalling the plugin — doesn't help because the cached token is reused
- Re-authenticating — the new OAuth flow simply no longer requests those scopes

What We Tried

- Switched plugin version to colleague's older version (`9b52fb18e184`)
- Revoked token at `https://id.atlassian.com/manage-profile/apps` and re-authenticated fresh
- Cleared auth via `/mcp` and reconnected

 

None of it helped — the scopes are missing from Atlassian's OAuth app registration itself.

Current Status

- Colleague's token (issued earlier) still has the write scopes — **do not revoke it**
- Issue posted in Atlassian Community; other users confirmed the same problem
Like Tim de Boer likes this
0 votes
Veranika Ulasen
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 17, 2026

Hi!
Same issue from today

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events