What does it actually look like when AI agents become 20% of your API traffic?

At one production observability platform, nearly 20% of all monthly interactive queries now come from AI agents — that's a real usage metric cited in this week's MCP specification release, not a vendor projection. If you've published an MCP endpoint and haven't thought hard about what agent-scale traffic looks like, you're about to find out.

Where does this data come from?

This post draws on the 2026-07-28 MCP specification release, an independent analysis of 177,436 published MCP tools, and a study of around 1,400 production MCP servers. The spec itself is the primary source; third-party research fills in the deployment picture that official announcements leave out.

Has the MCP ecosystem actually grown that fast?

The download numbers are striking. The TypeScript and Python SDKs have each individually crossed one billion total downloads. Tier 1 SDKs as a group are now approaching 500 million monthly downloads. Weekly download velocity grew from around 80,000 at MCP's late 2024 launch to 14 million by February 2026, according to research analyzing 177,436 publicly available MCP tools — a 35× increase in just over a year.

But volume alone isn't the story. What's changed is what those tools are actually doing.

Are agents mostly reading data, or are they doing things now?

When MCP launched, roughly 73% of tool uses were read operations — fetching data, querying state, pulling documents. Action tools — the ones that modify external environments, like writing files, sending email, or executing transactions — accounted for around 27%.

By February 2026 that had flipped. Action tools now represent approximately 65% of observed tool calls, with read tools falling to around 35%.

This shift matters for rate limiting in a way that sheer volume doesn't capture. A misconfigured agent that reads the wrong data is annoying. A misconfigured agent that fires off payments or edits files at 500 calls per minute is a different category of incident entirely. When the dominant tool type is "does something irreversible in the world," the cost of a runaway loop goes up sharply.

What did the new spec actually change, and why does it matter for load?

The 2026-07-28 specification is the largest single revision to MCP since launch. The headline: the protocol is now stateless. The initialize handshake is gone. The Mcp-Session-Id header over HTTP is gone. Each request now carries its own protocol version, client identity, and declared capabilities.

For infrastructure, this is a real improvement. Standard round-robin load balancers work out of the box. No shared session store, no sticky sessions, no gateway-level connection tracking required. The new Mcp-Method and Mcp-Name request headers let gateways route traffic without parsing the JSON body of every request.

Two rate-limiting-friendly features also ship in the spec. List endpoints now support a ttlMs field — how long a client should cache the response — and cacheScope, which controls whether the cache applies globally or just per-connection. A cacheScope: "global" with a long ttlMs means well-behaved clients won't re-fetch your capabilities list on every new session. Set that once and discovery traffic drops substantially.

Enterprise-Managed Authorization (EMA) rounds out the release, giving corporate identity providers central control over MCP server access without per-user consent flows. OAuth handling is tightened in line with RFC 9207, requiring clients to validate the issuer field on tokens before code redemption.

The catch: stateless sessions lower the friction for agents to connect. That's good for legitimate usage. It also removes the handshake step that previously forced at least one round-trip before any tool could be called — a small but non-zero speed bump against automated probes.

What does the authentication picture actually look like right now?

Not encouraging. An analysis of around 1,400 production MCP servers found that approximately 38.7% had no authentication at all — any agent, from anywhere, could enumerate and call their tools with zero credentials. Of the 4,126 individual tools across those servers, 52% were read operations, but 25% were write operations and 23% were unclassified.

EMA and tightened OAuth requirements in the new spec address this gap — but only for servers that actually implement them. If your endpoint currently accepts unauthenticated requests, moving to stateless HTTP doesn't help you. There's no longer even an initialization handshake to slow down an automated client making its first probe.

What actually goes wrong when rate limits are missing?

The documented cases are specific enough to be instructive. Sentry's MCP server caps authenticated callers at 60 requests per 60 seconds per user. In team environments where multiple developers share the same API key for an integration, three or four parallel agent sessions saturate that budget in seconds — a common production failure mode.

More broadly, an AI agent session has been reported hitting a major API provider's 5,000-requests-per-hour limit in under two minutes. A separate retry loop that wasn't stopped early accumulated 127,000 calls in around eight hours; the resulting cloud bill came to approximately $47,000. Neither case is an extreme edge case. They happen when limits are tuned for deliberate human usage and then hit by software that generates tool calls at machine speed, treating each call as essentially free.

So what does this mean for site owners?

Three things worth doing now, in priority order.

Is your authentication actually enforced? If your endpoint accepts calls without credentials, fix that before anything else. An API key per caller with per-key request tracking is the minimum viable floor. EMA is the right long-term architecture for teams with existing enterprise identity management. Identity comes first because rate limits without caller identity are just IP-level throttling — and most agent traffic shares cloud egress ranges.

Are your rate limits calibrated for agent traffic, not human traffic? Per-IP limits won't catch parallel agent sessions from the same egress IP. Key your limits on caller identity — API key or client ID from the request — and use a token bucket with a burst allowance that can absorb a legitimate multi-tool workflow without triggering false positives. The typical agentic session chains eight to fifteen tool calls in rapid succession; your burst headroom needs to accommodate that.

Have you set ttlMs on your tools/list response? This is a low-effort win. If your tool definitions don't change frequently, returning a long ttlMs with cacheScope: "global" tells clients they can reuse the manifest across sessions. Discovery traffic drops materially; the apparent latency for new agent connections improves. It costs a single field in your response handler.

The 2026-07-28 spec didn't create the problem of AI agents generating unexpected traffic burdens on MCP endpoints. It made connecting cheaper, simpler, and more scalable — which means the issues you've been putting off are going to become harder to defer. When one production service is already reporting that agents account for 20% of interactive queries, "eventual" is closer than it looks.