I measured MCP vs a CLI for agent search. The MCP used 17x more tokens per call.
Ran the same Google search through SerpApi’s official serpapi-mcp server and through serp, the small open-source (MIT) CLI I built for the same job. Before I had searched anything, the MCP had already put 771 tokens into the model’s context. The CLI put zero. When I searched, the MCP returned 6,047 tokens and the CLI returned 351. Same query, same serpapi library underneath, same machine.
That 771-token standing cost is a different kind of cost than the per-call number. You pay the per-call cost when the agent searches. You pay the standing cost on every model turn, whether the agent searches that turn or not. A loop that takes 20 turns to finish a task and only searches three of them costs 771 × 20 = 15,420 tokens in standing schema before you count a single result. The CLI costs nothing on the other 17 turns.
TL;DR: for stateless search in an agent loop, a CLI costs roughly 0 standing tokens against ~771 per turn for an MCP tool, and ~351 per call against ~6,047. The compaction logic on both sides is identical; the CLI trims to the fields you ask for and stays out of context when idle. Pick the transport that fits the call.
MCP (Model Context Protocol) is a standard for connecting external services to AI agents. When you use an MCP server, the model gets a full description of every tool it exposes, and that description sits in context on every single request, paid whether or not the agent uses it that turn. A CLI is a command-line binary the agent calls directly, like git or curl. The agent learns the CLI exists once and then calls it without a standing description in context. Tokens are roughly the number of characters the model processes per request, and most API providers charge per token, so more tokens in context means a bigger bill and less room for the actual task.
Standing cost, paid every turn
| SerpApi MCP | serp CLI | |
|---|---|---|
| Tool schema in context, per turn | 771 tokens | ~0 (binary on PATH) |
| Skill metadata | n/a | ~110 tokens, and only until it triggers |
The MCP injects its search tool schema, all 771 tokens of it, on every request to the model. Not just when the agent searches. Every request, because the schema must be present so the model knows it can search. The CLI injects nothing. It is a binary on PATH; the agent learns it exists once, from a skill that costs ~110 tokens until it fires, and then calls it like any other command.
Wire up ten MCP servers instead of one and you are carrying several thousand tokens of always-loaded schema before the agent has made a single tool call. That is the number the demos skip.
Discovery cost, paid once
| SerpApi MCP | serp CLI | |
|---|---|---|
| Learn the interface | engine resource (google.json) = 5,816 tokens | --help = ~290 tokens |
Both are on demand. To learn one engine’s parameters through the MCP you read its resource file; google.json runs to 5,816 tokens. To learn the CLI you read --help, about 290. This is not a per-turn cost so it does not compound the same way, but it shows up at least once per cold session.
Per call, the same query, byte for byte
| Response | Tokens |
|---|---|
MCP complete (the default) | 6,047 |
MCP compact | 4,577 |
CLI --format complete | 5,321 |
CLI compact, no --fields | 3,940 |
CLI --fields title,link | 351 |
The MCP’s default mode is complete, so out of the box one search drops about 6,000 tokens into your context. The CLI defaults to compact and lets you specify exactly which fields you want back, so the same ten results come back at 351 when you ask for just title,link. That is roughly 17x smaller than the MCP default, and 13x smaller than the MCP’s own compact mode.
At 17x token usage per search call, the math is direct. Ten searches through the MCP at 6,047 tokens each equals 60,470 tokens of search results. The same ten through the CLI at 351 equals 3,510. The title and link are usually everything an agent needs to decide whether to fetch a page or cite a result. The rest is noise at model cost. Across thousands of agent runs a day, that gap is not trivial, and it stacks on top of the standing 771 tokens per turn whether the agent searches or not.
Why the CLI is 13x cheaper
The honest part first: the compaction logic on both sides is identical. Both drop the same five metadata blocks: search_metadata, search_parameters, search_information, pagination, serpapi_pagination. SerpApi’s MCP is a good piece of software, and 771 tokens for one universal tool covering every search engine it supports is a reasonable schema, not bloat. I am not dunking on it.
What those five blocks contain is worth saying plainly. search_metadata carries timing and processing data, including request ID and API credits consumed. search_parameters echoes back exactly what you sent. search_information is display copy for building a UI. The two pagination objects are for humans navigating result pages. An agent synthesizing an answer from search results needs none of this.
The gap after stripping those five blocks comes from three things the CLI does that the MCP does not. First, field projection: --fields title,link trims every result to the keys you named. The MCP’s compact mode strips the metadata blocks but still returns every field in every result, including snippet, date, sitelinks, knowledge graph extras, and whatever else the engine included. That feature alone accounts for most of the 13x. Second, minification: the MCP pretty-prints with indent=2, which adds roughly 15% more characters compared to compact output. Third, zero idle cost: there is no schema sitting in context between calls.
The measurement
Tokens are characters / 4 throughout, the same proxy on both sides. Trust the ratios more than the absolutes; any systematic error in the proxy cancels in the comparison.
For the standing cost: I took the actual tools/list response from serpapi-mcp running on FastMCP and counted the fields a client receives, name, description, and inputSchema. That is 771 tokens for the single search tool. The server also exposes 107 engine resources; listing them all costs about 4,300 tokens, and reading google.json specifically costs 5,816.
For per-call: one live Google search, fixed query, pulled through the same serpapi Python library the MCP uses internally. Serialized two ways: json.dumps(indent=2) to match what the MCP hands to the model, and minified with field projection to match what the CLI produces. The exact numbers from those two serializations are what is in the table above.
Compaction was mirrored on both sides deliberately, same five blocks stripped before serializing, so the comparison is apples-to-apples on that dimension. The remaining gap is projection and minification.
To reproduce: run serpapi-mcp locally via npx -y serpapi-mcp, capture the raw tools/list JSON response, count with len(json.dumps(payload)), divide by 4. For per-call, pull the same query through the serpapi Python library directly (from serpapi import GoogleSearch), serialize with json.dumps(indent=2), count characters. Then serialize the same result after stripping those five metadata blocks and projecting to title,link, count again. The five blocks: search_metadata, search_parameters, search_information, pagination, serpapi_pagination. Both measurements fit in about 30 lines of Python and need only one live API call.
Other people measured the same effect, harder
The principle is not mine. Anthropic’s framing is that the context window is a public good, and two published benchmarks point in the same direction. Their code-execution-with-MCP writeup took a Drive-to-Salesforce workflow from about 150,000 tokens to about 2,000 by calling tools as code rather than loading their definitions, a 98.7% cut. The OnlyCLI benchmark timed a GitHub task at 44,026 tokens through MCP versus 1,365 through a CLI, about 32x. Those are big end-to-end scenarios with many tools and substantial intermediate state. My 13-17x on a single search is the small, conservative version of the same mechanism.
When you want the MCP
This is not “CLI beats MCP.” It is pick the transport that fits the call.
Reach for the MCP when the connection is the hard part: OAuth or multi-user auth the agent should not handle itself, server-side quota and rate-limit governance, one hosted endpoint shared across many clients and machines, or a session that holds state between steps. SerpApi runs serpapi-mcp and a hosted version at mcp.serpapi.com. That is where it earns its keep, a managed connection with SerpApi handling auth and quotas, accessible to any MCP client without distributing a key.
Reach for the CLI when the call is stateless and you control both ends. Query in, results out, one step, one key in the environment, a payload you want to trim before it hits the model. A search is the textbook case. Read --help once per session and every call after that returns only what you asked for. No server to manage, no standing schema, no auth complexity.
One heuristic that holds: if the connection is the hard part, use MCP. If the payload is the hard part, use a CLI.
What serp is
It wraps SerpApi’s REST endpoint and compiles to a single binary with bun build --compile, no runtime dependencies. compact mode drops the five metadata blocks, --fields projects each result to the keys you name, and the geo flags (--location, --gl, --hl) only go on the wire when you set them. Output is minified JSON on stdout, because the reader is a machine. The key reads from SERPAPI_API_KEY with a fallback to SERP_API_KEY.
The parts worth testing are pure functions: the URL builder, the arg parser, the result formatter. The network call and run() entrypoint take an injected fetch and injected streams, so the full suite, 37 tests, runs offline with no key and no real requests. That is the part I am actually happy with.
There is a Claude Code skill alongside it, searching-with-serpapi, that holds the procedure: which engine fits which intent, compact vs complete, operators, when to dedup and cite, when not to search at all. The skill costs about 110 tokens until it fires. Capability from the CLI (or the MCP), procedure from the skill.
Two caveats worth naming
Prompt caching narrows the standing gap on warm sessions where the toolset stays fixed, since the static schema block gets amortized across turns. The 771-per-turn number bites hardest on cold starts and whenever you add or swap a tool. The per-call gap does not care about caching; you pay it fresh on every search.
Code execution is a bigger lever than any of this. It is where the 98.7% figure comes from. But it requires a real sandbox with resource limits and monitoring, which a plain CLI call skips. Different tradeoff, worth naming.
Bottom line
Match the transport to the call. For stateless search in a coding loop, a small CLI plus a skill is cheaper on context (roughly 0 standing against 771 per turn, roughly 350 per result against 6,000) and the standing savings stack as you add tools. For a hosted, governed, multi-client connection, the MCP is the right call.
If you are running agents with a stack of MCP servers, the standing cost is worth measuring on your own setup. The method is in the appendix, easy to reproduce. I would genuinely like to know what numbers you get.
The repo is open source and MIT: github.com/aryrabelo/serpapi-agent-toolkit. The CLI and the skill ship together, both complements to SerpApi’s serpapi-mcp.
Appendix: how I measured
Tokens are characters / 4, consistent on both sides, so trust the ratios more than the absolutes.
MCP standing is the real tools/list payload from serpapi-mcp running on FastMCP, counting the fields a client actually receives (name, description, inputSchema): 771 tokens for the single search tool. The server also exposes 107 engine resources; listing all of them is about 4,300 tokens, reading google.json specifically is 5,816.
Per-call numbers come from one live Google search for a fixed query, pulled through the same serpapi Python library the MCP uses internally, then serialized two ways: json.dumps(indent=2) to match the MCP’s output, and minified with field projection to match the CLI. Exact counts: MCP complete 6,047, MCP compact 4,577, CLI complete 5,321, CLI compact 3,940, CLI --fields title,link 351. CLI standing cost and --help size come from the v0.1.0 shipped text, about 110 and 290 respectively.
Sources: Anthropic’s “Code execution with MCP”, “Writing tools for agents”, and “Effective context engineering”; the OnlyCLI token-cost benchmark; SerpApi’s serpapi-mcp and serpapi-javascript repos.
If you run a stack of MCP servers and the standing cost is a mystery, the method above is roughly the first hour of the build. Hand me the setup and the rest is measurement, then the fix. Put numbers on your setup.
I write Em Paralelo once a week about AI, developer tooling, and performance, always with the numbers behind the claim. Subscribe to Em Paralelo.