Understand MCP rate limits
MCP and OAuth limits protect the server. They are counted per minute.
Limits by operation
| Bucket | Limit | Applies to |
|---|---|---|
| Main MCP limit | Read rate limit per minute, default 60 | Standard methods; every authenticated native HTTP request |
| Writes | The read limit, capped at 20 | Write tool calls |
| OAuth | 5 | Registration and token requests |
The write cap is a ceiling, not a setting: raising the configured limit above 20 does not raise the write limit. Lowering it below 20 lowers both, since writes use the smaller of the two.
OAuth registration and token requests share a fixed budget per client IP. Repeated MCP connection attempts also have an early per-IP limit before credential verification.
The WordPress 6.8 transport counts read and write operations separately. The bundled WordPress MCP Adapter counts every authenticated HTTP request and separately counts writes: a write consumes one of each. Concurrent requests cannot share the same remaining slot. Permission checks do not consume extra write slots; dry_run calls do.
Configuring the read limit
Settings → POM AI → MCP server → Runtime limits → Read rate limit per minute, default 60.
Sixty is comfortable for interactive use. Consider raising it if an assistant legitimately reads many records in a session and you see it being throttled; consider lowering it if you want a tighter bound on what a session can do.
How requests are counted
Counting is per authenticated caller, per minute:
- OAuth MCP calls — per client and acting user, shared across that pair’s tokens.
- API key — per key. Everything using that key shares one budget, which is a reason to prefer OAuth when several tools connect.
- Unauthenticated OAuth endpoints — per client IP.
Each minute is its own window. A client throttled at the end of one minute can continue at the start of the next.
What being limited looks like
| Where | Response |
|---|---|
| Standard MCP method | Error -32029 with a rate limit message |
| Native HTTP request limit | HTTP 429 with Retry-After |
| Native write limit | Tool result with isError: true and a rate limit message |
| The OAuth endpoints | HTTP 429 with rate_limited |
Nothing is executed when a call is limited, so no partial state results.
What it protects, and what it does not
It bounds how fast a client can act. That helps against a client stuck in a retry loop, a misconfigured integration polling aggressively, and a runaway session doing more than intended.
It is not a safety mechanism against harmful changes. Twenty writes a minute is more than enough to do real damage over several minutes. The controls that actually prevent unwanted changes are the write gates, the acting user's capabilities and the scopes on the token. See MCP security model.
During setup
The OAuth bucket catches people out. Registration and token endpoints share five attempts per minute, so a client retrying a failing exchange in a loop exhausts its budget quickly — and then every attempt fails for a reason unrelated to the original problem.
When diagnosing an OAuth failure: change one thing, try once, wait if you see 429. Repeated attempts mask whether your fix worked.
During bulk work
An assistant editing many records makes one call per record and hits the write cap at twenty per minute. A hundred-record job therefore takes at least five minutes.
That is usually fine, and the pacing is arguably a feature — it leaves time to notice a session going wrong. If a genuinely large job needs to run faster, the answer is a script or a WordPress bulk action, not MCP. See What POM AI MCP does not expose.
Reducing how often you hit it
- Ask for specific records rather than broad listings.
- Prefer tools that return counts over tools that return every record.
- Let the client cache the tool list rather than re-listing each turn.
- Send one JSON-RPC message per request with WordPress MCP Adapter. Standard-mode batches still count each method individually.
- Pace large jobs across minute boundaries. Opening another session does not reset the same caller’s budget.
Checking whether limits are the problem
Inspect the response in the client and the recent MCP logs in the settings panel. Repeated authentication denials are sampled, and a request refused before authentication may have no individual log entry. An empty log does not prove the request failed upstream.
If the server reports that request limiting is temporarily unavailable, wait and ask the site administrator to check WordPress storage. The server does not execute the operation while that safeguard is unavailable.
Multisite
Limits are per site, since each site has its own server, tokens and API key. Separate site connections have separate budgets. Requests delegated through the main-site MCP connection also remain subject to that connection's limits.