The protocol got interesting again by doing less

A new version of the Model Context Protocol shipped this week, and the developer who spent last year explaining why the protocol had been eclipsed by simpler options wrote a post about being interested in it again. The reason is worth sitting with. Not new capability. The spec got smaller.

MCP, plainly, is a standard way to hand an agent a tool. A server publishes what it can do and the shape of the arguments, and the agent calls one. The old version needed two HTTP requests to get anything done, one to open a session and collect an ID, one to actually make the call. The new one is a single request with no session for anybody to keep track of. That is the change.

The concession in that post is the honest one. An agent with a terminal and curl could already do most of what these servers do, and do it more flexibly, which is exactly why interest drained out of the protocol in the first place. Then comes the turn. Handing a model a shell and an open network is much harder to reason about than handing it four tools with typed arguments. The stated plan is to lean on the protocol for anything sensitive.

The vault’s notes on tool interfaces have argued the same thing from the other side for a while. The durable rule is not to avoid MCP, it is to avoid unbounded tool buffets, and the best interface exposes the minimum safe capability with clear schemas and visible receipts.

There is a second effect that gets less attention. A narrow, typed tool surface can be driven by a small model running on a laptop. An open shell needs a strong model to drive it well, and a lot of trust to hand over at all.

Three working tools got built on the new spec in a week, by one person, mostly with a coding agent. Easy to implement is a boring property. It is also the one that tends to decide which standards are still around in three years.