Why a Big MCP Toolset Is a Feature, Not a Context Problem

The concern is fair. AI context windows are finite. If you load up your client with five MCP servers and one of them is enormous, you might worry about token bloat or latency or model confusion. The instinct is reasonable.

The reality is that the MCP protocol was designed around exactly this constraint, and modern AI client implementations handle large catalogs without breaking a sweat. The fear comes from intuition about LLM context. The numbers tell a different story. This post walks the actual math, the actual protocol behavior, and the actual practical experience of running PaidSync alongside other tools.

The actual context math

The fear is "380 tools must use a huge amount of my context window." The math is more boring than the fear.

PaidSync's average tool description, including the name, the short summary, the platform tag, and the when-to-use hint, runs around 200 tokens. That is generous. Many descriptions are shorter. A few are longer for tools with complex parameters.

The full catalog token cost is approximately 380 tools times 200 tokens per description, which works out to around 76K tokens for the tool list itself. That number sits inside Claude Sonnet 4.5's 200K window with 124K to spare for the conversation itself, the system prompt, and any other context the user is bringing in. On Claude Opus 4.7 with its 1M context, the catalog is less than 8% of the available room.

The honest read on the 38% number for Claude Sonnet 4.5. Yes, it is a real chunk of the window. But that 124K leftover is more than enough for any normal operator conversation. A long search terms report is 5K to 20K tokens. A full account audit summary is 10K to 30K. The AI has plenty of room to work.

If you are running PaidSync alongside a long-running research workflow that needs every token, scope it down with tool filtering. Most operators do not need to.

MCP tool schemas are loaded lazily

The protocol matters. MCP does not flood the AI's context with the full input schema for every tool the moment you connect. It sends descriptions on connect, then fetches the per-tool input schema when the AI decides to call that specific tool.

The practical effect. The catalog overhead is descriptions only, and descriptions are short. Full schemas for a tool can run 500 to 2000 tokens depending on parameter complexity, but you only pay that cost when the AI calls the tool, not when the catalog loads.

For a typical 10-call operator conversation, the schema-load cost is 10 tools' worth of full schemas, around 5K to 20K tokens spread across the session. That is small. The catalog itself is the bulk of the upfront cost, and it is bounded by description length, not parameter complexity.

Why small MCPs are usually not cheaper

The intuitive fix for "big MCP uses context" is "I will just use a smaller one." That math usually breaks down in practice.

Each MCP server you connect to your AI client comes with its own overhead. The schema metadata for the server itself. The auth context for the server. The tool-naming conventions, which the AI has to learn separately. The conversation patterns, since different MCPs name similar actions differently.

If you replace one 380-tool PaidSync MCP with three smaller MCPs covering Google Ads, Meta Ads, and LinkedIn Ads separately, you end up with three sets of schema overhead, three auth contexts, three sets of tool-naming conventions for the AI to track. The duplicated metadata typically lands you above PaidSync's single-catalog cost, not below.

The cleaner comparison is "well-scoped large MCP" against "fragmented small MCPs." For paid media, the well-scoped large MCP usually wins on total context.

Modern AI clients cache the catalog

One more practical detail. Claude Desktop, Cursor, and the major MCP clients cache the tool catalog across a session. The catalog loads once when you start a conversation. After that, every prompt the AI sees has the tool list already in cached context. Anthropic's prompt cache TTL is several minutes, long enough that a normal back-and-forth working session never pays the catalog load cost twice.

The first prompt of a session pays the 76K catalog token cost. The next 20 prompts pay close to zero on the catalog side. That matters a lot for operators who chain calls. The catalog cost amortizes across the conversation.

If you genuinely want a smaller footprint

For the technical buyer who has done the math and still wants a smaller catalog, the protocol supports it. Most MCP clients let you filter tools by name pattern, platform tag, or category at config time. The PaidSync MCP exposes platform tags so you can scope to a single platform when you want.

The simplest scope-down patterns. Filter to Google Ads only if you only run Google. Filter to read-only tools if you only need audits. Filter to a specific category like "audit" or "reporting" if your workflow is narrow. The full PaidSync MCP is available when you need it. The scoped version is available when you do not.

Most operators never bother. The full catalog fits, the work gets done, and the cross-platform tools earn their context cost the moment the AI compares Google Ads, Meta Ads, LinkedIn Ads, and TikTok Ads in the same conversation.

Why a deep catalog is the right design

Here is the underlying argument. Paid media is a deep domain. The work an operator does in Google Ads or Meta Ads is not "list campaigns and pause one." It is n-gram search term analysis, Performance Max insight extraction, wasted spend detection, MCC routing across client accounts, conversion value rule edits, audience-building flows. Each of those is a real tool that benefits from a real input schema and a real output structure.

You can ship a thin MCP with 20 generic tools and expect the AI to compose them into the deep workflow. In practice, that produces brittle prompts and inconsistent results. The AI is much better at calling a well-named, well-scoped tool than at composing six generic actions into the same outcome.

380 tools is the cost of doing the work right. Each tool is a workflow the AI can call in one step. The depth is why PaidSync produces predictable results in Claude or ChatGPT instead of needing custom prompt engineering for every task.

The honest take

"Big MCP fills my context" is a fair instinct that does not survive contact with the numbers. The catalog is 76K tokens in a 200K to 1M window. The schemas are lazy. The cache amortizes. The alternative of stitching small MCPs together usually costs more, not less.

A deep catalog is the entire reason an MCP server earns its place in the AI client. It is the workflow surface the AI calls to actually do the work. If you want a shallow MCP that asks the AI to compose generic actions, the alternative exists. For operators who want AI to run paid media, the depth is the value.

Frequently asked