OpenRouter test: MCP, CLI and Skills — which one is eating your context?

OpenRouter test: MCP, CLI and Skills — who is stealing the context?

OpenRouter used the same GitHub query to compare the context tokens and costs of MCP, CLI and Skills across different models. MCP, which loads 46 tools by default, is the most expensive; CLI is the cheapest. Result size and extra call rounds also shift the gap.

• MCP sends all tool definitions, CLI provides only a shell, and Skills loads instructions on demand.

• The same 46 tools produce significantly different token overhead across models and providers.

• To complete the same query, CLI, Skill and a two-tool MCP consume 1,421, 3,315

• Tool results and multi-round calls keep pushing MCP overhead higher, and Tool Search does not necessarily reduce it

The source is OpenRouter's official blog and its own testing. The test tools, tasks, models and number of runs were chosen by OpenRouter; the cost figures come from its test environment, and the vendor has not provided third-party retesting.

You ask an AI Agent to look up the latest release of a GitHub repository and three bug issues. The answer looks the same, but the input token bill can differ by dozens of times. OpenRouter used the same task to test MCP, CLI and Skills: MCP, which loads 46 tools by default, consumes the most context, CLI the least, and Skills sits in between. What really determines cost is how many tool instructions the model reads at the start of each round, and how much larger the returned results it swallows are.

Before the model acts, MCP, CLI and Skills have already fed it different things

Before the model even starts querying GitHub, what it reads is already different: MCP lays out the entire tool catalog, CLI gives just one entry point, and Skills first places a catalog and expands the manual only after a task matches.

MCP (Model Context Protocol, a protocol that lets models call external tools) writes every tool provided by the MCP server into the request. The tool name tells the model what it can call, the description explains the purpose, and the JSON schema (the JSON format that defines tool parameters) specifies which fields to fill in. All three parts are resent with every request, and the model has to reread the full tool catalog on every round.

So can the model be given just one entry point and left to look things up itself? The command-line tool CLI (a program interface that executes commands in a terminal) takes this route. When connecting to GitHub CLI, the model is given only a shell tool (a tool that lets the model run terminal commands) in advance, plus a one-line note that "GitHub CLI is installed and authenticated." It does not need to memorize the full definition of every subcommand first; it only needs to know the program is available and then compose commands itself.

Can the entry point be reduced further? Skills does not even provide the full entry point in advance. Each Skill initially occupies just one line of description, telling the model like a catalog entry what capabilities exist; when a task actually needs it, the full SKILL.md (the complete operating instructions file for a Skill) is loaded once. It does not stuff the instructions permanently into every request, but lets the model first decide whether to read them.

Looking only at the first screen, MCP spreads the entire tool manual on the table, CLI hands over just a terminal key, and Skills gives a catalog first and fetches the manual once an entry matches.

The same set of MCP tools: how many more tokens does a different model cost?

The fixed overhead of the MCP tools mentioned above is not the same across models and providers. Tool count, model and provider all change this cost.

The default tool set of GitHub MCP contains 46 tools. On Claude Haiku 5.5, each request adds 19,436 prompt tokens (the amount of prompt input the model receives each round).

The same set of 46 tools is 8,903 on GPT-6 Luna and 8,525 on Gemini 3.8 Flash. Even with the tool set completely unchanged, the model's count of the tool definitions changes — prompt formats and counting methods differ by provider, so tool count cannot be used to estimate overhead.

The same model route can also produce different results on different providers. The same tool set for Gemini 3.8 Flash counts as 8,525 tokens via Google Vertex and 13,010 tokens via Google AI Studio. Recording only the model name is not enough; which provider route the actual request lands on is also a test condition that must be fixed.

The figures above come from OpenRouter's vendor benchmark methodology and have not been retested by a third party. Until the tool set and provider are fixed, no single token number can serve as a budget basis.

The same GitHub query: which of the three approaches saves more tokens?

Completing the same GitHub query on Claude Sonnet 5.5 shows a clear input token gap: CLI is lowest, Skill next, and MCP limited to two tools highest. How big the gap is can be seen in the three numbers below.

OpenRouter's comparison test put the three integration methods into the same GitHub task. CLI used 1,421 input tokens in total, Skill used 3,315, and MCP scoped to two tools used 23,228. "Input tokens" here refers to the prompt content the model reads and is billed for (the context text the model receives and is billed for), not just the sentence the user typed.

How big is the gap? Skill's input tokens are 2.3 times CLI's, and MCP limited to two tools is just over 16 times CLI's. However, this set of results covers only this task's performance on Sonnet 5.5 and cannot be taken directly as a fixed ratio for all GitHub queries or other models.

Each combination was run three times, and what is shown here is the median, the middle value of the three results. It represents the typical input usage for this set of tasks better than a single run, but it is not the cumulative bill of three runs.

Claude Haiku 5.5 counts prompts the same way as Sonnet 5.5, so the input token values of the two can be understood on the same basis. Some Haiku 5.5 runs used more rounds, and once the round count changes, the bills of the two models cannot be compared side by side.

A single tool return can outweigh the entire tool catalog

A GitHub release object returns just one tool result but takes up about 20,400 tokens, more than the 19,436 tokens added by the 46 default GitHub MCP tool definitions combined. A single tool return can outweigh the entire tool catalog.

For this accounting of prompt tokens (the unit of input text the model reads during processing) on Claude Sonnet 5.5, start with a single instance: the size of one release result already exceeds all the definitions.

Overhead also accumulates with call rounds. The first round carries the tool definitions; after the tool returns the release object, the data enters the context; when the model calls another tool, subsequent requests still carry the previous definitions and results. Cumulative overhead depends on the number of calls and the size of each result, not just on how many tools are mounted.

Tool definitions are a fixed bill; tool results are the bill that can grow with the task.

Tool Search saves the startup cost, but the bill is not necessarily smaller

Tool Search can shrink the first batch of MCP tool definitions to a very small size, but it does not guarantee that the entire GitHub query becomes cheaper.

Tool Search is an OpenRouter server tool (hosted and invoked by the server). The 46 tools originally handed to the model all at once are reduced after searching to a first batch of definitions under 600 tokens. The model does not have to read the full tool catalog at the start.

But the test results here cut both ways: on Sonnet 5.5, using Tool Search halved the cost of the entire task; on Haiku 5.5, the cost actually increased. The same optimization did not produce results in the same direction on the two models.

Initial cost is not the final bill. After the task begins, the model still has to find the right tools, make calls and receive results; what is saved is only the startup segment. It shortens the tool definition segment and does not automatically rewrite the subsequent execution process.

These figures come from OpenRouter's own testing, and no third-party retesting is provided in the text. They can show how the tool performs with this set of models and tasks, but cannot be taken directly as a fixed ratio for all workflows.

Back to this GitHub query: the same answer can go through MCP, CLI or Skills, but the context bill differs. When the tool set is not fixed and the model is not chosen, fully loading the default MCP tool set is the least controllable way to connect.

Source: OpenRouter official blog "MCP vs CLI vs Skills: What Each Costs in Context"; the methodology is the median of three runs under the GitHub query, tool configuration and model environment chosen by OpenRouter. Input tokens and costs all come from its testing, with no third-party retesting provided.

Glossary · Plain-language notes appearing in this piece

The full text of deep dives, research analyses and tool tutorials, plus all podcasts, are in the members area.