# 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

1. curl the same PAT against /rest/api/2/myself on your Jira host.
   Expected: It returns 200, proving the PAT is valid.
2. Check whether the failing calls were preceded by a 429 rate limit.
   Expected: The logs show 429 then 401.
3. 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.
4. 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.