What happened
OpenRouter’s November 11, 2026 article, “MCP vs CLI vs Skills: What Each Costs in Context,” examines how much context different ways of giving an agent access to a tool consume. The comparison uses the GitHub repository cli/cli and asks for its latest release and three most recently opened issues labeled bug. The three approaches were a shell tool with the GitHub CLI installed, the same shell tool plus a short index to a gh skill, and GitHub’s MCP server. OpenRouter ran the combinations three times on October 20, 2026, and reports medians.
On Claude Sonnet 5.5, all three approaches returned correct answers. The CLI used 1,421 input tokens and cost $0.0075 per task; the skill used 3,315 tokens and cost $0.0118. MCP used 23,228 tokens when scoped to two relevant tools, 59,417 with the server’s 46 default tools, and 101,351 with all 91 tools. The corresponding reported cost for the 46-tool setup was $0.1274 per task. GPT-6 Luna and Gemini 3.8 Flash also showed substantial differences, though the exact counts varied by model. OpenRouter says the 46 default MCP definitions alone added 19,436 tokens on Sonnet 5.5, and 8,903 on GPT-6 Luna.
The definitions were only part of the context cost. In the test, GitHub’s get_latest_release returned a 42,182-character release object, 87% of which described download files. OpenRouter says this result added about 20,400 tokens on Sonnet 5.5 and was carried into later requests. The CLI returned just the tag and date needed for the question. Scoping MCP to two tools reduced the first request from 19,487 tokens to 1,406, but the full task still used 23,228. A 4,000-character result cap brought that run to 5,357 tokens, with correct answers in the reported runs. OpenRouter cautions that this cap worked because the needed fields happened to appear near the beginning of the response; selecting fields explicitly is safer.
The article also tests Tool Search, OpenRouter’s beta mechanism for deferring MCP definitions until a model searches for tools. With 46 definitions deferred, the upfront cost was under 600 tokens on Claude models, GPT-6 Luna, and Gemini 3.8 Flash. But the full-task results were model-dependent: on Sonnet 5.5, Tool Search used 30,334 tokens against 59,417 with all 46 tools loaded; on Gemini 3.8 Flash it used 37,568 against 35,409. Haiku 5.5 used more tokens with 46 deferred tools than with all loaded, and the article describes tool-argument errors and retries. OpenRouter recommends measuring on the target model and capping tool-loop requests.
What the archive adds
New Runtime’s earlier coverage discussed Agent Skills as reusable procedures that can be exposed to multiple coding-agent clients (Genesis Skills repository, November 10, 2026). That note concerned a specific skills repository, not this cost comparison. This is a new fact about the operational cost of choosing among skills, CLI, and MCP, rather than a restatement of that coverage.
Trend signal
This does not yet fit a pattern New Runtime tracks. OpenRouter’s measurements are a focused comparison of one task and one server, not evidence of a general shift in tool protocols or agent architecture.
Connections to other events
OpenRouter’s comparison connects interface choice to the broader question of how agent capabilities are exposed. Within this same article, Tool Search is a concrete alternative to loading every MCP definition at once; the results show both its potential and its model-dependent costs. The CLI, skill, and MCP paths remain distinct options rather than interchangeable winners.
Why it matters
Tool choice affects more than integration convenience. Every definition and result placed in a model’s context can increase usage and remain present across later turns. For teams running agents repeatedly, the difference between $0.0075 and $0.1274 per task can compound, while oversized results also consume context that could be used for reasoning or other work.
The practical lesson is to optimize the whole tool loop, not only the number of tools advertised. Start with the narrowest interface that can do the job. If a CLI is available and the model can use it reliably, it may avoid loading a large schema. If MCP is needed for typed calls, remote access, or server-side authorization, expose only relevant tools and return only relevant fields. Tool Search can reduce upfront definitions, but these tests show that it is not a universal cost reduction: discovery behavior and call reliability vary by model. Builders should benchmark their own tasks, track correctness alongside token totals, and set a request cap so retries do not erase savings.
Limits and uncertainty
These figures come from one GitHub server and one task, with three runs per combination; they do not establish typical costs across tools or workloads. OpenRouter’s measurements are not independently reproduced here. Tool Search results varied between models and runs, and some attempts failed or retried. The article’s capped-response result depends on fields appearing near the start, while output-token charges also affected billed task totals. Teams should validate both cost and answer quality using their own tool schemas, response shapes, models, and provider routes.
Skill to build now
Build a small tool-cost test for one real agent task. Record input tokens, billed cost, number of calls, and whether the answer is correct for the current interface; then repeat with a CLI or skill, scoped MCP, and field-limited results where applicable. Keep the request, model, and task fixed so the comparison identifies the effect of the interface rather than a changed workload.
Reader takeaway
An MCP server’s cost is not just the price of a tool call: definitions and results can occupy the context repeatedly. Use the smallest reliable interface, constrain what the model sees, and benchmark the full task on the model you plan to run.