429 Rate Limited in MCP: How to Reduce Tool Calls and Retry Safely

Getting 429 rate limit errors from your MCP server? This troubleshooting guide helps you understand rate limiting, identify the causes (bursting, loops, large lists), implement safe retry/backoff strategies, and reduce tool calls through batching and pagination patterns.

Understanding 429 Rate Limits

A 429 status code means you've exceeded the rate limit—too many requests in too short a time. The server is temporarily refusing requests to protect itself and ensure fair usage.

What Rate Limiting Means

• Rate limit: Maximum number of requests allowed per time window
• 429 error: Server response indicating limit exceeded
• Temporary: Usually resets after a short period (seconds to minutes)
• Protective: Prevents server overload and ensures fair usage

Common Causes of Rate Limiting

1. Bursting (Too Many Calls at Once)

Symptom

Making many tool calls in rapid succession

Example

"List all my projects, then for each project list all tasks, then for each task get details"

This can trigger hundreds of calls in seconds.

2. Loops Without Delays

Symptom

Repeated tool calls in a loop without rate limiting

Example

"Update 100 tasks one by one" (without batching or delays)

Each update is a separate call, quickly hitting limits.

3. Large Lists Without Pagination

Symptom

Fetching all items at once instead of paginated batches

Example

"Get all my tasks" (may return 1000+ tasks, requiring many calls)

Use pagination to fetch in smaller batches.

4. Parallel Tool Calls

Symptom

Making multiple tool calls simultaneously

Example

"Get details for tasks 1, 2, 3, 4, 5 all at the same time"

Parallel calls can quickly exhaust rate limits.

Step 1: Identify Rate Limit Errors

Recognize when you're hitting rate limits:

429 Error Indicators

• HTTP status code: 429 Too Many Requests
• Error message mentioning "rate limit" or "too many requests"
• Response headers may include Retry-After (seconds to wait)
• Some calls succeed, then suddenly all fail
• Errors occur after a burst of successful calls

Rate Limit vs Other Errors

Step 2: Implement Safe Retry with Backoff

When you get a 429 error, retry with exponential backoff:

Exponential Backoff Strategy

Recommended Retry Pattern

1. First retry: Wait 1-2 seconds, then retry
2. Second retry: Wait 2-4 seconds, then retry
3. Third retry: Wait 4-8 seconds, then retry
4. Max retries: 3 attempts total
5. After max: Report error to user

Check Retry-After Header

Some servers include a Retry-After header indicating how long to wait:

• If present, wait at least that many seconds
• If not present, use exponential backoff (1s, 2s, 4s)
• Don't retry immediately—this makes the problem worse

Prompt Patterns for Retries

Good: Explicit Retry Instruction

"If a tool call returns 429 rate limit error, wait 2 seconds and retry once. If it still fails, wait 4 seconds and retry again. After 3 attempts, report the error."

This guides the AI to implement proper backoff.

Step 3: Reduce Tool Calls with Batching

Batch operations to reduce the number of calls:

Batching Strategy

Batch Operations

1. List items once (with pagination if needed)
2. Process items in batches of 10-20
3. Wait for batch to complete before next batch
4. Avoid parallel calls within batches

Example: Batch Update Pattern

Good: Batched Updates

"Update task titles in batches of 10:
1. Get first 10 tasks
2. Update each one sequentially
3. Wait for all 10 to complete
4. Then get next 10 tasks
5. Repeat until done"

This reduces calls and avoids rate limits.

Bad: Unbatched Updates

"Update all 100 tasks at once"

This triggers 100+ calls quickly, hitting rate limits.

Step 4: Use Pagination

Fetch large lists in smaller, paginated chunks:

Pagination Best Practices

Paginated Requests

// Instead of getting all tasks
list_tasks()  // May return 1000+ tasks, many calls

// Use pagination
list_tasks(limit: 50, offset: 0)   // First 50
list_tasks(limit: 50, offset: 50)  // Next 50
// Continue until done

Recommended Limits

• list_tasks: Use limit: 50-100 per call
• list_task_comments: Use limit: 25-50 per call
• list_projects: Usually small, but limit: 20 if needed

Prompt Patterns for Pagination

Good: Paginated Request

"List my tasks, but only show the first 50. If I need more, I'll ask for the next batch."

This ensures the AI uses pagination.

Step 5: Avoid Parallel Calls

Make tool calls sequentially when possible:

Sequential vs Parallel

Good: Sequential Calls

"First, list my projects. Then, for each project, list the tasks one at a time."

This encourages sequential, not parallel, calls.

Bad: Parallel Calls

"Get all my projects and all their tasks at once"

This may trigger parallel calls, hitting rate limits quickly.

Step 6: Use Filters to Narrow Results

Filter before fetching to reduce the number of items returned:

Filtered Queries

Use Filters

// Get only tasks due this week
list_tasks(due_date: "2026-06-12", status: "in_progress", limit: 50)

// Instead of getting all tasks and filtering client-side
list_tasks()  // Returns everything, then filters (more calls)

Available Filters

• project_id: Filter by specific project
• board_id: Filter by specific board
• status: Filter by status (open, in_progress, done, blocked)
• due_date: Filter by due date
• keyword: Search by keyword (server-side filtering)

Step 7: Monitor and Adjust

Track your tool call patterns to avoid future rate limits:

Rate Limit Prevention Checklist

• ✅ Using pagination for list operations (limit parameter)
• ✅ Using filters to narrow results before fetching
• ✅ Batching operations (10-20 items per batch)
• ✅ Making sequential calls instead of parallel
• ✅ Implementing retry with exponential backoff
• ✅ Checking Retry-After header when available
• ✅ Limiting total number of calls per workflow

Quick Fix Checklist

When You Get 429 Errors

1. ✅ Identified the error as 429 (rate limit, not auth/permission)
2. ✅ Checked for Retry-After header in response
3. ✅ Implemented exponential backoff (1s, 2s, 4s delays)
4. ✅ Limited retries to 3 attempts max
5. ✅ Reviewed workflow for batching opportunities
6. ✅ Added pagination to large list operations
7. ✅ Reduced parallel tool calls
8. ✅ Added filters to narrow results

Related Troubleshooting

• Timeouts - Fix timeout issues that can occur with rate limits
• Pagination Guide - Learn pagination patterns for MCP tools
• Batching Guide - Learn how to batch tool calls effectively
• Troubleshooting Index - Browse all troubleshooting guides