MCP Is No Longer A Draft. It Won.

Three weeks ago no one would have bet on this.

We spent all of 2025 arguing about agent frameworks. LangGraph vs AutoGen vs AgentScope vs Camel. Every week a new one launched. Every one had a different way to call tools. None of them talked to each other.

That fight is over. Nobody won it. MCP did.

Over the last 30 days, every significant new agent project shipped with native MCP support. Robotics. Trading. Penetration testing. Evaluation infrastructure. Educational material. All of them converged on the same wire protocol, the same tool discovery interface, the same trust model.

This is not coordination. This is every independent team arriving at the same conclusion at exactly the same time. MCP is good enough. It solves the actual hard problem everyone was stuck on. And it is now the default way to build agent systems.

The quiet standard that won

MCP did not win on technical merit. It won because it was the only proposal that did not try to own the whole stack.

Every prior agent standard tried to dictate how you write prompts, how you orchestrate turns, how you store memory, how you do planning. MCP does none of that. It only defines one thing: how an agent discovers and calls tools that live somewhere else.

That is it. That is the entire standard. And that is exactly what everyone needed.

No one wants to lock their tools to one agent framework. No one wants to rewrite their weather API wrapper 7 times for 7 different runtimes. No one wants to maintain 12 different function calling schema formats.

MCP solves exactly that one problem. It does nothing else. And for that reason, everyone adopted it.

What MCP actually solves that no one talked about

Before MCP, every tool was part of the agent process. If you wanted your agent to check the weather, you installed that weather code into the same runtime as the LLM loop.

This was a disaster for three reasons:

1. Every tool dependency became an agent dependency. You could not add a new tool without rebuilding and redeploying the entire agent.
2. There was no trust boundary. Any tool could read every other tool's state, modify the agent runtime, or crash the whole process.
3. Tools could not be shared. If I wrote a good stock quote tool, you could not use it unless you copied my entire codebase.

MCP fixes all three. Tools run as separate processes, separate servers, separate deployments. They speak a common protocol. Agents discover them at runtime. They call them over the network.

This is not an incremental improvement. This is a complete inversion of agent architecture.

The agent is no longer the center of the system. The agent is just a client. All capability lives out on the network, in tools.

Reachy Mini: the first good production MCP implementation

Most MCP demos are toys. Reachy Mini is not. It is the first production system that got MCP right, and every other implementation is already copying its patterns.

Reachy is a small humanoid robot. Until last month all its tools were baked into the app. Move head. Play emotion. Use camera. Every change required a full firmware update.

Now you add a new tool with one command:

reachy-mini-conversation-app tool-spaces add pollen-robotics/reachy-mini-weather-tool

That is it. No rebuild. No restart. The next time you talk to the robot it can check the weather.

The pattern they landed on is now the reference implementation for every MCP system:

All tools are registered in a single flat registry. A plain text file called tools.txt acts as the gatekeeper. If a tool name is not listed in this file, the agent will never even see it. It will not be included in the prompt. It can not be called.

This is brilliant. It is dead simple. It is auditable. You can read the active capability set of an agent in 10 seconds by catting one 10 line file.

There is no magic. No policy engine. No RBAC. Just a list. And it works perfectly.

Namespacing is handled with a double underscore. Remote tools get a prefix derived from their source slug. No collisions. No surprises.

pollen_robotics_reachy_min_search_tool__search_web
pollen_robotics_reachy_min_weather_tool__get_day_brief

This is not fancy. This is correct.

Every MCP implementation built in the last two weeks copies this exact naming convention. Every one copies the tools.txt gatekeeper pattern.

Trust boundaries and the profile gatekeeper pattern

The most important insight from Reachy Mini is almost never mentioned.

Capability is not granted at install time. It is granted at profile activation time.

You can install 100 tools. None of them will be used until you explicitly add their ID to the active profile.

This solves the hardest unsolved problem in agent security: you always know exactly what an agent is allowed to do.

There is no hidden capability. There is no tool that got added by a dependency. There is no surprise. The entire allowed surface is enumerated explicitly in plain text.

This pattern is so good it is spreading to every domain.

Trading agents: MCP for bounded autonomy

Vibe-Trading is the fastest growing agent project on Github right now. It is also built entirely around this exact MCP trust model.

When you connect this agent to your brokerage account, you do not give it permission to trade. You write a mandate.

That mandate is a plain text list:

• Allowed symbols
• Maximum order size
• Maximum daily exposure
• Maximum leverage
• Hard expiry time

The agent can not do anything outside that list. The MCP server enforces every constraint before any order reaches the broker.

There is also a filesystem kill switch. Create an empty file called halt in the working directory. All trading stops immediately. No API calls. No delays.

This is how autonomous agents should work. You do not trust the LLM. You do not trust the agent framework. You put a hard gate at the tool boundary.

The agent can propose anything it wants. The MCP server decides if it is allowed to happen.

As of June 2026 this pattern works across 7 different brokers. All of them expose the exact same MCP interface. You can swap brokers without changing a single line of agent code.

HexStrike: when you give 150 security tools to an agent

If you want to see how fast this is moving, look at HexStrike AI.

It is an MCP server that exposes 152 standard penetration testing tools. Nmap. Sqlmap. Nuclei. John the Ripper. Every tool a human pentester would use.

You install it once. Then any MCP compatible agent can use every one of those tools. Claude Desktop. Cursor. Roo Code. Any custom agent you write.

None of them need to know anything about penetration testing. None of them need to be modified. They just see a list of tools. They call them. They get results back.

This went from zero to 4000 Github stars in 9 days.

It is already being used for bug bounties. It is already being used for internal security audits. And every single person using it is running exactly the same trust boundary pattern:

1. Install the MCP server
2. Write a profile that lists exactly which tools the agent is allowed to call
3. Never give it write access to anything outside the test environment

No one is arguing about prompt guardrails. No one is arguing about agent alignment. Everyone is just putting a hard gate at the tool layer.

Training agents properly: NVIDIA NeMo Gym

If you want to see where this is going next, look at NVIDIA NeMo Gym. It launched 10 days ago.

NeMo Gym is a standardised environment for training and evaluating agents. Every environment it exposes speaks MCP. Every agent harness it supports speaks MCP.

For the first time you can take exactly the same agent, exactly the same tool set, and run it:

• For evaluation against 47 different standard benchmarks
• For RL training at 1000 concurrent rollouts per GPU
• In production connected to real tools

There is no translation layer. There is no schema conversion. The exact same wire protocol used for production is used for training.

This was the missing piece. Until now training environments and production environments were completely separate systems. You trained an agent on a mock tool interface. Then you crossed your fingers it would behave the same way with real tools.

That is gone now. You train on exactly the same MCP interface you run in production.

The gap everyone is ignoring: education

All of this happened so fast almost no educational material has caught up.

The one exception is Hello-Agents from Datawhale. It is a full open source course that teaches agent architecture from first principles. It has 41,000 Github stars. It was updated last week to make MCP the core protocol for all multi agent communication.

This is the only course right now that is teaching the model people are actually using. Every other agent tutorial is still teaching 2025 era framework specific tool calling. All of that material is already obsolete.

The course makes one point that almost everyone misses. There are now two kinds of agent developer:

1. People who build agents
2. People who build tools that all agents can use

The second group is 100x larger. And almost no one is teaching it.

The three unsolved problems right now

This is all moving extremely fast. There are three obvious gaps that no one has solved yet:

1. Tool discovery. Right now you have to know the exact slug of a tool space to install it. There is no public searchable registry. There is no rating system. There is no way to verify that a tool does what it says it does. This will be the next big fight.

2. Audit logging. Every MCP implementation has ad-hoc logging. There is no standard format for tool call traces. There is no standard way to replay an agent run. There is no standard way to prove what an agent did, and when.

3. Parallel execution guarantees. Prompts can encourage an agent to call multiple tools in parallel. They can not force it. Right now every agent will randomly serialize tool calls for no reason, adding unnecessary latency. This logic will have to move out of the prompt and into the MCP client layer.

None of these are hard problems. They just have not been standardised yet. All three will be solved before the end of the year.

What comes next

We are not going to have one dominant agent framework. We are not going to have one dominant agent runtime.

We are going to have hundreds of different agents, thousands of different tools, all speaking the same protocol.

Any agent will be able to use any tool. Any tool will work with any agent. Capability will be composable. Trust will be handled at the boundary.

This is not a possible future. This is what is being built right now. Every project covered here is running in production today. All of them are open source. All of them are converging on exactly the same model.

The agent framework wars ended last month. Nobody noticed. MCP won.

Now the actual work starts.