Rate Limiting & Reliability

JiraMCP includes a built-in rate limiter that protects against Jira API rate limits and ensures reliable operations through exponential backoff, request queuing, and operation verification.

delay = min(initialDelay * 2^attempt, maxDelay) * random(jitterMin, jitterMax)

The jitter prevents thundering herd problems when multiple requests hit rate limits simultaneously.

The rate limiter automatically retries on:

• HTTP 429 — Too Many Requests (uses Retry-After header if present)
• HTTP 5xx — Server errors (502, 503, 504)
• Network errors — Connection timeouts, DNS failures

JiraMCP reads Jira’s rate limit headers on every response:

• X-RateLimit-Remaining — Requests remaining in current window
• Retry-After — Seconds to wait before retrying (on 429 responses)

For mutation operations (create, update, transition), JiraMCP automatically verifies the operation succeeded by reading back the resource after writing.

1. Execute mutation (e.g., create issue)
2. Wait delayBeforeVerify (default: 500ms)
3. Read back the resource
4. Compare expected vs actual state
5. If mismatch and retryOnMismatch is enabled, retry up to maxVerifyRetries times

• verifyIssueCreated — Confirms issue exists with expected fields
• verifyIssueUpdated — Confirms fields were updated correctly
• verifySprintState — Confirms sprint state transition (active/closed)
• verifyIssuesInSprint — Confirms issues were moved to the target sprint

All rate limiting and verification events are logged with:

• Correlation IDs for request tracing
• Request/response metrics
• Retry attempt details
• Verification results

Set JIRA_LOG_LEVEL=DEBUG to see detailed rate limiting behavior.