Atlassian MCP server: OAuth succeeds but zero tools exposed to sessions

[Mov1ngTrg3t]

Description

The Atlassian MCP server (https://mcp.atlassian.com/v1/mcp) connects successfully and OAuth completes, but no tools are ever exposed to agent sessions. Other HTTP MCP servers (LeanIX, Lucid) work correctly with the same app configuration.

Environment

• Copilot CLI app on Windows 11
• MCP config: HTTP type, URL https://mcp.atlassian.com/v1/mcp
• Atlassian Cloud ID:

[Mov1ngTrg3t]

Update: Server confirmed working - client-side bug isolated (2026-07-10)

New evidence

I manually replicated the full MCP handshake using PowerShell and the cached OAuth tokens from ~/.copilot/mcp-oauth-config/:

1. initialize - returns 200 OK, Content-Type: text/event-stream, with Mcp-Session-Id header
2. tools/list (with Mcp-Session-Id header) - returns 31 tools successfully

The server works perfectly. Tools include full Jira CRUD (create/edit/transition issues, add comments, search with JQL) and Confluence operations (create/update pages, search with CQL, Rovo search).

What was tested in the client

Config	Result
type: "http"	Green checkmark, 0 tools in session
type: "sse"	Green checkmark, 0 tools in session

Both transport types connect successfully but expose zero tools to agent sessions.

Likely root cause

The client either:

1. Does not send the Mcp-Session-Id header when calling tools/list after initialize (server returns error -32600 without it), or
2. Does not correctly parse the SSE-formatted response from tools/list

The server requires Mcp-Session-Id on all requests after initialize. Without it, it returns:

{"jsonrpc":"2.0","error":{"code":-32600,"message":"Request must be an initialize request if no session ID is provided."}}

Comparison with working MCP servers

LeanIX and Lucid (also HTTP type, also use OAuth) correctly load and expose tools. The difference is likely in how Atlassian's server uses session IDs for the tools/list call.

Server info (from initialize response)

{
  "protocolVersion": "2024-11-05",
  "capabilities": {"logging": {}, "tools": {"listChanged": true}, "resources": {}},
  "serverInfo": {"name": "atlassian-mcp-server", "version": "1.0.0"}
}

Response headers include: Mcp-Session-Id: r9-<uuid>

[Mov1ngTrg3t]

Update: Server confirmed working - client-side bug isolated (2026-07-10)

New evidence

I manually replicated the full MCP handshake using PowerShell and the cached OAuth tokens from ~/.copilot/mcp-oauth-config/:

1. initialize - returns 200 OK, Content-Type: text/event-stream, with Mcp-Session-Id header
2. tools/list (with Mcp-Session-Id header) - returns 31 tools successfully

The server works perfectly. Tools include full Jira CRUD (create/edit/transition issues, add comments, search with JQL) and Confluence operations (create/update pages, search with CQL, Rovo search).

What was tested in the client

Config	Result
type: http	Green checkmark, 0 tools in session
type: sse	Green checkmark, 0 tools in session

Both transport types connect successfully but expose zero tools to agent sessions.

Likely root cause

The client either:

1. Does not send the Mcp-Session-Id header when calling tools/list after initialize (server returns error -32600 without it), or
2. Does not correctly parse the SSE-formatted response from tools/list

The server requires Mcp-Session-Id on all requests after initialize. Without it, it returns:
json {"jsonrpc":"2.0","error":{"code":-32600,"message":"Request must be an initialize request if no session ID is provided."}}

Comparison with working MCP servers

LeanIX and Lucid (also HTTP type, also use OAuth) correctly load and expose tools. The difference is likely in how Atlassian's server uses session IDs for the tools/list call.

Server info (from initialize response)

json { "protocolVersion": "2024-11-05", "capabilities": {"logging": {}, "tools": {"listChanged": true}, "resources": {}}, "serverInfo": {"name": "atlassian-mcp-server", "version": "1.0.0"} }

Response headers include: Mcp-Session-Id: r9-uuid

[gokhanarkan]

Triage summary

Open PR 12728 targets authenticated MCP servers whose deferred tools remain absent in retained or resumed clients. Current Rust code captures and forwards Mcp-Session-Id, so the report's missing-header theory is not supported.

Please validate this Atlassian flow in PR 12728 before opening new work.

Route: needs-follow-up while work is in progress.

This triage summary was prepared with GitHub Copilot and reviewed before posting.

[gokhanarkan]

Triage summary

Open runtime PR 12728 targets authenticated MCP servers whose deferred tools remain absent in retained or resumed clients, which is a strong match. The proposed Mcp-Session-Id cause is not supported by current code: the Rust client captures and forwards the session ID after initialize and preserves it during header refresh.

Please validate this report in PR 12728 with an Atlassian-shaped OAuth flow across foreground, retained, and resumed sessions. Do not change header handling without a trace showing omission.

Route: needs-follow-up while work is in progress.

This triage summary was prepared with GitHub Copilot and reviewed before posting.

[copilot-cli-bot]

This appears to be resolved as of GitHub Copilot CLI v1.0.88. Please update to that release or a newer stable version. We're closing this as completed. If it still happens, please comment with your version and reproduction steps.