The first ninety days of an MCP server in production are about correctness, not abuse. The team is busy proving the agents do the right thing: the policy lookups return what they should, the audit log captures the right fields, the structured errors are parsed by the agent framework correctly. Rate limiting is something the team plans to add "after we have real traffic." The team has real traffic on day 12 and forgets to add rate limiting. On day 87 the first runaway lands.

The runaway always has the same shape. One agent starts behaving badly: a test loop forgot to set max_iterations, a malformed prompt drove the model into a long-output failure mode, a retry policy got an aggressive backoff inverted. The agent calls the same MCP tool 400 times in 30 minutes, burning 70% to 90% of the day's token budget before any human sees the alert. By morning the bill shows a $4,200 charge against an Anthropic account that usually does $800/day.

The structural fix is per-agent token quotas baked into the MCP server. Each agent identity gets a budget across three windows (hourly, daily, weekly). The MCP server tracks consumption and rejects calls that would exceed the budget. The agent gets a structured error; the human operator gets one page per cycle instead of a Slack thread at 9 a.m. asking who is responsible for the bill.

The pattern composes with the MCP cost ledger (which tells you what each agent has spent) and the policy-aware MCP governance work. The ledger is descriptive; the quota is prescriptive. Together they turn per-agent cost into a managed budget rather than a billing artifact you read about three days later.

The first MCP runaway lands in 90 days

The runaway shapes are predictable. After auditing a dozen MCP-server rollouts at ZopDev customers, the three failure modes account for almost every incident.

The detection latencies are uncomfortable because none of them are inside the MCP server's control. The server sees the agent's calls and bills them honestly. It does not see the agent's intent, the retry logic, or the prompt change that landed an hour ago. By the time a human sees the spike in a billing dashboard or a cost alert, the runaway has been burning for hours.

The right place to catch this is inside the MCP server, on the call path. Every tool call passes through the server; every call has an agent identity attached (a service account, a session token, an API key). If the server checks the agent's running budget against a quota before allowing the call, the runaway stops at the quota boundary instead of at the 9 a.m. Slack ping.

Per-agent quotas as a tri-window check

A single daily quota is not enough. An agent that burns its full daily budget by 10 a.m. has fourteen hours to keep generating rejected requests; even rejected, the orchestration overhead (the agent's own LLM calls deciding what to do next) eats real tokens. A weekly quota catches the slow-creep agent that goes 8% over every day for five days and adds up to a meaningful Friday total that no daily check would have stopped.

The three caps compose. The agent is allowed if it is under all three. If any single cap trips, the call is rejected. This sounds expensive to check but in practice it is three counter reads from a Redis hash; the overhead is sub-millisecond.

The hourly cap is the most underweighted of the three. Teams that ship daily-only quotas get caught by the morning runaway whose damage is done before the daily counter resets. The hourly cap means the worst case is 60 minutes of damage instead of 8 hours. For a 100x normal burn rate, the difference is $200 vs $2,000.

The weekly cap catches the agent that nobody pages on because no single day looks anomalous. An agent that does 60K tokens/day on a 50K cap looks within budget on the daily check (allowing the over-budget grace described below) but accumulates to 420K by Friday on a 250K cap. The weekly check catches the pattern that the per-day signal misses.

Default budget + adaptive growth

A new agent does not get a generous quota on day one. The default is small (50K tokens/day, 8K/hour, 250K/week) and grows with demonstrated usage. The growth is automatic, based on the agent's actual consumption pattern over the trailing 30 days.

The shape: cheap by default, generous to proven workloads, never silently unlimited. A new agent that turns out to need 1M tokens/day gets there through a documented promotion path, not by accident. The same agent at day one would have been hard-blocked at 50K and the human would have set the right quota explicitly.

The promotion thresholds matter. If the auto-promotion fires whenever utilization is non-zero, every agent inflates to its peak day's quota and the protection erodes. If the threshold is too tight (e.g., only auto-promote at 50-70% utilization), most agents never grow and FinOps becomes a quota-approval bottleneck. The 30% / 40% bands above are the typical operating range; tighten or loosen based on the team's tolerance for false promotion vs friction.

Hard-block vs degrade: the design choice

When an agent exceeds quota, the MCP server has two response options. Hard-block is the simple choice: reject the call with an error, the agent's task fails, the human investigates. Degrade is the more humane choice: route the call to a cheaper model (or a cached response, or a partial result), the agent's task completes but with lower quality, the cost stays under control.

Most teams ship hard-block first because the failure mode is contained: an agent that breaks under quota is visible immediately and gets a real fix. Degrade looks better in theory but introduces a subtle failure mode: a degraded agent producing low-quality outputs may loop trying to recover, generating more (cheaper but still real) calls and ultimately costing more than hard-blocking would have.

The middle path is to ship hard-block as the default and let agents opt-in to degrade for specific tool classes where partial output is genuinely better than no output. Read-only tools (lookup, search, summarize) are good degrade candidates: a cached or cheap-model response is acceptable. Write tools (mutations, policy changes) should hard-block: a degraded write is worse than no write.

Structured rejection so retries back off correctly

When the MCP server rejects a call, the error payload matters more than the rejection itself. An unstructured error ("quota exceeded") triggers the agent's default retry logic, which is usually "try again with exponential backoff." The agent retries, gets rejected, retries again, and burns more tokens on its own orchestration calls trying to figure out why the tool is failing.

A structured rejection includes the data the agent needs to back off correctly:

With this payload, the agent's retry logic can do the right thing: stop retrying until reset_at, surface the over-budget condition to its orchestrator, or fall back to a different code path. None of these are possible from "quota exceeded" alone.

The cost difference between structured and unstructured errors is meaningful. A blind retry loop against a rejected MCP tool generates 5-15 orchestration LLM calls before the agent's policy gives up. At Claude Sonnet rates, those orchestration calls cost roughly the same as the rejected tool calls would have cost. Structured errors zero out that overhead.

Audit + composition with the cost ledger

Every quota check writes an audit log line, regardless of decision. This is the system of record for two things: postmortem of any cost incident, and input to monthly quota tuning.

The cost ledger and the quota check run on the same call path but serve different purposes. The ledger writes the actual token cost after the call returns (the source of truth for billing). The quota check uses a pre-call estimate (input tokens are known exactly, output tokens are projected from max_tokens). The estimate is conservative (assumes worst case); the ledger is exact.

This split matters for tuning. After 30 days, the ratio of estimated cost to actual cost is the input to whether the quota's grace margin needs to change. If estimates are systematically 20% higher than actuals, agents get blocked more often than the budget would warrant; the grace margin can shrink. If estimates are 10% lower, the budget is leaking; the grace margin needs to grow.

The composition with the MCP cost ledger is what makes the quota system trustworthy. The ledger answers "what did we spend"; the quota answers "what are we allowed to spend." Two complementary systems, one call path, one audit log.

First-month tuning: 2-4 unexpected runaways caught

The first month of the quota system in production produces a predictable mix of firings. ZopDev customer rollout data shows:

The week-1 false positives are a signal that some agents were running with consumption nobody had measured. This is itself the value: the team learns what its agents actually cost. Most teams discover at least one "we thought this agent did 20K tokens/day but it actually does 180K" surprise in the first two weeks.

The week-3 first real runaway is the moment the system earns its keep. The runaway gets caught within an hour (because of the hourly cap), the page goes out, the human reads the structured error, and the incident is closed in 45 minutes with $200 of damage instead of 8 hours and $5,000.

The FinOps engineer time across the month is 4-6 hours: classifying the firings, adjusting quotas, writing brief postmortems, updating the promotion thresholds based on observed utilization. The fleet-wide saving over the same month is typically 20-40% of the monthly token bill, mostly from runaways prevented and from the visibility into per-agent consumption that the audit log enables.

The dollar math

The numbers are simple. Per-agent quotas at a typical mid-market agent fleet:

The build cost varies because the implementation choices (Redis counters vs Postgres, structured errors vs not, adaptive promotion vs static caps) have different effort profiles. The lowest-effort version (a single daily cap per agent, hard-block on overage, structured errors) ships in two weeks; the full tri-window adaptive system with degrade support is a quarter of platform-engineer time.

The payback math works because the prevented-runaway saving is a real reduction in spend, not a forecasted one. The agent that would have burned $4,200 overnight burns $200 and stops. The cost ledger and the audit log show exactly how much was saved at each firing, which is the kind of receipt finance accepts as ROI evidence.

Per-agent quotas are not optional once an MCP server has more than three or four agents in production. The first runaway is a question of when, not if. Shipping the quota system before the first runaway costs a quarter of platform-engineer time; shipping it after the first runaway costs that plus the bill for the incident and the trust hit from finance. Set the default budget, wire the tri-window check, log the decisions, and stop relying on the morning Slack ping to catch agent runaways.