MCP Failed to Reconnect to Atlassian: Causes and Fixes

Quick Answer

When an MCP client fails to reconnect to an Atlassian MCP server, the cause is almost always one of three things: an expired or revoked OAuth token, a changed Atlassian permission or site configuration, or the MCP server process itself is no longer running or reachable. Start by checking the HTTP status code in the error output, verify the OAuth app is still authorized in id.atlassian.com, and confirm the MCP server endpoint responds before touching client configuration.

MCP Failed to Reconnect to Atlassian: 60-Second Checklist

Work through this in order. Stop at the first item that fails — that is your problem.

• Is the MCP server process running? Check the process, container, or service. If it crashed, restart it and retry.
• Does the server endpoint respond? curl -I <your-mcp-server-url> should return HTTP 200, 401, or 405 — not a timeout or connection refused.
• Is Atlassian itself up? Check status.atlassian.com for active incidents affecting your product (Jira Cloud, Confluence Cloud, Atlassian Access).
• Is the OAuth app still authorized? Log into id.atlassian.com → Security → Connected apps. Confirm the integration appears and shows active scopes.
• Did you rotate or delete the API token? If using an API token instead of OAuth, check it still exists in id.atlassian.com → Security → API tokens.
• Did your Atlassian account or site access change? Confirm the authenticated user still has access to the relevant Jira project or Confluence space.
• Is the MCP server configuration stale? Compare the configured site URL, client ID, and token against what is actually active in Atlassian.
• Does a fresh authentication session fix it? Clear the MCP client's stored state, re-authorize, and retry. If this works, the issue was stale session state.
• What HTTP status code is the MCP server returning? Match it to the HTTP Response section below for the exact fix.

Jump to the Right Fix

Identifying Your Exact Atlassian MCP Implementation

Before debugging anything, confirm exactly what you are running. The fix for an expired OAuth token in a self-hosted third-party MCP server is completely different from the fix for an official Atlassian-hosted integration.

Official vs. third-party: how to tell

• Official Atlassian MCP: The server URL is hosted under an atlassian.com domain, or the integration was installed directly from the Atlassian Marketplace. Authentication flows through Atlassian's OAuth 2.0 authorization server at auth.atlassian.com.
• Third-party or community MCP servers: The server runs on your own infrastructure, a cloud VM, Railway, Render, or a similar platform. Examples include open-source projects like sooperset/mcp-atlassian or custom internal tools. The OAuth app is registered by the third-party developer, not Atlassian.
• Local stdio MCP server: The server runs as a local process on the same machine as the MCP client (common with Claude Desktop). In this case, "reconnect failure" usually means the process crashed or the configuration is broken.

How to find your server details

Check your MCP client configuration file. In Claude Desktop, this is typically at:

# macOS
~/Library/Application Support/Claude/claude_desktop_config.json

# Windows
%APPDATA%\Claude\claude_desktop_config.json

In Cursor, check .cursor/mcp.json in your project or global Cursor settings.

A typical entry looks like this:

{
  "mcpServers": {
    "atlassian": {
      "command": "npx",
      "args": ["-y", "mcp-atlassian"],
      "env": {
        "ATLASSIAN_SITE_URL": "https://your-org.atlassian.net",
        "ATLASSIAN_USER_EMAIL": "user@example.com",
        "ATLASSIAN_API_TOKEN": "your-api-token"
      }
    }
  }
}

Or for a remote SSE/HTTP server:

{
  "mcpServers": {
    "atlassian": {
      "url": "https://your-mcp-server.example.com/mcp",
      "transport": "sse"
    }
  }
}

Identifying the transport type (stdio vs. SSE vs. streamable HTTP) and the hosting model (local vs. remote) determines which sections below apply to you.

Finding the Original Disconnect Cause

"Failed to reconnect" means there was a prior working connection that broke. The cause of the disconnect and the cause of the reconnect failure are often different.

Common disconnect triggers:

• MCP server process restarted or crashed
• OAuth access token expired and the MCP server could not refresh it
• MCP client closed and reopened (Claude Desktop restart, Cursor restart)
• Network interruption between client and remote MCP server
• Atlassian admin action: token deletion, app revocation, permission change

Where to find disconnect information:

For local stdio servers, check the MCP client's own logs. In Claude Desktop, enable developer mode (Settings → Developer → Enable MCP Logging if available) or check the system console. For remote servers, check the server's application logs at the time of the disconnect.

Look for the last successful request timestamp in server logs versus when the client started reporting failure. If they match a token issuance time (typically 1 hour for Atlassian OAuth access tokens), token expiry is the likely cause.

Checking Server Reachability

Before investigating authentication, confirm the MCP server endpoint is actually responding.

For remote HTTP/SSE servers:

# Basic reachability check
curl -I https://your-mcp-server.example.com/mcp

# For SSE transports, test the stream opens
curl -N -H "Accept: text/event-stream" https://your-mcp-server.example.com/sse

# Check with timeout to distinguish connection refused from slow response
curl --connect-timeout 10 -I https://your-mcp-server.example.com/mcp

Expected responses by status:

• 200 OK: Server is up. Authentication is where the failure occurs.
• 401 Unauthorized: Server is up. Token is missing or invalid.
• 403 Forbidden: Server is up. Permissions or scopes are the issue.
• 404 Not Found: Endpoint path is wrong or server was moved.
• Connection refused / timeout: Server process is down or firewall is blocking.

For local stdio servers:

The server is a child process launched by the MCP client. It does not have an HTTP endpoint to check. Instead, verify the command runs correctly on its own:

# Test the server command directly
npx -y mcp-atlassian --help

# Or if using Python-based servers
python -m mcp_atlassian --help

If the command fails, the problem is the server package installation or environment configuration — not the MCP connection itself.

Checking Atlassian Service Availability

If the MCP server is running and the endpoint responds but requests still fail with 5xx errors or timeouts to Atlassian's APIs, the problem may be on Atlassian's side.

Check before anything else:

• status.atlassian.com — official Atlassian status page covering Jira Cloud, Confluence Cloud, Atlassian Access, and Atlassian Identity
• Look for incidents in your region (Atlassian Cloud uses regional infrastructure)
• Check the atlassianstatus.com Twitter/X account for real-time updates during incidents

Identifying Atlassian-side vs. server-side 5xx:

If the MCP server returns 5xx to the MCP client, check whether the MCP server itself is erroring (its own bug) or whether it received a 5xx from the Atlassian REST API downstream. Good server implementations include upstream error details in their logs.

# If you can access server logs, look for upstream Atlassian API responses
grep -E "5[0-9][0-9]|upstream|atlassian\.net" /var/log/mcp-atlassian.log | tail -50

During an Atlassian outage, the only fix is to wait. No client-side or MCP server change will restore connectivity until Atlassian resolves the incident.

OAuth and Token Refresh Failures

This is the most common cause of mcp failed to reconnect to atlassian errors. Atlassian's OAuth 2.0 (3LO) flow issues short-lived access tokens (typically 60 minutes) with longer-lived refresh tokens. When a refresh fails, the connection cannot be restored without user re-authorization.

Diagnosing the Specific Failure

HTTP 401 on reconnect means:

• The access token expired and the MCP server either has no refresh token or the refresh itself failed
• The OAuth app authorization was revoked in Atlassian's admin console
• An API token (non-OAuth) was deleted or rotated
• The MCP server is sending the token in the wrong header format

Verify OAuth app authorization status:

1. Go to id.atlassian.com
2. Navigate to Security → Connected apps (for user-level apps) or check with your org admin under admin.atlassian.com → Security → OAuth app management
3. Look for the MCP integration. If it is missing, authorization was fully revoked.
4. If present, check whether the scopes match what the MCP server expects.

Verify API token status (if using token-based auth):

1. Go to id.atlassian.com
2. Navigate to Security → API tokens
3. Confirm the token used in the MCP server configuration still exists
4. If it was deleted or expired, create a new one and update the MCP server configuration

Fixing OAuth Token Expiry

For third-party MCP servers using API token authentication (most common for self-hosted):

# 1. Generate a new API token at id.atlassian.com
# 2. Update the environment variable or config file
export ATLASSIAN_API_TOKEN="new-token-here"

# 3. If using a .env file
sed -i 's/ATLASSIAN_API_TOKEN=.*/ATLASSIAN_API_TOKEN=new-token-here/' .env

# 4. Restart the MCP server
pkill -f mcp-atlassian && npx mcp-atlassian &

For OAuth 2.0 flows where the refresh token failed:

You cannot recover a failed OAuth refresh token silently. The user must re-authorize:

1. Clear the MCP server's stored token state (location depends on the server implementation — check for a .cache, tokens.json, or similar file in the server's working directory)
2. Restart the MCP server
3. Re-trigger the OAuth authorization flow from the MCP client
4. Complete the Atlassian consent screen with the same account

OAuth refresh token lifetime: Atlassian's refresh tokens for OAuth 2.0 (3LO) expire after 365 days of non-use, or immediately if the user revokes the app. Some third-party MCP servers do not persist refresh tokens between restarts, meaning every server restart requires re-authorization.

Confirming Recovery

After re-authorizing, send a test request through the MCP client:

# In Claude Desktop or Cursor, prompt the agent:
"List my open Jira issues assigned to me"

If Jira data returns without error, OAuth is working. If you still get a 401, the client is likely using a cached stale token — clear the client's credential store and try again.

Account, Site, and Permission Changes

HTTP 403 errors, or successful reconnects with no available tools, usually trace back to changes in Atlassian account access or product permissions.

Common Permission-Related Disconnects

Verifying site access:

# Direct API check using the configured credentials
curl -u "user@example.com:your-api-token" \
  "https://your-org.atlassian.net/rest/api/3/myself"

A 200 OK with your user account JSON confirms the credentials and site URL are correct. A 403 means the user exists but lacks product access. A 401 means the credentials are invalid.

For organizations with Atlassian Access (SSO/SCIM): If your organization enforces an identity provider, the OAuth token may be bound to a specific SSO session. When that session expires at the IdP level, Atlassian can invalidate the OAuth token even before its natural expiry. Check with your Atlassian admin whether session policies have changed.

HTTP Response Troubleshooting

HTTP 401 — Unauthorized

Cause: Token is missing, expired, or invalid. Fix: Re-authenticate. See OAuth and Token Failures. Confirm: curl -u "email:token" https://your-org.atlassian.net/rest/api/3/myself returns 200.

HTTP 403 — Forbidden

Cause: Valid token, insufficient permissions or scopes. Verify: Check the OAuth app's granted scopes at id.atlassian.com. Check the user's Jira/Confluence product access. Fix: Re-authorize with the correct scopes, or fix the user's Atlassian permissions.

HTTP 404 — Not Found

Cause: The MCP server endpoint URL is wrong, the server moved, or the Atlassian site URL in the configuration is incorrect.

Important: HTTP 404 does not universally mean an expired MCP session. It means the URL you requested does not exist. Always check the endpoint path first.

Verify: Access the base URL in a browser or with curl. Check whether the site URL changed.

# Check if the Atlassian site URL is correct
curl -I https://your-org.atlassian.net
# Should return 200 or redirect, not connection error

Fix: Update the site URL or server endpoint in your MCP configuration.

HTTP 429 — Too Many Requests

Cause: The MCP server is retrying the reconnect too aggressively and hit Atlassian's API rate limit.

# Check the Retry-After header
curl -v https://your-org.atlassian.net/rest/api/3/myself 2>&1 | grep -i retry

Fix: Wait for the period specified in the Retry-After response header. Then configure the MCP server to use exponential backoff on reconnects. Do not keep hammering the endpoint — each failed attempt resets the window.

HTTP 5xx — Server Errors

• 500 Internal Server Error: Either the MCP server has a bug, or the upstream Atlassian API returned 500. Check both sets of logs.
• 502 Bad Gateway / 503 Service Unavailable: A reverse proxy (nginx, Cloudflare, AWS ALB) in front of the MCP server cannot reach it, or Atlassian is experiencing an outage.
• 504 Gateway Timeout: The MCP server is up but Atlassian API calls are timing out. Check status.atlassian.com.

Stale MCP Session State

Some MCP server implementations — particularly those using SSE transport with persistent connections — maintain server-side session state associated with a session identifier. When the server restarts, those session IDs become invalid.

Symptom: Reconnect fails with a 404 or a specific session-not-found error. A fresh connection (not a reconnect) succeeds immediately.

How to verify this is the problem:

1. Check whether your MCP client is sending a session ID in the reconnect request (visible in network logs or MCP client debug output)
2. Check whether the MCP server logs show "session not found" or "invalid session" errors
3. Try connecting with a completely fresh client profile or a new MCP client instance — if it works, stale session state is confirmed

Fix:

For SSE-based MCP servers:

# Clear the client's persisted session state
# Location varies by MCP client

# Claude Desktop — remove MCP state
rm -rf ~/Library/Application\ Support/Claude/mcp-state/ 2>/dev/null

# For Cursor, clear the MCP session cache from settings
# Or delete .cursor/mcp-sessions/ in the project directory if it exists

Then reconnect from scratch without providing a prior session ID. The MCP server should issue a new session.

Note: Not all MCP servers use persistent session state. Stateless HTTP MCP servers do not have this problem — each request is independent. The session state issue is specific to SSE transport implementations that maintain server-side connection context.

If you're unsure whether your server uses stateful sessions, check the MCP Inspector complete guide for how to inspect the raw transport layer.

Reconnect Failures After Server Restart or Deployment

If you or someone else restarted, redeployed, or updated the third-party MCP server since the last successful connection, the reconnect will fail for reasons unrelated to OAuth.

Scenarios and Fixes

Scenario 1: MCP server endpoint URL changed after deployment

A new deployment on Railway, Render, Fly.io, or similar platforms can generate a new URL if not using a custom domain.

# Verify the old URL is dead
curl -I https://old-mcp-url.railway.app/mcp
# If 404 or connection refused, find the new URL in your deployment dashboard

Update the MCP client configuration with the new endpoint URL and reconnect.

Scenario 2: Server restarted and lost in-memory token state

Some MCP server implementations store OAuth tokens in memory only. A restart wipes them.

Fix: Re-authorize the integration after restart. For production, configure the server to persist tokens to a file, database, or secret manager.

Scenario 3: Environment variable changes not applied

# Verify the server is reading the correct environment
# If running with Docker:
docker exec <container-id> env | grep ATLASSIAN

# If running as a systemd service:
systemctl show mcp-atlassian --property=Environment

Scenario 4: Reverse proxy configuration broken

If nginx or another proxy sits in front of the MCP server:

# Test the proxy bypass (direct to app port)
curl -I http://localhost:3000/mcp

# Compare to proxy URL
curl -I https://your-domain.com/mcp

# Check nginx logs
tail -100 /var/log/nginx/error.log | grep -i mcp

For SSE transport, ensure the reverse proxy is not buffering the event stream:

# Required nginx configuration for SSE
location /sse {
    proxy_pass http://localhost:3000;
    proxy_buffering off;
    proxy_cache off;
    proxy_set_header Connection '';
    proxy_http_version 1.1;
    chunked_transfer_encoding on;
}

Reconnect Succeeds but Atlassian Tools Are Missing

This is a particularly confusing failure mode: the MCP connection establishes successfully, but when you ask the agent to search Jira or read Confluence pages, it says it has no tools available.

Why this happens:

MCP tools are advertised during the initialization handshake via the tools/list method. If the server returns an empty or reduced tool list, the client has no tools to call — even though the transport is connected.

Diagnostic steps:

# Use MCP Inspector to check what tools are actually being advertised
npx @modelcontextprotocol/inspector@latest
# Connect to your MCP server and check the Tools tab

You can also test the tools/list call directly:

# For streamable HTTP servers
curl -X POST https://your-mcp-server.example.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

If the response contains an empty tools array, the server is not exposing any tools. Common reasons:

1. Insufficient OAuth scopes: The token was re-issued with fewer scopes than before. The server requires read:jira-work, read:confluence-content.all, etc., but the re-authorization only granted basic scopes.
2. Feature flags or configuration: Some server implementations hide tools based on environment variable configuration (e.g., ENABLE_JIRA=false).
3. Partial authentication: The server connected but Atlassian API calls to enumerate accessible projects failed, so it returned no tools rather than erroring.

Fix:

Re-authorize with explicit scope selection. If using OAuth 2.0, check the consent screen during re-authorization and confirm all required scopes are checked. If using API tokens, verify the token owner has Jira Software and Confluence product access on the Atlassian site.

Client-Specific Reconnect Problems

If one MCP client reconnects successfully while another fails, the problem is almost certainly client-side.

The working client has: A valid cached access token or OAuth session that has not yet expired. The failing client has: An expired or revoked token, or stale session state that it is presenting on reconnect.

Claude Desktop

# Clear all MCP-related state in Claude Desktop
# macOS
rm -f ~/Library/Application\ Support/Claude/mcp*.json

# Restart Claude Desktop
# Then allow it to re-initialize the Atlassian MCP server

If the MCP server is configured in claude_desktop_config.json, confirm the config is valid JSON and the server command or URL is current:

# Validate JSON syntax
cat ~/Library/Application\ Support/Claude/claude_desktop_config.json | python3 -m json.tool

Cursor

# Check global MCP config
cat ~/.cursor/mcp.json

# Check project-level config
cat .cursor/mcp.json

# Reload Cursor window after config changes
# Cmd+Shift+P → "Reload Window"

General Client Debug Pattern

For any MCP client with debug logging available:

1. Enable verbose or debug logging
2. Trigger the reconnect
3. Find the exact HTTP request the client sends and the exact response it receives
4. The status code and response body will point to the specific failure reason

For remote server testing, the MCPForge test tool can independently verify whether your MCP server is functioning correctly, which helps isolate whether the problem is the server or a specific client.

MCP Inspector Testing

MCP Inspector is the most reliable tool for isolating whether the reconnect failure is client-related or server-related.

# Install and launch MCP Inspector
npx @modelcontextprotocol/inspector@latest

This opens a browser UI at http://localhost:5173.

Testing a remote SSE or HTTP server:

1. Select SSE or Streamable HTTP transport
2. Enter your MCP server URL
3. Add any required authorization headers (Bearer token, etc.)
4. Click Connect
5. If connection succeeds, go to the Tools tab and click List Tools
6. If tools appear, the server is healthy and the problem is client-specific

Testing a stdio server:

1. Select STDIO transport
2. Enter the command (e.g., npx mcp-atlassian)
3. Add environment variables for ATLASSIAN_SITE_URL, ATLASSIAN_USER_EMAIL, ATLASSIAN_API_TOKEN
4. Click Connect
5. Check the connection output for errors

What MCP Inspector reveals:

• Whether the server accepts connections at all
• What tools are actually advertised
• Whether specific tool calls succeed
• Raw JSON-RPC messages for debugging transport-level issues

If MCP Inspector connects successfully but Claude Desktop or Cursor cannot, the problem is definitively in the client configuration, not the server.

For a complete walkthrough of MCP Inspector's capabilities, see the MCP Inspector complete guide.

Minimal Reproduction Steps

If you cannot identify the root cause, reduce the problem to its simplest form before escalating.

# Step 1: Test Atlassian API directly with configured credentials
curl -u "your-email@example.com:your-api-token" \
  "https://your-org.atlassian.net/rest/api/3/myself" \
  | python3 -m json.tool

# Expected: JSON with your Atlassian account details
# If this fails: credentials or site URL are wrong

# Step 2: Test MCP server health independently of the MCP client
curl -I https://your-mcp-server.example.com/

# Step 3: Test MCP server connection via Inspector (see above)

# Step 4: Test MCP client with a different, known-working MCP server
# This confirms whether the client itself is broken

If Step 1 fails, the problem is credentials or site URL. If Step 1 passes but Step 3 fails, the problem is the MCP server. If Steps 1-3 pass but the client still fails, the problem is the MCP client configuration or cached state.

Bug Report Checklist

If you've exhausted the above steps and need to report the issue to a server maintainer or open a GitHub issue, include this information:

Bug Report: MCP Failed to Reconnect to Atlassian

**MCP Server:**
- Name and version: 
- Official Atlassian / Third-party / Self-hosted: 
- Transport: stdio / SSE / Streamable HTTP
- Hosting: Local / Docker / Railway / Render / Other:

**MCP Client:**
- Name and version (Claude Desktop 0.x / Cursor 0.x / Other):
- OS:

**Atlassian Configuration:**
- Product: Jira Cloud / Confluence Cloud / Both
- Authentication method: OAuth 2.0 / API Token
- Site URL (redact org name if needed): https://[org].atlassian.net

**Error Details:**
- Exact error message:
- HTTP status code (if visible):
- When did the connection last work successfully?
- What changed between last success and current failure?

**Diagnostic Results:**
- Does `curl` to Atlassian API with credentials succeed? Y/N
- Does MCP Inspector connect to the server? Y/N
- Does a fresh OAuth session fix the problem? Y/N
- Does [status.atlassian.com](https://status.atlassian.com) show any active incidents? Y/N

**Reproduction Steps:**
1. 
2. 
3. 

**Server Logs (redact tokens and PII):**

Prevention Best Practices

Once you fix the reconnect failure, these practices reduce the likelihood of it recurring.

Token and credential hygiene:

• Use long-lived API tokens for server-to-server integrations instead of OAuth where possible — they do not expire on a 60-minute cycle
• Store tokens in a secret manager (AWS Secrets Manager, HashiCorp Vault, Doppler) rather than plain environment variables — this makes rotation easier
• Set calendar reminders for API token expiry if your organization has a rotation policy

Server resilience:

• Configure the MCP server to persist OAuth refresh tokens across restarts if it supports this
• Add a health check endpoint to the MCP server and monitor it with an uptime tool
• Use exponential backoff in reconnect logic to avoid triggering Atlassian rate limits

Permission stability:

• Use a dedicated service account or integration user for MCP Atlassian access rather than a personal account — personal account permission changes cascade to all integrations
• Document which OAuth scopes the MCP integration requires so re-authorization always uses the same scope set

Monitoring:

• Set up log alerts for 401 and 403 responses in the MCP server logs
• Subscribe to status.atlassian.com email updates for your Atlassian products

For a comprehensive treatment of secure MCP server design, the MCP security best practices guide covers production-grade secrets management and permission scoping in detail.

Frequently Asked Questions

Why does my Atlassian MCP connection drop after a few hours?

OAuth access tokens issued by Atlassian expire. When the MCP client cannot silently refresh the token — either because the refresh token also expired, the user revoked app consent, or the MCP server never stored the refresh token — the connection drops and cannot automatically recover. Re-authorizing the integration from scratch is usually required.

The MCP reconnect error says 401 Unauthorized. What does that mean for Atlassian specifically?

A 401 from Atlassian's API means the access token the MCP server sent is missing, expired, or invalid. The most common causes are an expired short-lived access token, a revoked OAuth app, or a deleted API token. Check the Atlassian admin console to confirm the OAuth app still has active authorization, then re-authenticate.

My Atlassian MCP reconnects successfully but no Jira or Confluence tools appear. Why?

Tool availability depends on the scopes granted during OAuth and the Jira/Confluence site permissions of the authenticated user. If scopes changed, consent was partially revoked, or the user lost access to a specific Atlassian site, the MCP server may connect but expose zero tools. Check the granted OAuth scopes and the user's product access in the Atlassian admin console.

Can I test whether my Atlassian MCP server is reachable before reconnecting the client?

Yes. Use curl or MCP Inspector to send a request to the server's base URL or health endpoint. For SSE-based servers, curl -N <server-url> should open a stream. For streamable HTTP, a GET or POST to the MCP endpoint should return a recognizable response. If you get a timeout or connection refused, the server itself is down before the client is even involved.

One MCP client reconnects to Atlassian successfully but another fails. What causes that?

This almost always means one client has a valid cached token or session state and the other does not. The failing client is likely presenting an expired or revoked token. Clear the failing client's stored credentials, delete any persisted session state, and re-authorize. Do not assume the problem is server-side when one client already succeeds.

Does Atlassian have an official MCP server?

As of early 2025, Atlassian has been actively developing MCP integrations, but many integrations in use today are third-party or community-built MCP servers that wrap Atlassian's REST APIs. The behavior of reconnects, session management, and OAuth token handling differs significantly between official and third-party implementations. Always identify which server you are actually using before troubleshooting.

What is the fastest way to confirm an Atlassian OAuth app is still authorized?

Log into id.atlassian.com, go to Security → Connected apps (or Manage apps depending on your account type), and look for the integration. If it is missing or shows no active scopes, the app authorization was revoked and you need to re-authorize the MCP integration from scratch.

HTTP 429 errors appear when my Atlassian MCP tries to reconnect. Is that a real block?

Yes. Atlassian rate-limits API requests per OAuth token and per site. If the MCP server is retrying reconnects aggressively, it can exhaust the rate limit and get temporarily blocked. Add exponential backoff in the server configuration if available, wait for the retry-after period, and check whether reconnect storm behavior is triggering this.

After rotating my Atlassian API token, the MCP server still fails to reconnect. Why?

Rotating the API token invalidates the old one immediately. The MCP server still has the old token cached in its configuration or environment variables. You need to update the MCP server's configuration with the new token and restart the server process for the change to take effect.

My Atlassian site URL changed. Will that cause MCP reconnect failures?

Yes. If your Atlassian Cloud site was renamed or migrated, the base URL used in the MCP server configuration is now invalid. Requests will return 404 or redirect to the new URL depending on whether Atlassian set up redirects. Update the site URL in the MCP server configuration and verify the endpoint resolves correctly before reconnecting the client.