Skills Over MCP vs Specialist Agents: Microsoft's Own Trace Says Fewer Calls, More Tokens
What happens when you delete the model from a specialist agent and keep only its instructions and tools
Most specialist agents in a multi-agent system do not need to think. They need to read a procedure, call two functions, and hand back a number. Microsoft's Agent Framework team tested what happens when you admit that, and the answer is stranger than the marketing on either side of the A2A-versus-MCP argument: the version with no specialist models was more than twice as fast and used half the model calls, and it also consumed 22 percent more tokens.
That is the whole post in one sentence, and it is worth a careful read because it is one of the few multi-agent write-ups that publishes its traces instead of its opinions.
The experiment
Tommaso Stocchi, a cloud solution architect at Microsoft, has a ski-resort demo that has been through a few architectures. The original version is textbook: a resort advisor agent takes the user's question and delegates to four specialist agents (weather, safety, ski coaching, lift traffic) over Agent-to-Agent. Each specialist has its own instructions, its own tools, and its own model loop. The advisor sees each one as a function it can call, waits for the specialist to reason and reply, then reasons again over the replies.
On September 16 he published the second architecture alongside it. Same four domains, same remote services, same data. The difference is that each specialist stopped being an agent. Its system prompt became a SKILL.md. Its functions became typed MCP tools with input and output schemas. Its model loop was deleted. The advisor loads the skill's instructions when it decides the domain is relevant, receives that provider's tool definitions on the next model iteration, and calls the operations itself.
Stocchi's own framing of the distinction is the sharpest line in the piece: the choice is between "delegating a task to another reasoner versus giving the current reasoner a competence and access to its operations." A distributed skill, in his words, "is not an agent wrapped in Markdown."
He sent one prompt through both paths three times each, with a fresh conversation every run and at least 65 seconds between them: "considering weather and waiting time, where should i start?"
The numbers
Here is the table, reproduced from the post with nothing changed.
| Pair | Architecture | Elapsed | Input tokens | Output tokens | Total | Model calls |
|---|---|---|---|---|---|---|
| 1 | A2A specialists | 16.416 s | 2,971 | 578 | 3,549 | 6 |
| 1 | Native MCP skills | 8.661 s | 4,341 | 178 | 4,519 | 3 |
| 2 | Native MCP skills | 5.866 s | 4,337 | 165 | 4,502 | 3 |
| 2 | A2A specialists | 12.835 s | 2,974 | 580 | 3,554 | 6 |
| 3 | A2A specialists | 17.188 s | 3,394 | 637 | 4,031 | 7 |
| 3 | Native MCP skills | 4.517 s | 4,341 | 171 | 4,512 | 3 |
The skills path used exactly three model calls every time: one to load the two relevant skills, one to call one weather tool and one lift-traffic tool, one to write the answer. The A2A path used six, six, and seven, because every specialist runs its own two-call loop (interpret the delegated question, then write a reply) on top of the advisor's two. Mean elapsed time was 6.348 seconds for skills against 15.480 seconds for A2A.
And the skills path burned more tokens on every pair. Across the three runs, 13,533 observed tokens against 11,134, about 22 percent more. Look at the input column and you can see why: 4,341 input tokens on the skills side versus 2,971 on the A2A side in pair 1. When you delete the nested loops, the instructions, the tool schemas, and the tool results all pile up in one context window instead of being split across four smaller ones. Stocchi breaks down the first skills run as 866, 1,593, and 1,882 input tokens across its three calls. The context grows every step.
Output tokens tell the opposite story. The A2A path produced 578 to 637 output tokens per run because each specialist writes prose that the advisor then has to read and rewrite. The skills path produced 165 to 178, because tool results come back as structured records rather than paragraphs.
What the post refuses to claim
This is where the write-up earns trust. Stocchi lists the reasons you should not read the table as a benchmark, and he lists them before the takeaway rather than in a footnote.
The processes were reused and warm. The skills runs reported 1,536 to 3,072 cached input tokens per run, and the A2A specialist spans did not report cache counters at all, so "whole-system cached input is therefore unknown, not zero." That means the token totals are tokens, not cost. Cached input, uncached input, and output are priced differently, and the post says plainly that "these measurements report tokens, not a dollar comparison."
The two paths did not do identical work. A2A called both GetWaitTimes and SuggestLessBusyArea; the skills advisor called only lift_traffic_least_busy_area. In pair 3 the A2A advisor also consulted the coach, which asked for the skier's ability level, adding a seventh call and a more complete answer. All six responses recommended the same lift, but "faster responses do not establish equally correct or complete advice."
There is also a trap in the other direction that I had not thought about. If you measure the A2A path by the top-level API's reported usage, you get 1,751 tokens for the advisor in pair 1. The weather specialist added 633 and lift traffic added 1,165. Comparing only the top-level number would miss more than half the request's tokens. Anyone who has been told their multi-agent system is "cheap" based on a single dashboard should go check where that dashboard is measuring.
My read: the decision is about where context accumulates
The A2A-versus-MCP framing gets the question wrong. Stocchi says this himself, and the numbers back him up. A2A and MCP address different boundaries. An autonomous component with its own model, private context, and a long workflow should stay an agent. A bounded competence that reads a procedure and calls typed operations should become a skill. The ski demo keeps a web-research agent as a real agent in both architectures precisely because it needs autonomy.
What the table measures is something more specific: the cost of a nested reasoning loop. Every specialist agent you add is a model that has to read a delegated question, decide which of its own tools to call, and write prose about the result for a parent that will read the prose and reason again. The skills architecture deletes that loop and pays for it in context growth. Three calls, one context, everything accumulates. Six calls, five contexts, nothing accumulates but nobody shares.
So the honest tradeoff is latency and call count against context size, and the right answer depends on the shape of your catalog. Four skills and twelve tools fit in one context with room to spare. Forty skills and four hundred tools do not, which is why Stocchi's demo defers tool exposure until a skill is loaded, using middleware that binds a successful load_skill to that provider's tool catalog. He also says that for a small catalog you can skip the middleware entirely and register the MCP tools up front.
The other thing the skills architecture buys you is that domain ownership survives. The weather service still runs on its own host, owned by its own team, deployed on its own schedule. What moved was the reasoning, not the service. That is a real organizational benefit that the token count does not capture.
Put this into practice
The lowest-friction first step is a measurement, not a migration.
Pick one specialist agent in a system you already run. Pull its traces for ten representative requests and count three things: how many model calls it makes per delegated task, how many output tokens it produces, and how much of its system prompt is procedure (do X, then Y, report Z with units) versus judgment (weigh these factors, decide if the request is safe). If the prompt is mostly procedure and the specialist averages two calls and a paragraph of prose per task, it is a skill wearing a model.
Second, separate the competence from the runtime before you change any protocol. Stocchi's step one is to split a specialist into its instructions, its model runtime, and the functions that reach the business system. The functions are the reusable part. Keep validation, business rules, and data access in code; a skill can describe how to paginate but it does not persist a cursor, and it can explain an approval step but it does not enforce authorization.
Third, write the SKILL.md from the old system prompt, then strip the assumptions about an independent conversation. His illustrative weather procedure is four numbered steps: which tool for current conditions, which for forecasts and with what integer range, which for storm status, and a rule to report units and not invent observations. The tool names in the procedure match the MCP tool names, and MCP supplies the schemas. Do not put endpoint configuration, authentication, or transport details in the skill; those stay infrastructure.
Fourth, keep the old path live and compare. Route the same prompts through both, compare routing decisions, data correctness, and structured results, and only then move traffic. If you are on Microsoft Agent Framework, the pieces are SkillsProvider, MCPSkillsSource, and a small middleware in the demo repo (native_mcp.py at commit 56f453a) that connects a loaded skill to its tools.
Fifth, if you are building the server side, target the final spec. MCP SEP-2640, the Skills Extension, was merged and marked Final on September 13 with the extension identifier io.modelcontextprotocol/skills. It serves skills over the existing Resources primitive under a skill:// URI scheme and adds skills/list and skills/get methods. The Microsoft demo was checked against a draft on September 10 and uses a skill://index.json convention rather than those methods, so it is already one revision behind the spec it cites.
Honest limitations
This is three prompt pairs on one demo with one model (gpt41), reused processes, and partial cache reporting. It is a well-documented illustration, not a study, and the author says so.
The skills path did less work in every run. It called one lift tool instead of two and never consulted the coach. Some of the latency gain is architectural and some of it is simply answering a narrower question.
The token comparison cannot be turned into a cost comparison from the published data, because the A2A side's cache usage is unknown. If your provider prices cached input at a steep discount, the 22 percent token overhead on the skills side may cost less than it looks. It may also cost more. You cannot tell from this table.
Neither this run's repo check nor a second pass could find a LICENSE file in the demo repo at the commit the post pins, so you can read the code but the terms for reusing it are undefined unless one has been added since.
And the safety observation is uncomfortable: every skills response, and the first A2A response, used safety language without consulting the safety provider. Moving reasoning into the orchestrator means the orchestrator decides which competences to load, and here it decided it did not need the one about safety. That is a routing bug you would never see in a system where the safety specialist always runs.
Where this leaves you
If you have a specialist agent whose prompt is a procedure and whose output is a paragraph, you are paying two model calls and a few hundred output tokens per task for reasoning that a typed tool result would replace. Microsoft's trace says you can cut that in half and finish in a third of the time. It also says you will carry more context and you will have to watch which skills the orchestrator chooses not to load.
Measure your own loops before you believe either number. The table is public, the repo is pinned to a commit, and the spec went Final four days ago. The rest is your workload.
Sources: Microsoft Agent Framework blog, September 16, 2026 · MCP SEP-2640 Skills Extension (Final) · PR #2640, merged September 13, 2026 · tommasodotNET/ski-resort-demo at 56f453a · Agent Skills specification
Medium metadata
Title: Skills Over MCP vs Specialist Agents: Microsoft's Own Trace Says Fewer Calls, More Tokens Subtitle: What happens when you delete the model from a specialist agent and keep only its instructions and tools Tags: MCP, Multi-Agent Systems, AI Agents, Microsoft Agent Framework, Software Architecture Canonical: fervorai.dev (import from the published URL)