Stop Asking for MCP: The Better Agent Standard Is Already Here
A revealing pattern is emerging in enterprise AI procurement. A vendor ships a command-line interface and an Agent Skill for its platform. Prospective customers push back. They do not want the skill. They want a Model Context Protocol server.
The vendor has already built the more efficient interface. The customers demand the more expensive one.
That is the Model Context Protocol trap. Vendors are not forcing it on enterprises. Enterprise buyers are asking for it because “Does it have an MCP server?” has become shorthand for “Is it agent-ready?”
The instinct behind that question is sound. Enterprises need standards. They cannot build a custom integration for every agent, application, and data source. Anthropic introduced the Model Context Protocol to solve exactly that problem: replace fragmented connectors with a common way for AI systems to reach tools and data.
The mistake is assuming that a standard connection is an efficient connection.
It is not.
You Pay for the Tools the Agent Never Uses
An agent needs to know what tools it can call. In a common MCP implementation, that means putting tool names, descriptions, and input schemas into the model’s context. Anthropic’s own tool-use documentation is explicit: the contents of the tools parameter count as input tokens, including tool names, descriptions, and schemas.
The agent pays that context cost before it has used a single tool.
One server might expose a handful of tools. Another might expose dozens. Connect several servers, and the agent can begin every task carrying instructions for capabilities that have nothing to do with the outcome you asked it to produce.
Then the agent takes another turn.
It inspects a result. It asks a follow-up question. It corrects a malformed call. It retries after a timeout. The tool catalog remains part of the conversation while the useful work continues around it.
The toll is not paid once. It is paid every turn.
Scalekit tested this directly in 75 benchmark runs comparing command-line tools and MCP. The benchmark used the same model, prompts, and GitHub tasks. Direct MCP consumed between four and 32 times as many tokens as the command-line interface. GitHub’s MCP server exposed 43 tool schemas automatically, while the agent generally needed one or two.
The benchmark does not prove that every MCP deployment has the same multiplier. It proves the mechanism. Eager schema exposure spends tokens describing tools that do not contribute to the outcome.
That is waste.
Stop Measuring How Many Tools You Connected
Enterprise AI teams still celebrate the wrong metric.
They count models deployed, copilots licensed, agents launched, and tools connected. None of those numbers tell you whether the system is creating value.
The measure that matters in the agentic era is outcome per token.
Every token should help the agent understand the problem, choose an action, recover from uncertainty, or produce the result. Tokens spent repeatedly describing unused tools do none of those things.
A demonstration proves an integration works; it does not reveal what the architecture costs when thousands of agents carry it through thousands of multi-turn workflows. That is why pilot economics are lies when they exclude production scale. The bill appears after the architecture has hardened and procurement has become infrastructure. Token-maxing is not a strategy for the same reason: token consumption needs a business outcome paired with it. More tokens do not become valuable merely because an agent consumed them.
Ask a harder question of every integration:
What business outcome did these tokens buy?
If the answer is “they described 41 tools the agent did not use,” you have found an architecture problem.
The Vendor Is Not the Villain
It would be easy to blame software-as-a-service vendors for rushing out MCP servers and calling the job finished. That would miss what is actually happening.
Vendors respond to buyers.
If enterprise customers demand MCP, product teams will build MCP. If request-for-proposal checklists treat MCP support as evidence of maturity, vendors will add the checkbox. If a company already offers a skill and command-line interface but prospects reject them, the company has little reason to keep arguing with the market.
The problem sits upstream of the vendor. Buyers have adopted a technical preference before developing the economic sophistication to evaluate it.
Anthropic’s role deserves scrutiny too. Anthropic created MCP, and Anthropic sells token-priced inference. Its API documentation explains that tool definitions add input tokens and that total input and output tokens determine request cost.
That does not prove Anthropic designed MCP to burn tokens. We do not need a conspiracy theory. The incentive is visible without one.
An inference provider has no natural business pressure to minimize inference consumption on your behalf. That does not make the provider evil. It makes the provider the wrong party to define your efficiency strategy.
Asking an inference company to set your token discipline is like asking an oil company to design your fuel-efficiency policy. Listen to its engineers. Use its products. Do not outsource the meter.
A Well-Made Skill Beats a Well-Made MCP Server on Efficiency
Every time.
A well-made skill begins with a small piece of metadata that tells the agent what capability exists and when it applies. The agent loads the full instructions only when the task triggers that skill. It reads supporting references, scripts, and examples only when the work requires them.
A well-made, agent-first command-line interface continues that disclosure pattern. Its top-level help shows the available command families. Subcommand help reveals the relevant flags and examples. Structured output gives the agent the data it requested without wrapping the result in more explanation than it needs.
The agent carries a map. It does not carry the territory.
This is not an informal convention. The Agent Skills specification defines progressive disclosure in three stages:
- Load lightweight name and description metadata for discovery.
- Load the full
SKILL.mdinstructions when the skill activates. - Load scripts, references, and assets only as the task requires them.
I have already used the same principle on the output side in The Artifact Pyramid. Agents work better when they receive the smallest useful layer and can descend into detail on demand. The principle applies just as strongly to tools.
Discover cheaply. Load selectively. Execute precisely.
The MCP Community Is Reaching for Skills
The strongest evidence for this argument is coming from inside the MCP ecosystem.
The Agentic AI Foundation’s Angie Jones wrote that skills already teach agents while avoiding context bloat. She described the combination of the Playwright command-line interface and its skill as producing quicker sessions, fewer errors, and lower token spend.
The foundation now has a Skills Over MCP working group exploring how MCP servers can distribute Agent Skills through the protocol’s Resources feature. The proposal uses a lightweight skill catalog, then lets the agent fetch complete instructions and supporting files only when needed.
That work is useful. MCP needs progressive disclosure. Agent Skills already has it.
Even when MCP becomes the transport for a skill, the skill is doing the efficiency work. The Agent Skills specification remains the owner of the format. MCP becomes one way to deliver it.
Enterprises do not need to wait for that work to mature. They can adopt the standard now.
Change What You Ask Vendors to Ship
Stop requiring MCP by default.
Ask vendors for an Agent Skill paired with an agent-first command-line interface. Require the skill to follow the agentskills.io specification. Require progressive disclosure in both the skill and the CLI help system. Require structured output, non-interactive execution, useful errors, and safe previews for destructive actions.
Then audit the MCP servers already inside the enterprise. Inventory every connected server and measure how much context its schemas add. Compare exposed tools with tools actually invoked. Calculate the outcome produced for the tokens consumed. Replace inefficient integrations with skills and agent-first CLIs. Repeat the audit as the agent fleet grows.
MCP can still carry value where its authorization, tenant isolation, remote access, or governance model solves a real problem. Those benefits belong in the outcome side of the calculation. They do not make context overhead disappear.
Do not accept “standard” as the end of the evaluation. Demand evidence that the standard earns what it costs.
Groktopus Endorses Agent Skills
Groktopus endorses Agent Skills as the better default standard for giving agents new capabilities and operational knowledge.
It is open and portable. Progressive disclosure is part of the architecture. It works with command-line tools that enterprises can inspect, test, compose, and run without handing control of every interaction back to an inference provider.
The choice is not between MCP and a return to bespoke integration chaos. A standard alternative already exists.
Use it.
The standard you demand becomes the architecture you pay for. Choose the one that spends your tokens on outcomes.
The vendor did not force MCP on you. You asked for it. Ask for something better.