{"slug": "do-unused-mcp-tools-cost-you-money", "title": "Do unused MCP tools cost you money?", "summary": "A developer benchmarked two identical MCP agents, one with a single GitHub server and one with three additional unused servers, and found the latter cost 28% more per question due to extra input tokens from tool schemas. The experiment used the open-source MAVERIK test bench and showed that attaching unnecessary MCP servers imposes a deterministic token tax on every request.", "body_md": "*A short case study from my \"building and testing MCP agents\" series — it stands on its own, but the method behind it is laid out in https://dev.to/langensjonathan/the-parameters-that-actually-matter-when-youre-tuning-an-ai-agent-2agd.*\n\n**TL;DR:** I benchmarked two agents that are identical except for one thing — how many MCP servers they're connected to — on the exact same question. Both got the right answer, both called the same single tool. The one with more MCP servers attached still cost **28% more per question**, purely from the extra tool schemas the model has to be told about on every single call, whether it uses them or not.\n\nMAVERIK is my open-source MCP test bench: define a suite of questions with pass criteria, run it against one or more agent configurations, and compare the results on hard numbers. This post is one deliberately tiny experiment with it: change exactly one thing about an agent, hold everything else fixed, and see what the numbers attribute to that one change.\n\nI have a small \"GitHub summarizer\" agent: one system prompt, one job — answer questions about my GitHub account by calling the [GitHub MCP server](https://github.com/github/github-mcp-server). I duplicated its configuration (MAVERIK supports this directly — same model, same prompt, same everything) and changed one field on the copy: the set of attached MCP servers, adding `deepwiki`\n\n, `microsoft-learn`\n\n, and `context7`\n\n. Neither agent needs any of those three for the question I was about to ask; they were attached because that's what the \"kitchen sink\" version of this agent had accumulated over a few sessions of general-purpose use.\n\nThen I wrote the simplest possible test suite — one question:\n\n\"How many repositories do I have?\"\n\nwith a `contains`\n\ncriterion checking the answer includes the correct count. No judge model, no subjectivity — it either says the right number or it doesn't. I ran both agents against it, 2 repetitions each, same model (`claude-haiku`\n\n) for both, and pulled up MAVERIK's **Agent Comparison** report.\n\nAgent A — `github` only |\nAgent B — `github` + 3 more MCP servers |\n|\n|---|---|---|\n| MCP servers attached | 1 | 4 |\n| Pass rate | 100% | 100% |\n| Tool calls per question | 1 (`get_me` ) |\n1 (`get_me` ) |\n| Iterations per question | 2 | 2 |\n| Avg input tokens | 16,628 | 21,467 |\n| Avg output tokens | 138 | 144.5 |\n| Avg peak context tokens | 8,494 | 10,919.5 |\n| Avg duration | 3,659 ms | 3,061 ms |\n| Token cost / question | $0.034636 | $0.044379 |\n| Tool cost / question | $0.0000 | $0.0000 |\nOverall cost / question |\n$0.034636 |\n$0.044379 |\n\n(Raw CSV, straight out of the report's export button, is at the bottom of this post if you want to check my arithmetic.)\n\nThree numbers moved together, consistently, across both repetitions:\n\nOne caveat I want to make before someone else does: 28% is a function of how small this task is. The tax itself is absolute — ~4,839 extra input tokens on every request — so on a task with 50k tokens of real context the *percentage* would look much smaller. But that's the wrong comfort: the absolute tax is paid on every iteration of every run this agent ever makes, forever. Short tasks are where the tax is most *visible*, not where it's worst.\n\n`get_me`\n\n— both times).`repetitions`\n\nknob in the first place. I'd want a much larger `n`\n\nbefore drawing any conclusion about latency here. Token counts, by contrast, needed zero repetitions to trust — they were bit-for-bit identical across both runs of the same agent, because they're a function of the prompt and tool schemas, not the network.That asymmetry is the real lesson: **cost is a much cleaner signal than latency.** If I'd only looked at duration, I'd have concluded the bigger agent was *better*. It took breaking the run down by token count — something a stopwatch can't tell you — to see the actual, deterministic tax of the extra servers.\n\nIt's a reminder that **\"which MCP servers does this agent have access to\" is a tunable parameter with a real, measurable cost, not a one-time architectural decision you make and forget.** Every tool a server exposes gets its name, description, and JSON schema stuffed into the model's context on every call. A server with a large or verbose tool catalog is a standing tax on every request an agent makes, independent of whether that agent ever calls it.\n\nThere's a design consequence hiding in that, too. Restricting which tools an agent may use only saves you money if the host enforces the restriction **before serialization**: a disallowed tool has to be left out of the request entirely, not merely rejected when the model tries to call it. Enforce it at call time and you keep paying the token tax for tools the agent was never allowed to touch. The same trimming shrinks your actual attack surface, in the security sense — every unused tool schema in context is one more thing a prompt injection can try to steer the model toward.\n\nThe practical version of this: if you're building agents against MCP servers, don't default to \"attach everything, it might be useful.\" Give each agent only the servers its job actually requires, and — if you're not sure whether a broader toolset is worth its overhead — measure it instead of guessing. That's a two-line duplication of an agent config and a one-question test suite, and the answer was sitting in a CSV five minutes later.\n\nThis whole thing was: duplicate an agent config, write a one-question suite with a `contains`\n\ncriterion, run both agents against it a couple of times, open the built-in **Agent Comparison** report (or export it to CSV, like I did above). If you're evaluating your own MCP servers or agent configs, the project is open source — [https://github.com/langens-jonathan/maverik](https://github.com/langens-jonathan/maverik).\n\nRaw CSV (Reporting → Agent Comparison → Export → To CSV)\n\n```\nsuiteId,agentId,timestamp,sourceRunId,passRate,avgDurationMs,avgInputTokens,avgOutputTokens,avgToolCalls,avgPeakContextTokens,tokenCost,toolCost,overallCost\ngithub-summarizer,github-test-agent,2026-07-26T10:07:18.9720785+00:00,github-summarizer-20260726-100718,1,3659,16628,138,1,8494,0.034636,0,0.034636\ngithub-summarizer,github-test-agent-all-mcp-servers,2026-07-26T10:07:18.9720785+00:00,github-summarizer-20260726-100718,1,3061,21467,144.5,1,10919.5,0.044379,0,0.044379\n```\n\n", "url": "https://wpnews.pro/news/do-unused-mcp-tools-cost-you-money", "canonical_source": "https://dev.to/langensjonathan/do-unused-mcp-tools-cost-you-money-2gnb", "published_at": "2026-07-30 18:18:36+00:00", "updated_at": "2026-07-30 18:32:33.169912+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools", "large-language-models"], "entities": ["MAVERIK", "GitHub MCP server", "claude-haiku"], "alternates": {"html": "https://wpnews.pro/news/do-unused-mcp-tools-cost-you-money", "markdown": "https://wpnews.pro/news/do-unused-mcp-tools-cost-you-money.md", "text": "https://wpnews.pro/news/do-unused-mcp-tools-cost-you-money.txt", "jsonld": "https://wpnews.pro/news/do-unused-mcp-tools-cost-you-money.jsonld"}}