Cutting MCP Token Costs: Search vs. Programmatic Tool Invocation

Table of contents

• The Token Problem in MCP
• Search‑Based Tool Loading
• Programmatic Tool Orchestration
• Optimizing Your Own MCP Servers
• Takeaways

---

The Token Problem in MCP

MCP servers expose a set of RPC‑style “tools” that an LLM can call.

• A single server can ship dozens of tools, each with a verbose description, parameter list, and examples.
• When an agent connects to multiple servers, the total token footprint can balloon.
  • Example: 167 tools spread across four servers consumed more than 60 k tokens before a user even typed a prompt.
• Even a 200 k‑token context window can be partially exhausted by tool metadata alone, leaving fewer tokens for the actual conversation.

Search‑Based Tool Loading

Claude’s recent update introduces a search mechanism that loads only the most relevant tools.

• Trigger: If preloaded tools exceed 10 % of the context window, the agent runs a natural‑language query to identify needed tools.
• Result: Only 3–5 matching tools are injected into context, cutting token consumption by up to 95 %.
• The approach mirrors “skill” loading: the agent first loads tool names and short descriptions, then fetches full definitions for the selected ones.

Quick illustration

User: “Find the latest GitHub repo for this project.”
Claude: “Searching for tools…”
Claude loads only the `github_search` tool and its schema.

Programmatic Tool Orchestration

Cloudflare’s Code Mode flips the paradigm: instead of feeding a list of tool definitions to the LLM, it converts those definitions into a TypeScript API.

• The LLM writes code that imports the TypeScript interface, calls the appropriate functions, and handles the response in a sandboxed worker.
• Benefits:
  • Token savings – no need to serialize tool metadata back into the prompt.
  • Complex orchestration – a single script can chain multiple calls, eliminating round‑trips to the LLM.
  • Developer familiarity – LLMs are trained on large codebases, so generating TypeScript is more natural than composing tool‑call JSON.

Sample workflow

import { githubSearch, awsCli } from '@cloudflare/mcp';

async function run() {
  const results = await githubSearch({
    query: "open source MCP implementation",
    limit: 5
  });
  const bucketList = await awsCli({
    command: "s3 ls",
    env: { AWS_PROFILE: "dev" }
  });
  console.log(results, bucketList);
}
run();

Optimizing Your Own MCP Servers

If you host your own MCP server, token bloat can be trimmed from the source.

• Consolidate similar tools:
  • Combine four web‑search tools into a single web_search with a provider enum.
  • Merge GitHub search variants into one github_search with a search_type param.
• Reduce verbosity: strip unnecessary example calls and trim descriptions to a few sentences.
• Enable/disable servers selectively:
  • The McPick CLI edits the ~/.claude.json config to toggle servers on demand, so only the tools you need are ever loaded.

McPick usage

npx mcpick
? Toggle MCP servers
❯ mcp-omnisearch (enabled)
◯ turso-cloud (disabled)

Takeaways

• Token bloat in MCP is a real bottleneck; even a well‑tuned LLM can be starved of conversation tokens.
• Search‑based loading offers a quick win: reduce context size by selecting only the tools that matter.
• Programmatic orchestration provides deeper savings and flexibility, especially for multi‑step workflows.
• Server‑side optimization—consolidating tools, trimming documentation, and enabling only needed servers—completes the picture.

Implement one or a combination of these strategies to keep your LLM’s context lean and your agent’s reasoning swift.