Agent or MCP Tool: Microsoft’s Lesson

Microsoft shows that multi-agent systems often need an MCP tool, not a second agent, with economic and technical analysis.

  • An agent zoo costs money
  • The MCP tool as the unit economics of a skill
  • What changes technically
  • Where this already works beyond a demo

An agent zoo costs money

In the ski-resort demo case, Microsoft examined a common mistake made by multi-agent system architects: the orchestrator calls four specialist agents—for weather, slope safety, instruction, and lift capacity—through the A2A protocol, and each has its own model, prompt, and session history. The demo works, but Microsoft engineers asked an uncomfortable question: why does a specialist need a separate model if it only needs instructions and three API calls?

In the new version of Agent Framework, they move the specialist’s instructions into the orchestrator as an MCP tool.

For any company that has launched or is planning a multi-agent system, this changes the cost calculation.

Each new agent adds a separate model session, separate token billing, another failure point, and another deployment and monitoring pipeline.

The ski-resort demo case with four specialists already means four independent LLM calls for one user request, four places where the network can fail or the context can run out, and four sets of logs for the on-call engineer. In production, this becomes a cloud provider’s bill and an on-call engineer who cannot sleep.

The business sees the cost on the invoice six months later—the demo does not show it.

The MCP tool as the unit economics of a skill

  1. Microsoft’s key move: an avalanche-risk forecasting specialist does not need reasoning—only a function: a set of instructions and an external API call packaged as an MCP tool that the existing orchestrator invokes.

  2. There is one model, one session, and one context for the orchestrator.

  3. The economics are simple: an agent is an expensive unit (model + memory + quality evaluation), while an MCP tool is inexpensive (description + call).

  4. The rule is simple and strict: a specialist without reasoning is an MCP tool.

  5. Only make something an agent if it needs to reason over facts.

  6. Most “specialists” in real systems are procedures without reasoning—in other words, tools.

Assess where AI can deliver impact in your process

What changes technically

A2A remains appropriate where a specialist genuinely needs its own memory or multi-step negotiation—for example, a service that communicates with an external booking system and maintains state. MCP handles everything else: a weather API, risk scoring, or lift availability checks—tasks with clear inputs and outputs that require no internal reasoning.

The orchestrator describes the set of MCP tools once, and any model—Claude, GigaChat, or a local Qwen—calls them in the same way, without rewriting prompts for each “specialist.” This is where time to value lies: connecting a tool through MCP takes hours, while building and training a new agent from scratch takes weeks.

Where this already works beyond a demo

  1. Teams building LLM & Security Gateway and MCP integrations for enterprise customers face this choice on every project: a client asks for an “agent to check counterparties,” but in fact needs one call to the Federal Tax Service registry and one scoring call—with no separate reasoning at all.

  2. The architectural difference is the difference between a system that fails weekly across four different agents and one where a single orchestrator reliably calls a set of proven tools.

  3. A simple system looks simple from the outside precisely because an engineer has mapped out in advance where an agent is needed and where a function behind an MCP facade will do.

  4. A person makes this distinction before choosing a framework.

Conclusion

Before creating a new agent, ask Microsoft’s question: does this specialist really need a model, or does it only need API access with clear instructions? Nine times out of ten, an enterprise “multi-agent” system turns out to be one good orchestrator and a dozen MCP tools that someone neglected to formalize as tools. The savings show up in tokens, latency, and the number of things the on-call engineer must keep in mind at night.

Discuss the article: Agent or MCP Tool: Microsoft’s Lesson…

Enter your email or phone number so we can get back to you.

Send via: