MCP servers could do anything, it just had no idea how! Most people aren’t running custom MCP servers, they just plug in a couple of community MCP servers and trust them to work. What remains untold is these servers are built for everyone, which means they’re optimized for no one! You give your agent a database tool. An email tool. A file management tool. Maybe a dozen more. It can enumerate them fluently. And then you ask it to do something moderately complex, like “process all invoices from last quarter and summarize by vendor”, and it stumbles. Not because it lacks the tools. Because no one told it how . We are looking at 2 problems here: Too many tools injected to your context upfront is costly and confusing. The agent interactions between the tools are unclear which makes the overall A gent E xperience poor. Both these issues are currently being addressed by the two ideas below: Lets Not Load All Tools Upfront: Search tools. Don’t ship them. More tools should mean more capability. In practice, it often means the opposite. As a tool library grows, an agent has to hold every definition in context and weigh every option before it can act , even when most of those tools are irrelevant to the task at hand. This leads to a real cost increase. A typical setup spanning a few connected services can add up to tens of thousands of tokens in tool definitions alone, before any work begins. And past roughly 30–50 available tools, an agent’s ability to select the correct one starts to decline. Anthropic addresses this with on-demand tool loading. Instead of loading every tool definition into context upfront, Anthropic searches a tool catalog serverside and loads only the tools relevant to the current request. Marking a tool as deferred is a one-line change: client = anthropic.Anthropic() response = client.messages.create( model="claude-opus-4-8", max_tokens=2048, messages=[{"role": "user", "content": "What is the weather in San Francisco?"}], tools=[ {"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"}, { "name": "get_weather", "description": "Get the weather at a specific location", "input_schema": { "type": "object", "properties": { "location": {"type": "string"}, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}, }, "required": ["location"], }, "defer_loading": True, # 👈 this is the whole idea } ], ) Lets Ship Skills Over MCP: Skills are context, and MCP is a context protocol. The result is SEP-2640 , a formal spec proposal submitted in April 2026. The core idea: expose skills as MCP Resources with a skill:// URI scheme. Zero protocol changes. Full backward compatibility. The server author ships both the tools and the know-how in a single atomic unit and when an agent connects, it gets both. The skill will be a separate resource, and the agent can be directed to read them first before doing anything else. mcp = FastMCP("IPInfo", instructions=( "Before using IPInfo tools, read the skill://ipinfo/usage resource " "for tool selection guidance and context reuse patterns." )) @mcp.resource("skill://ipinfo/usage") def ipinfo_skill() -> str: return SKILL_CONTENT What Now? Fixing these two problems doesn’t make MCP the default answer to everything. You still have to think about when MCP earns its place, when a CLI tool does the job faster, and where each one actually shines. A CLI script that runs in two seconds doesn’t need a protocol wrapped around it, and a protocol that scales across a hundred tools shouldn’t be replaced by a pile of scripts either. The most smart answer to all questions is “It depends”. 😁 The right tool was never about which one is best. It’s about which one fits the problem you’re solving right now.

Your API isn’t an MCP tool! What’s intuitive for humans often overwhelms agents. Discover how to design MCP tools with AI agents in mind — and why AgentExperience (AX) matters — in my latest article in AINativeDev.