What a Skills-vs-MCP benchmark reveals about where models should reason, where code should execute, and what enterprise teams should measure.

My colleague David Parry, a principal architect, recently published a benchmark comparing an instruction-only skill, an MCP-backed tool, and a prompt-only baseline. His test gives us a useful way to examine an architecture problem: where should the work execute?

This was proof for me that token efficiency belongs in architecture review alongside latency, reliability, security, and operability.

Teams now have access to larger context windows, longer agent loops, more tools, more agents, and more retries. That capacity can be useful. It can also hide weak system design. If a model repeatedly recalculates a policy, reloads an entire rule catalog, or carries verbose tool results through a long workflow, the system is paying for the same work again and again.

The target should be the lowest responsible cost per verified outcome.

That measure forces us to account for more than the token count on one API call. It includes the model’s work, the tool path, retries, failures, verification, infrastructure, and the engineering required to keep the workflow trustworthy.

David’s experiment used one synthetic activity-recommendation workload. The customer request stayed constant while the execution path changed:

The benchmark ran 15 times for each of 9 model-and-configuration pairs, producing 135 stored responses.

The raw results expose a detail that token totals alone wouldn’t infer. On Opus 4.8, the tool-backed path used 2,632 mean total tokens, compared with 2,403 for the instruction-only skill. Yet the tool-backed path cost 32% less. It used more input tokens and far fewer expensive output tokens.

On GPT-5, the tool-backed path cost 76% less than the instruction-only skill and reduced mean latency from 16.1 seconds to 4.8 seconds.

Those numbers come from one workload, three models, and successful runs. They don’t settle every skills-vs-MCP decision. However, they do show why total token count is an incomplete metric. Input pricing, output pricing, reasoning-token accounting, cached input, model calls, tool calls, latency, and retries can change the result.

The benchmark also revealed an authoritative-state problem. Workflows that depend on current state need an authoritative source. MCP is one way to expose that source, but a skill script, local library, CLI, database, or existing API could do the same job.

Skills and MCP describe useful packaging and interface choices. They don’t establish the execution guarantee by themselves, though.

A skill can contain instructions, reference material, and executable scripts.

An MCP server can expose a well-tested deterministic capability or a weak service with unclear behavior.

A local script may be enough for one repository. An existing API may already own the authoritative business rule.

The engineering decision starts with this:

If a price, entitlement, compliance decision, or money movement must use deterministic code, an instruction that asks the model to call a tool is too weak. The workflow should require that path, validate the inputs and result, and fail safely when the capability is unavailable.

Paul Duvall’s centralized-rules repository shows another part of the same problem. The repository reports a 74.4% average reduction in estimated rule-context tokens for four Python and FastAPI task types by selecting two or three relevant rule files instead of loading all eight applicable files.

To be clear, it’s a static estimate based on rule-text size, not a provider-reported reduction in total billed tokens or end-to-end cost. Yet it still demonstrates a useful information-architecture choice: govern rules centrally, then load only the approved subset required for the current task.

Centralization and progressive disclosure solve different problems.

Centralization gives a team provenance, review, versioning, and distribution. Progressive disclosure controls what enters the model’s context. A centralized repository can still become an expensive prompt prefix if every rule is loaded for every task.

The enterprise pattern I would use has two parts:

This keeps governance centralized without turning runtime context into a dump.

Every agent workflow has at least four context decisions:

Large tool catalogs make this visible. Tool definitions, schemas, descriptions, and accumulated results all consume context. Loading every schema before the model knows what it needs increases standing cost and can make selection harder. Deferred discovery helps the model see a compact catalog first and load the full contract only when a capability becomes relevant.

The same principle applies to skills. Metadata can support discovery. Full instructions can load after activation. Reference files and scripts can stay out of context until the task needs them.

Available context is capacity. Architecture determines occupancy.

Moving repeatable work into code changes the cost surface.

Very small tools can create long call chains, repeated round trips, and repair turns. Very large tools can return too much data, hide several responsibilities behind one interface, and become difficult to test. The useful unit is a coherent capability with validated inputs, compact structured outputs, and a clear owner.

For large results, filter and aggregate near the data. Return the fields the next decision needs, along with a reference to the larger artifact when necessary. A model shouldn’t carry a full log, document, or catalog through every remaining step when a tool can return a count, a bounded result set, or a verification receipt.

Stable schemas also matter. Prompt caching can reduce the price of repeated input, but it doesn’t reduce the amount of context occupied. Constantly inserting, removing, or reordering tool definitions may save visible tokens on one request while weakening cache reuse across the workflow.

These are ordinary architecture trade-offs. And they belong in interface design.

I would model the cost of an AI workflow this way:

model input + model output and reasoning + tool runtime + retries + failure remediation + engineering and operations

Then I would divide that cost by verified outcomes, not attempted calls.

A short prompt that causes two repair turns may cost more than a longer, precise instruction. A cheaper model that violates a policy boundary creates review and incident cost. A local model may have no provider-token invoice while consuming meaningful compute and wall-clock time. A deterministic microservice can lower inference cost and still be the wrong choice when its deployment, security, and maintenance burden exceed the value of the rule it replaced.

Verification belongs in the equation because a plausible answer isn’t always a completed outcome.

For consequential workflows, deterministic components should return compact evidence that can be tied to the rule version, code version, inputs, authoritative data, and effective date used for the decision.

Enterprise teams need a repeatable way to examine these boundaries. I would put these questions into the architecture review:

These questions create a decision-placement rubric. They also make token use observable by source and stage, which is the only way to distinguish rule bloat from schema bloat, verbose results, repeated reasoning, and failure recovery.

Platform teams will need context budgets for standing instructions, activated skills, tool definitions, retrieved data, conversation history, completions, reasoning, and repair turns.

Tool owners will need typed contracts, field selection, pagination, timeouts, versioning, and clear failure behavior.

Teams that govern shared rules will need provenance, applicability, approval, deprecation, and a reviewable activation path.

They will also need architecture tests. A test should prove that the workflow invokes the deterministic capability every time it is required. Failure tests should cover malformed arguments, timeouts, stale data, version skew, and attempts by the model to recompute or override an authoritative result.