MCP-Method header: route and rate-limit MCP requests at a gateway

The MCP 2026-07-28 release requires Mcp-Method and Mcp-Name headers on HTTP requests. If you rate-limit in front of Sume, note that Sume counts its own limits by what a call does, not by the request that carried it.

What does the spec now require?

The MCP project's release post lists a stateless core with no initialize handshake and no Mcp-Session-Id header, with each request carrying the protocol version and client identity, and states that the Mcp-Method and Mcp-Name headers are required on HTTP requests. The post does not spell out routing rules beyond that, so treat gateway policy as your own design.

How does Sume count an MCP call?

Sume's rate limits use separate read and write budgets per plan. A read is any GET or HEAD, plus two POSTs that submit nothing: /v1/generation/admission-preview and the MCP endpoint itself. Everything else is a write. The authentication docs add that an MCP tool call spends the write budget for the run it creates, once, not for the JSON-RPC request that carried it, and a jobs_status poll over MCP spends no write budget.

Should my gateway limit by MCP method?

A per-method header limit at your gateway would be a second, separate limit on top of Sume's. It cannot see which calls create a paid run unless you map tool names yourself. Sume's own accounting already does that, so the safer default is a generous gateway limit and reliance on the response headers: read ratelimit-remaining and back off on retry-after. A 429 names the budget in error.details.scope, either read or write.

Does the hosted server use these headers today?

Sume's server negotiates older protocol versions, as covered in the 2026-07-28 spec post, so do not build a gateway rule that requires Mcp-Method on traffic to mcp.sume.com. See Authentication for the limits themselves.

Which numbers matter if I put a gateway in front?

If your gateway limits requests per minute, compare its number to the read budget for your plan, because the MCP endpoint itself counts as a read. On the Free plan that is 4800 reads a minute, and on Pro it is 12000. The write budgets are 120 and 300 on those plans, and they are spent by the runs a tool call creates.

That means a burst of jobs_status polls over MCP is cheap against Sume's limits, while a burst of paid creates spends write budget one run at a time. A gateway rule that treats every MCP POST as a write would be stricter than Sume is.