Sume MCP rate limit: one write per run created, none per status poll

An agent that calls Sume over MCP uses the same per-minute budget as one that calls the REST API, but it counts differently. The docs say that an MCP tool call spends the write budget one time, for the run it creates. It does not also spend a write for the JSON-RPC request that carried it. A jobs_status poll over MCP spends no write budget at all.

Why the transport request is a read

The MCP endpoint is one of the two POST routes that submit nothing. Like /v1/generation/admission-preview, it counts as a read. The tool inside it then spends a write only when it creates a run. This keeps an agent that lists options and checks status from burning the submit budget that the plan sells.

The budget in numbers

On Free, 120 writes a minute means about 120 runs created each minute across all keys of the workspace owner. Reads are 4800 a minute. An agent that creates 10 runs and polls each of them every 2 seconds uses 10 writes and about 300 reads in a minute, which is far from either limit.

Check it yourself

A short loop makes the claim visible. It reads ratelimit-remaining before and after a read-only call and prints the difference. Run it against a key that nothing else is using. The numbers belong to the bucket that the request spent from.

import os, urllib.request

def remaining(path):
    req = urllib.request.Request("https://api.sume.com" + path, headers={"x-api-key": os.environ["SUME_API_KEY"]})
    with urllib.request.urlopen(req, timeout=15) as resp:
        return int(resp.headers["ratelimit-remaining"])

a = remaining("/v1/me")
b = remaining("/v1/me")
print("reads spent between two calls:", a - b)  # 1 when nothing else shares the key

When a 429 appears

An MCP client that gets rate_limited should read error.details.scope. A write scope means too many runs were created in the window, so reduce the fan-out. A read scope means the polling is too tight, so lengthen the interval.