Yesterday the maintainers of the Model Context Protocol published an updated roadmap, and buried in it is a sentence that describes something we've run into ourselves: connecting to a server with a hundred tools means the model pays for that entire surface before anyone has asked a single question, and tool selection gets worse as the list grows.

We know that problem firsthand. Anamnesis, the memory system we run internally, is an MCP server with 47 tools registered on it: memory tools, task tools, sprint tools, library tools, project tools. Every one of those 47 loads into context before a single question gets asked. The roadmap's description is clinical. The lived version is an assistant that used to reach for exactly the right tool starting to reach for the close-enough one instead, or quietly skipping a tool it should have used because the list got too long to hold clearly.

What Already Shipped

Most of the previous roadmap's work is already live. That earlier roadmap, published in March by lead maintainers David Soria Parra and Den Delimarsky, named four priorities: transport evolution, agent communication, governance maturation, and enterprise readiness. Most of it landed in the July 28 specification release. MCP servers stopped requiring session state or an initialization handshake, so a server can scale horizontally without holding onto who's connected (SEP-2575, SEP-2567). List results became cacheable (SEP-2549). Tasks moved into an official extension after early adopter feedback (SEP-2663). Authorization got real teeth, too: issuer validation, issuer-bound client credentials, and Enterprise-Managed Authorization went stable.

That's five months of unglamorous plumbing work. Most businesses running an AI integration will never notice any of it directly. They'll just notice their AI tools kept working, which is the point.

The new roadmap sets five priority areas for what comes next. Three of them (agentic messaging for long-running work, unifying local and remote servers onto one transport, and agent identity for workloads acting without a person present) matter most to the people writing server code. The other two are worth a business owner's attention even if you never touch a line of MCP yourself.

The Problem They Finally Named

The new roadmap says out loud something we'd only felt before, never seen admitted by the people who built the protocol. Its Improved primitives section states plainly that connecting an AI assistant to more tools doesn't just add capability. It taxes every request the assistant makes, and it degrades the assistant's judgment about which tool to reach for. The fix in motion is called progressive discovery: instead of a server dumping its entire catalog on the model up front, it offers a small entry point and reveals more of the catalog as the conversation narrows. Handing someone a phone book versus handing them a receptionist.

One Predictable Shape for Every Tool Result

Tool results are also getting standardized, closing a gap that's been quietly breaking integrations for a while. Right now a tools/call response can come back in more than one form, and a server developer has no reliable way to know which form the client on the other end will hand to the model. That ambiguity is exactly the kind of thing that turns "it worked in every test we ran" into "it broke on one customer's setup and nobody can tell why." Fixing it closes off a whole category of bugs that never show up until production.

What This Means If You Don't Write MCP Servers For a Living

Every AI tool you connect to your business makes every other one slightly worse at getting picked correctly, and that's a real limit inside the protocol, not a flaw in whatever product you bought. If you've been layering AI tools on top of each other, a chatbot here, an automation there, a CRM assistant, an internal ops tool, you're building the same kind of tool surface we built with Anamnesis's 47 tools. Its own maintainers just spent five months documenting that limit in public and are now actively fixing it.

Someone should be watching your tool surface the way you'd watch a database schema: what's on it, why, and what it costs to keep there. We built laravel-ai-action so the same action class that runs a form on your site can answer an MCP tool call without duplicating logic, and even with that in place we still have to decide which actions earn a spot on the tool list versus which ones just add noise. That call gets more important, not less, as progressive discovery lands and servers are expected to offer a small door instead of the whole building at once.

If you're trying to figure out what an MCP server actually is and whether your business needs a custom one built, or you're wondering why an AI feature that worked great with three integrations started acting strange at ten, this roadmap is the clearest public signal yet that the people building the protocol know exactly what's happening. Worth reading before your next AI integration decision, not after. Get in touch if you want a second set of eyes on the tool surface you're already running.