Your MCP Servers Are Silently Draining Your Context Window: The Hidden Cost of Tool-Heavy AI Agents
ππΌπ΅π» on November 12, 2026
I typed a two-word promptβ"Run tests"βinto my AI coding agent, and my API billing dashboard immediately registered 28,400 input tokens. I had not a...
I especially liked the point that βmore toolsβ doesnβt automatically mean βmore capable agent.β
Itβs really easy to keep adding MCP servers because each one looks useful in isolation, but once all of those schemas and outputs start competing with the actual code and task context, the trade-off becomes much less obvious.
The distinction between focused micro-tools, small CLIs, and on-demand skills also makes a lot of sense to me.
βSmall, sharp, single-purpose toolsβ feels very close to how I want to design developer tooling in general too. πΈ
Freelance fullstack developer creating fast, modern, and refined applications. I focus on simplicity, performance, and real value for users. I also write tech-related articles here.
That "looks useful in isolation" trap is exactly how bloat creeps into modern workflows. Keeping tools small, sharp, and single-purpose really is the sweet spot. Both for human developer experience and for keeping AI context windows clean.
Really glad this resonated with your philosophy on building developer tooling.
This highlights an important design principle that I think will become increasingly relevant as AI agents evolve: more capabilities don't automatically translate into more intelligence. We often equip agents with every possible integration, assuming that greater access means better results. But there's a hidden trade-off: every additional tool competes for context, attention, and the model's ability to distinguish what actually matters.
I particularly like the shift toward focused micro-tools. It mirrors good software architecture: small, composable components with clearly defined responsibilities are often easier to maintain, understand, and optimize than massive systems trying to do everything.
I'd add one more consideration: tool selection should be dynamic, not just minimal. An agent working on a database issue shouldn't need to carry the entire GitHub, Slack, and Jira tool catalog throughout every reasoning step. Loading capabilities when they're actually needed could become just as important as optimizing the model itself.
We're entering an era where building better AI agents may involve giving them fewer tools, not more. The real measure of an agent isn't how much it can access, but how effectively it uses the context it has available.
Excellent reminder that context is an engineering resource, not an unlimited container.
The dynamic angle is a great addition β loading tools per task phase rather than per session feels like the natural next step after capping the count. The 78% to 99% first-try accuracy jump in the article already shows how much selection quality matters, and swapping tool sets as the task shifts could push that further. I wonder how you'd decide when to swap β a planner step up front, or letting the agent request a tool set as it goes?
Freelance fullstack developer creating fast, modern, and refined applications. I focus on simplicity, performance, and real value for users. I also write tech-related articles here.
Thanks so much, Marie. I love the framing that context is an engineering resource rather than an unlimited container.
Your point about dynamic capability loading really nails the next step here. An agent debugging a database issue has zero reason to carry Slack, Jira, or GitHub schemas through every reasoning loop, so loading tools just-in-time is quickly becoming just as critical as keeping individual tools small and composable.
Appreciate you bringing such a thoughtful architectural perspective to the thread.
Built a crypto media site and an on-chain analytics tool. Now I invest in crypto and follow post-quantum security. Nights I vibe code and dig Reddit for startup ideas.
Good breakdown. One distinction Iβd make in the table: 25k is per-request context occupancy; 250k over a 10-step loop is cumulative input processed, not 250k sitting in one context window. Both matter, but labeling them separately makes the cost-versus-window tradeoff much clearer.
Freelance fullstack developer creating fast, modern, and refined applications. I focus on simplicity, performance, and real value for users. I also write tech-related articles here.
Fair point - that is a really helpful distinction.
Separating single-turn window occupancy (which drives attention dilution) from cumulative input processed across the loop (which drives latency and API spend) definitely makes the tradeoff clearer.
Appreciate you calling that out for readers going through the numbers.
The 28,400-token figure for a two-word prompt is a good concrete baseline. One thing I've run into that makes this worse than the schema count suggests: the same MCP server can expose overlapping tools (list_workflow_runs vs get_commit_status vs search_issues), and the model spends real tokens on the description of the near-miss before picking the right one. Trimming the server list to two or three tools per domain β or wrapping the server with a thin "search" tool that returns the schema for the real tool on demand β cut my per-request overhead by roughly the same 60-70% range you're implying.
Did you measure the hit on the model's actual picks, or only the token cost? With seven servers, I'd expect the bigger loss to be in the model calling a plausible-but-wrong tool from the list and having to recover from the error.
Freelance fullstack developer creating fast, modern, and refined applications. I focus on simplicity, performance, and real value for users. I also write tech-related articles here.
Your intuition is spot on. The recovery loops from picking a "plausible-but-wrong" tool hurt far more than the static schema tax itself.
In my benchmark runs, first-try tool selection accuracy dropped to 78% with the full 52-tool stack (compared to 99% with the 4-tool setup), and every misfire burned an extra full turn of context just to recover from validation errors or wrong endpoints. Wrapping servers behind a thin on-demand schema search tool is a great way to sidestep that overlap entirely.
Appreciate you sharing those numbers and insights from your own setup.
The schema overhead math tracks with what we see in document extraction pipelines too, though tool return payloads often dwarf the definition tax. An unguarded PDF or web-fetch MCP tool that dumps raw layout JSON or an entire 40-page document into stdout burns tens of thousands of tokens on the very first turn, pushing relevant code or instructions into the middle of the context window.
Returning a compact structural outline first (headings, table counts, and page ranges) and letting the agent request specific sections or page slices on demand keeps both the schema surface small and the tool outputs bounded.
Freelance fullstack developer creating fast, modern, and refined applications. I focus on simplicity, performance, and real value for users. I also write tech-related articles here.
Spot on. The output payload blowup is often the bigger silent killer in real-world pipelines.
Dumping raw layout JSON or a 40-page document on turn one immediately triggers that "lost in the middle" degradation. Returning a lightweight structural outline first and letting the agent fetch specific slices on demand is such a clean pattern for keeping context bounded on both ends.
Appreciate you sharing this practical insight from document extraction workflows.
We're a place where coders share, stay up-to-date and grow their careers.
Really good article, John! πΈπ
I especially liked the point that βmore toolsβ doesnβt automatically mean βmore capable agent.β
Itβs really easy to keep adding MCP servers because each one looks useful in isolation, but once all of those schemas and outputs start competing with the actual code and task context, the trade-off becomes much less obvious.
The distinction between focused micro-tools, small CLIs, and on-demand skills also makes a lot of sense to me.
βSmall, sharp, single-purpose toolsβ feels very close to how I want to design developer tooling in general too. πΈ
Thanks so much, nyaomaru! π
That "looks useful in isolation" trap is exactly how bloat creeps into modern workflows. Keeping tools small, sharp, and single-purpose really is the sweet spot. Both for human developer experience and for keeping AI context windows clean.
Really glad this resonated with your philosophy on building developer tooling.
This highlights an important design principle that I think will become increasingly relevant as AI agents evolve: more capabilities don't automatically translate into more intelligence. We often equip agents with every possible integration, assuming that greater access means better results. But there's a hidden trade-off: every additional tool competes for context, attention, and the model's ability to distinguish what actually matters.
I particularly like the shift toward focused micro-tools. It mirrors good software architecture: small, composable components with clearly defined responsibilities are often easier to maintain, understand, and optimize than massive systems trying to do everything.
I'd add one more consideration: tool selection should be dynamic, not just minimal. An agent working on a database issue shouldn't need to carry the entire GitHub, Slack, and Jira tool catalog throughout every reasoning step. Loading capabilities when they're actually needed could become just as important as optimizing the model itself.
We're entering an era where building better AI agents may involve giving them fewer tools, not more. The real measure of an agent isn't how much it can access, but how effectively it uses the context it has available.
Excellent reminder that context is an engineering resource, not an unlimited container.
The dynamic angle is a great addition β loading tools per task phase rather than per session feels like the natural next step after capping the count. The 78% to 99% first-try accuracy jump in the article already shows how much selection quality matters, and swapping tool sets as the task shifts could push that further. I wonder how you'd decide when to swap β a planner step up front, or letting the agent request a tool set as it goes?
Thanks so much, Marie. I love the framing that context is an engineering resource rather than an unlimited container.
Your point about dynamic capability loading really nails the next step here. An agent debugging a database issue has zero reason to carry Slack, Jira, or GitHub schemas through every reasoning loop, so loading tools just-in-time is quickly becoming just as critical as keeping individual tools small and composable.
Appreciate you bringing such a thoughtful architectural perspective to the thread.
Good breakdown. One distinction Iβd make in the table: 25k is per-request context occupancy; 250k over a 10-step loop is cumulative input processed, not 250k sitting in one context window. Both matter, but labeling them separately makes the cost-versus-window tradeoff much clearer.
Fair point - that is a really helpful distinction.
Separating single-turn window occupancy (which drives attention dilution) from cumulative input processed across the loop (which drives latency and API spend) definitely makes the tradeoff clearer.
Appreciate you calling that out for readers going through the numbers.
The 28,400-token figure for a two-word prompt is a good concrete baseline. One thing I've run into that makes this worse than the schema count suggests: the same MCP server can expose overlapping tools (list_workflow_runs vs get_commit_status vs search_issues), and the model spends real tokens on the description of the near-miss before picking the right one. Trimming the server list to two or three tools per domain β or wrapping the server with a thin "search" tool that returns the schema for the real tool on demand β cut my per-request overhead by roughly the same 60-70% range you're implying.
Did you measure the hit on the model's actual picks, or only the token cost? With seven servers, I'd expect the bigger loss to be in the model calling a plausible-but-wrong tool from the list and having to recover from the error.
Your intuition is spot on. The recovery loops from picking a "plausible-but-wrong" tool hurt far more than the static schema tax itself.
In my benchmark runs, first-try tool selection accuracy dropped to 78% with the full 52-tool stack (compared to 99% with the 4-tool setup), and every misfire burned an extra full turn of context just to recover from validation errors or wrong endpoints. Wrapping servers behind a thin on-demand schema search tool is a great way to sidestep that overlap entirely.
Appreciate you sharing those numbers and insights from your own setup.
The schema overhead math tracks with what we see in document extraction pipelines too, though tool return payloads often dwarf the definition tax. An unguarded PDF or web-fetch MCP tool that dumps raw layout JSON or an entire 40-page document into stdout burns tens of thousands of tokens on the very first turn, pushing relevant code or instructions into the middle of the context window.
Returning a compact structural outline first (headings, table counts, and page ranges) and letting the agent request specific sections or page slices on demand keeps both the schema surface small and the tool outputs bounded.
Spot on. The output payload blowup is often the bigger silent killer in real-world pipelines.
Dumping raw layout JSON or a 40-page document on turn one immediately triggers that "lost in the middle" degradation. Returning a lightweight structural outline first and letting the agent fetch specific slices on demand is such a clean pattern for keeping context bounded on both ends.
Appreciate you sharing this practical insight from document extraction workflows.