Spurious 401 Login Required for a valid PAT after Jira rate limiting (Retry-After: 0)
Fixes mcp-atlassian reporting a valid Jira PAT as expired after a 429 rate limit. Use when a 429 is followed by 401 Login Required but the PAT works via curl. Not for genuinely expired tokens.
Spurious 401 Login Required for a valid PAT after Jira rate limiting (Retry-After: 0)
TL;DR: Your PAT is fine; the server's retry logic turns a bogus Retry-After: 0 into an unbounded retry that surfaces as 401. Verify with curl against /rest/api/2/myself using the same PAT; a 200 there proves the token. Upgrade past the configure_retry fix or set the retry-after opt-out flag so gateways with bogus values fall back to exponential backoff.
The error
ERROR - mcp-jira - Authentication failed for Jira API (401). Token may be expired or invalid. Please verify credentials. (underlying body: "You do not have the permission to see the specified issue. Login Required")Fix it
curl the same PAT against /rest/api/2/myself on your Jira host. Expected: It returns 200, proving the PAT is valid.
Check whether the failing calls were preceded by a 429 rate limit. Expected: The logs show 429 then 401.
Upgrade mcp-atlassian to a version with the bounded configure_retry fix, or set the retry-after ignore flag. Expected: Retries are bounded with real backoff.
Retry the original tool call. Expected: It succeeds or surfaces an honest 429, never a fake 401.
When this applies
mcp-atlassian 401s with Login Required right after rate limiting, on Jira Server/DC behind a gateway that emits Retry-After: 0, while the PAT works via curl.
When this does NOT apply
If curl also 401s, the PAT really is dead; regenerate it. Cloud instances rarely hit the bogus Retry-After path.
Tool compatibility
sooperset/mcp-atlassian 0.23.0, Jira Server/Data Center
Also seen as
- Jira MCP 401 after 429
- valid PAT reported expired mcp-atlassian
- Login Required Jira MCP rate limit
Why it happens
Two retry layers fight: atlassian-python-api honors the gateway's Retry-After: 0 as an immediate unbounded retry, and the failure surfaces as 401 Login Required. The bounded urllib3 retry layer added later is the correct single authority.
Edge cases
- Lowering call concurrency avoids the 429 that starts the cascade.
- Windows stdio users see this most because of per-user gateway limits.
- Do not regenerate the PAT in a loop; it was never the problem.