Here is a small feature with a large idea inside it. Deploy an agent on LangGraph's managed runtime — LangSmith Deployment, the service formerly named LangGraph Platform — and the Agent Server stands up a /mcp endpoint for you. The moment the server is live, every agent you deployed is registered as an MCP-compatible tool, reachable over streamable HTTP, discoverable and callable by any MCP client with no extra code. Your agent didn't just ship. It became a tool.

That is genuinely useful, and it's the cleanest demonstration yet of a shift that's been creeping up all year: the line between an agent and a tool is now a deployment decision, not a fact about what you built. The same LangGraph graph is an autonomous agent when you talk to it directly and a callable tool when another agent reaches it through /mcp. Recursive composition — agents calling agents as tools — without A2A, without Agent Cards, without a line of glue.

Before you wire your whole org chart of agents together this way, look closely at what the /mcp boundary does to an agent on its way through.

A tool call is a flattened agent#

MCP's tool surface is request/response. A client sends arguments, the tool runs, a result comes back. One shot in, one result out. That model is perfect for what tools have always been — a function with a typed signature — and it is exactly what an agent is not.

An agent's defining affordances are the ones that don't survive a single request/response:

Exposing an agent as a tool is lossy compression. The bytes you drop are precisely the ones that made it an agent and not a function.

This is not a knock on the /mcp endpoint. It's the whole reason A2A exists as a separate protocol rather than a feature of MCP. The two were not built to compete — both now sit under the same Agentic AI Foundation — and the standing advice is to use MCP for tool access and add A2A for agent-to-agent delegation. MCP points your agent down at tools; A2A points it sideways at peers. When you publish an agent on /mcp, you are choosing to put a peer on the down-plane. Sometimes that's right. Sometimes you've just turned a colleague into a vending machine.

The decision rule#

The question to ask before exposing an agent as an MCP tool is not "can I?" — LangGraph makes it one toggle — but "does this agent need to stay an agent across the call?"

Expose it as a tool when the call is self-contained and fire-and-forget. A research agent that takes a query and returns a finished report. A classifier. A well-bounded transformation that runs in seconds and never needs to ask you anything. Here the flattening costs nothing, because you weren't using the affordances you gave up. You get recursive composition for free and a clean, typed surface other agents can call without knowing there's an agent behind it. That opacity is a feature: the caller composes a capability, not a personality.

Keep it behind A2A — or in-process as a subagent — when the callee must remain an agent. Long-running jobs that need status. Work that might come back to you for a clarification. Anything that has to act under its own identity and leave its own audit trail. Force one of these through a tool call and you'll feel it as timeouts, guessed-wrong parameters, and an observability hole exactly where the nested agent did its work — your trace shows one tool call and a result, with the agent's entire reasoning sealed inside it.

The convenient framing of 2026 is that agents and tools have merged — same artifact, expose it however you like. The truer framing is that you now have two planes to call an agent on, and they encode different contracts. The tool plane gives you composition and hides the agent. The agent plane preserves the agent and costs you glue. Picking the plane is the design decision. The /mcp toggle just makes it easy to make without noticing you made it.