The original MCP design was a conversation shape: the client opens a session, the server holds per-session state, and the tools and resources are described once per connection. The shape is right for a laptop with one human. It breaks at a deployment where ten thousand agents open short-lived connections, where the server pool must scale request handling independently of session storage, and where the latency of a request is better as a property of the network than of the session's location. Statefulness also hid the cost: the protocol overhead - everything that is not the model call - was invisible in the model invoice, because it was not an event, it was the substrate, and the substrate does not appear on the line item.
What the stateless core actually changes
The 2026-07-28 revision made the core protocol stateless, and the three changes that matter economically are these:
- Multi-round-trip as design. A single client action is a defined sequence of request-response exchanges, not one stateful operation. The round trip, which was an implementation detail, becomes a countable event, and the countable event is the metering point.
- Header routing replaces session affinity. Requests carry what the server needs in headers, and any request can go to any server instance. The session-stickiness constraint that created hot pods and uneven fleets goes away, and the load on the fleet returns to the L4 shape it had before the sessions.
- Cacheable listings. The tool and resource listings carry explicit cache semantics with a stated refresh interval. A client can cache the listing once and serve every task from it until the interval lapses, instead of re-listing per session.
Telecoms made exactly this move in the circuit-to-packet shift of the late twentieth century: the circuit-switched network metered by connection duration, and the duration carried the cost of the conversation that used it, and the application's meaning was invisible to the meter. The packet network meters by packet, and only then by application meaning. The metering point moved from the connection to the unit of exchange. MCP just did the same move for the agent protocol: the round trip is now the unit of exchange, and the metering point is where the cost model attaches.
The economic consequence is that an agent task's cost decomposes into lines the stateful protocol carried in the dark: the model tokens (the visible line, on the LLM invoice), the round-trip overhead (a fixed protocol latency plus TTFT, per model call and per tool call), the listing cost (re-listing when the cache TTL lapses mid-task), and the rework cost (the step that acts on a stale listing, fails, and retries). The model bill was the entire perceived cost of the agent before the shift. After it, the model bill is one of four lines, and the other three are now budgetable, measurable, and attributable.
One protocol fact from the same window belongs in the metering design: on August 17, 2026, the A2A protocol moved into the Agentic AI Foundation. The inter-agent layer is standardizing on the same clock, and the same metering discipline (round trips, payloads, latency per leg) applies to A2A traffic the way it applies to MCP traffic.
What to meter first, in order
- Round trips per task. One per task is a configuration smell; one per tool call is the floor; a healthy task runs 3-10 tool round trips. Anything above 15 per task, regularly, is a spec or a loop problem, not a model problem, and the telemetry is the one that owns it.
- The tool-listing cache hit rate. The cacheable listing exists to be read from cache, and a hit rate below roughly 90 percent means the TTL is shorter than your tasks and you are paying the re-listing tax on most of them. The TTL should be matched to the measured task length, explicitly, and the hit rate is the readout of the match.
- Tool payload sizes, in bytes, per tool, per task. The tool output - the file read, the query result, the scraped page - is often larger than the user prompt, and it is fresh input tokens on every round trip that follows. Payload is input cost that the prompt template's budget does not see, and the per-tool measurement is the one that finds the oversized tool.
- Per-tool latency, P50 and P95. Header routing makes per-tool latency a deployment fact rather than a session artifact, and a healthy fleet is one where the P95 stays within 3x the P50. Above that is a flaky tool or a tool behind a slow dependency, and the telemetry can tell them apart, which the sessions could not.
What to do
- Count round trips per task, chart them weekly, and make the count a first-class SLO alongside token spend, because the stateless core made it countable, and the countable is what gets managed.
- Set the tool-listing cache TTL from your measured task lengths, in the same units, so the hit rate reads as a match metric and the re-listing cost becomes a budgeted line in the per-task cost.
- Add the tool payload to your per-task cost logging, in bytes and in token equivalents: the agent invoice's anatomy already has the line (the anatomy of an agent's API invoice), and the stateless spec is what makes the line measurable.
- Meter the per-tool latency per provider and per deployment, because after header routing the protocol overhead is a property of the deployment, not of the model, and the attribution is where the optimization lives.