After building seven MCP servers with 52 tools across nine external APIs, the protocol's limitations become sharp. MCP excels at connecting agents to tools. It does not yet help agents understand what those tools mean, or safely act on what they understand.
These are the six changes, grounded in production experience rather than speculation, that would raise the floor for every server in the ecosystem.
1. Smarter tool discovery
Today, every connected MCP server dumps all its tools into the agent's context at once. For a single server with 10 tools, that's fine. For a developer in an IDE with 10 servers connected simultaneously? That's 100+ tool descriptions competing for context.
This has a chilling effect on metadata investment: why write 200 lines of rich domain knowledge per tool if the client is going to flood the context with everything?
The spec needs a discovery layer: DNS for tools. Let servers declare tool groups with short summaries. The client presents groups to the model, the model selects the relevant group, and only those tool definitions are injected. Resolve first, load second.
2. Extensible metadata without context flooding
All metadata currently goes into tool descriptions and input schema descriptions, both consuming context tokens on every call. There's no mechanism for metadata the agent can request on demand.
A tool could declare 200 lines of field-level documentation, cross-reference tables, and query strategy guides as structured metadata. The client loads the tool's name and short description by default, but injects the full metadata only when the model indicates it wants to call that tool.
This would eliminate the trade-off between rich documentation and context efficiency, a trade-off that currently forces server authors to compress critical domain knowledge into artificially short descriptions.
3. Resources that actually work
MCP Resources are the spec's answer to reference documentation: static or dynamic content that agents can request to inform their reasoning. In theory, perfect for domain guides and field dictionaries.
In practice, no tested client reliably surfaces resources to agents. Claude Desktop lists them in a sidebar but agents don't request them. Claude Code and Cursor ignore them entirely. I built resources, tested them, and removed them after validation showed zero agent-initiated requests.
For resources to work, clients need to either: automatically inject relevant resource content when a related tool is selected, allow servers to mark resources as required context for specific tools, or give the model an explicit get_resource primitive that it's trained to use.
4. First-class feedback loops
The current spec has no concept of agent-to-server feedback. Every interaction is request-response: call a tool, get data, move on. No standard way for agents to report confusion, flag data quality issues, or indicate which calls were unhelpful.
I solved this with a custom report_problem tool and queryIntent parameters on every input schema. This works, but it's a workaround. The spec should support feedback as a first-class primitive: a standardized way for agents to annotate tool calls with intent, satisfaction, and issues encountered. Server authors could subscribe to feedback events and improve metadata iteratively, closing the loop that currently requires custom infrastructure.
5. Agent training on MCP patterns
Perhaps the most impactful change would happen not in the spec but in model training. Current models are not trained on rich MCP interactions. They don't know that a WHEN TO USE block should be parsed differently than a generic API description. They don't understand that .describe() annotations on output schema fields are there to be read and used.
If model providers included rich MCP server interactions in their training data (tool descriptions with domain metadata, multi-tool sequences with cross-references, feedback loops with intent parameters), agents would naturally leverage the metadata that server authors invest in writing. The metadata is already machine-readable. The models just need to be taught to read it.
6. Scoped write permissions for MCP Apps
As servers evolve from read-only to interactive applications, write operations become inevitable. But the spec offers no mechanism to restrict a write tool to a specific interaction context. If a server exposes a POST tool, any connected agent can call it at any time.
I designed a workaround: the WriteIntent pattern. The agent calls a model-visible "open" tool that mints a server-side intent. The actual mutation is performed by a separate "commit" tool registered with visibility: ["app"], hidden from the agent, callable only by the MCP App form. The intent is user-bound, resource-scoped, one-shot, time-limited, and validated with typed schemas.
The spec should formalize this: a way to scope write tools to specific MCP apps, so that a tool marked as write-only-via-app can only be invoked through a validated form interaction, not through freeform agent reasoning.
All six recommendations share a common theme: the spec is designed for transport, but the real challenge is knowledge delivery and safe interaction. Addressing these gaps at the framework level would raise the floor for every server, not just the ones built by teams willing to invest 40 hours in metadata engineering.
For the full context behind each recommendation, including the production evidence and implementation patterns, grab the practitioner report.