Skip to content

Knowledge base

Protocol and context cost

What MCP standardizes, who uses it, and how much of the context window its tool schemas take, with ways to load tools only when a task needs them.

Written by

Updated:

Tools 4

Our position. We use MCP for external integrations (opens in a new tab) such as issue trackers, databases, chat and third-party APIs. Every connected server adds capability and costs context tokens, so we load MCP servers explicitly per task (opens in a new tab) and connect what the task needs, not everything available.

What does MCP standardize, and who uses it?

MCP solves a real integration problem: instead of building a custom connector for every agent-tool pairing, developers implement the protocol once and gain access to an entire ecosystem. Adoption since the November 2024 launch has been rapid, and agents now routinely connect to hundreds or thousands of tools across dozens of servers (Anthropic - Code execution with MCP (opens in a new tab)). A side effect is that every server built for one client becomes a plugin for anything that speaks the protocol, which turns MCP into an accidentally universal plugin system; capabilities compound across the ecosystem without coordination between authors (Works on My Machine - MCP: An (Accidentally) Universal Plugin System (opens in a new tab)).

At enterprise scale the pattern shows up as internal tool platforms: Stripe operates a “tool shed” of roughly 500 MCP tools with meta-tool selection, and Shopify runs 100+ internal MCP integrations (AI Productivity Research). The protocol is also moving beyond developer tooling into the web itself: WebMCP, in early preview in Chrome, proposes declarative and imperative APIs that let websites expose structured tools directly to browser agents, replacing brittle raw DOM actuation for flows like checkout or support tickets (Chrome for Developers - WebMCP is available for early preview (opens in a new tab)). The contrast with UI-actuating agents is the argument for protocol access: Perplexity’s Comet browser agent takes a screenshot on every click, runs image recognition to locate the next target, then continues, and a holiday-apartment search across five platforms ran about thirty minutes to a poor result, a concrete illustration of why structured tools beat screen scraping for agent-web interaction (OMR State Of The Internet 2026 (opens in a new tab), 7 May 2026).

Beneath the ecosystem noise the protocol itself is small. An MCP server exposes three primitive types, not just callable tools: tools (executable functions), resources (files or records the agent can read), and prompts (reusable templates); servers run locally, remotely, or as managed services someone else hosts (Scalable AI with Multi-Agent Systems and MCP (opens in a new tab)). Transport is deliberately thin: local servers speak JSON-RPC over stdio with essentially no network overhead, while remote servers use HTTP from client to server and server-sent events back, which also means standing up a web server and auth (Docker MCP toolkit walkthrough (opens in a new tab)). The MCP Inspector validates a server’s tools, resources, and prompts before it is wired into a client, and discovery is still maturing: Anthropic has signalled an MCP registry so clients can auto-find the right server for a task rather than relying on manual configuration (Scalable AI with Multi-Agent Systems and MCP (opens in a new tab)).

Not everyone buys the trajectory. One detailed critique argues the “NxM problem” MCP claims to solve is largely handled by existing SDK abstractions, that separate long-lived server processes bring runtime, debugging, and supply-chain problems (including several high-severity CVEs in popular servers), and that most published servers are thin API wrappers a coding agent could one-shot as a local script; the prediction is that skills, command runners, and plain OpenAPI will chip away at MCP’s role (MCP is a Fad (opens in a new tab)). Whether or not the strong version of that claim holds, the security and operational concerns it catalogs are grounded in real incidents and belong in any MCP rollout discussion.

How much context do MCP tool schemas consume?

The central tradeoff of MCP is context. Most clients load all tool definitions upfront, and those definitions act as “billboards” that consume context even when the tools are never called (Claude Code). Measured numbers are consistently large: idle MCP tools measured at 24.1k tokens, about 12% of the context window, before any work began (Claude Code feature roundup (opens in a new tab), 15 August 2025); Playwright MCP’s 21 tools cost about 13.7k tokens and Chrome DevTools MCP’s 26 tools about 18k (What if you don’t need MCP at all? (opens in a new tab)); a setup with 6 servers and 60 tools consumed roughly 47,000 tokens before any work started (Introducing MCP CLI (opens in a new tab)).

Beyond raw tokens, large toolboxes confuse agents. Tools from arbitrary sources do not know what else is in the toolbox, so their descriptions cannot disambiguate when to use which tool, and agents get measurably worse at tool selection as the count grows (MCP is a Fad (opens in a new tab)). The consistent practitioner recommendation is fewer MCP servers, loaded deliberately: fewer servers produce better results (AI Productivity Research).

The mitigation toolkit is well documented. Delete the default .mcp.json, load servers on demand with claude --mcp-config <file>, use --strict-mcp-config to block globals, split servers into per-purpose config files (including read-only versus write variants), and verify the footprint with /context (Claude Code). Dynamic discovery goes further: instead of static schema loading, a CLI layer lists servers, fetches a specific tool’s schema, and executes it only when needed, cutting MCP-related token usage by around 99% in the measured scenario (Introducing MCP CLI (opens in a new tab)).

Anthropic shipped a platform-native version of this pattern in November 2025, the Tool Search Tool, which loads only a small search tool upfront (around 500 tokens) and marks the rest with defer_loading: true so they are discovered on demand rather than injected into context (Anthropic - Advanced tool use (opens in a new tab)). Anthropic’s five-server example already holds 58 tools and roughly 55,000 tokens of definitions, and adding Jira alone would add about 17,000. In its comparison, loading definitions for 50-plus MCP tools upfront consumed around 77,000 tokens before any work, against about 8,700 with the Tool Search Tool; Anthropic calls this an 85% reduction, though those two figures give about 89%. Measured tool-selection accuracy rose too (Opus 4 from 49% to 74%, Opus 4.5 from 79.5% to 88.1%); because deferred tools never enter the initial prompt, the technique also preserves prompt caching (24 November 2025, vendor claim about its own platform).

The vendor guidance is to keep the three to five most-used tools always loaded and defer the rest, and to reach for the pattern once tool definitions exceed roughly 10,000 tokens or 10 tools (Anthropic - Advanced tool use (opens in a new tab)). The common failure it targets is not only token cost but wrong tool selection when names collide, such as notification-send-user versus notification-send-channel (Anthropic - Advanced tool use (opens in a new tab)).

Resources

Articles

Posts

Talks and videos