If you're running ToolPiper alongside Claude Code, you have access to over 450 MCP tools without lifting a finger. Browser automation, OCR, web scraping, audio, pose, RAG, GitHub, Reddit, Google Search Console, the whole catalog is one MCP server connection away. That's a lot of capability. It's also a lot of tool definitions a client has to know about, whether you use them or not.

This piece walks through what keeps that cheap, and which part applies where. In Claude Code, two layers do the work: Claude Code's own deferred loading, and the tool selection you save in ToolPiper. The third, ToolGate, runs where ToolPiper itself calls a model, in its own chat and voice.

Why an MCP catalog costs tokens

Every MCP tool a client connects to has a name, a description, and a JSON Schema for its parameters. A client that put all of that into the prompt on every turn would spend a large share of its context on tools it is not using. With over 450 tools that is a real cost before you've even typed a question.

Multiply that by a long debugging session and the math gets painful, especially on cloud models priced per million input tokens. The catalog isn't doing work. It's just reminding the model that the work could be done. Reducing what the model sees per turn is the whole game.

Layer 1: Claude Code already does part of this for you

Claude Code uses deferred schema loading for MCP servers. At connection time, only the tool names enter the context. The full JSON schemas, parameter shapes, enums, nested objects, are not loaded until the model asks for one specifically through an internal tool-search step.

You can see this directly. Run Claude Code with ToolPiper connected and look at the MCP tools listing. You'll see something like:

Their schemas are NOT loaded. Use ToolSearch with query "select:<name>..." to load tool schemas before calling them.

That's the cost-control mechanism doing its job. The full schemas, which are the bulk of the weight, only cost tokens for the tools the model actually decides to use.

It's also not enough on its own, because the list of names still scales with the number of tools you've left in. That is what the next layer is for.

Layer 2: The tool selection you save

This is the layer most people skip and shouldn't. In ToolPiper's MCP Tools settings every tool has an include switch, and every category has Include All and Exclude All. Tools you exclude, and tools you set to Deny, are not listed to Claude Code at all. They don't show up in the deferred list and they don't cost a single token.

The right strategy is honest self-assessment. Will you ever ask Claude Code to scrape Reddit during a coding session? Probably not. Run a pose-detection benchmark? Also probably not. Narrate a video? Definitely not. Exclude those, and the catalog Claude Code sees shrinks by whatever you trimmed.

A practical baseline for a developer using Claude Code:

  • Keep: file ops, git, shell, web_scrape, http_request, code_search, browser_*, vision_screenshot, audio_transcribe, the things you'd actually invoke during a coding session.
  • Exclude for now: video_*, pose_*, audio_voice_clone, reddit_*, hn_*, gsc_*, queue_*, anything outreach-related. Include them again when you actually need them.

ToolPiper picks up the change without a restart. Claude Code gets the new list when it next connects, because ToolPiper hands each connection its listing once and keeps it steady for that session. You can also connect with a smaller profile in the URL, such as http://127.0.0.1:9998/mcp?profile=automation, which advertises only the core, browser and testing tools.

Layer 3: ToolGate, for ToolPiper's own chat

ToolGate is ToolPiper's on-device gating engine for the places where ToolPiper itself calls a model: ModelPiper's chat, voice, and scheduled runs. It picks which tool schemas to send for each turn. It does not trim what Claude Code sees; an external MCP client gets your whole selection.

It composes three things in order:

1. Permissions pre-filter. Tools you set to Deny are removed before anything else runs. Denied tools cannot ship under any circumstance. This is a hard guarantee, not a heuristic.

2. Budgeting. How much tool schema ToolGate sends follows the schema-budget band of the model configuration in use, and it never overruns the loaded model's context window, so tools cannot crowd out the conversation.

3. Semantic relevance. Inside that budget, ToolGate selects the tools most relevant to the current request, using an on-device retrieval model. The request text is not sent anywhere for the ranking.

You can watch it run. Each ranking logs a toolgate.recommend event in ToolPiper's logs viewer with the number of tools returned, the catalog size and how many were denied, never the text of your request.

Schema engineering, not just schema selection

Selecting fewer tools is half the savings. The other half is making each listed tool cost less, and this part does apply to Claude Code.

ToolPiper lists every tool in a compact projection. Tools whose name carries the meaning ship an empty input schema. The rest ship typed schemas with descriptions, output schemas and per-enum descriptions stripped. The model still picks the right arguments, and the listing is smaller for every client.

What a real Claude Code turn looks like

Putting the Claude Code layers together, here's what happens when you ask Claude Code to do something:

  1. Claude Code already has the names of the tools in your selection in context.
  2. You ask: "scrape this URL and pull out the API examples."
  3. Claude Code's tool search loads the full schema for the tools it picks, probably web_scrape, file_read and file_write.
  4. Claude Code calls them on ToolPiper and responds.

The tools you excluded or denied were never in the list. The schemas Claude Code didn't load aren't in the prompt.

How to measure it on your machine

For Claude Code, the MCP Tools settings show how many tools and how many bytes a new connection would receive from your current selection, and each listing logs a mcp.tools_list.published event. For ToolPiper's own chat, watch the toolgate.recommend events while you work.

If the listing looks large, trim your selection first. In ToolPiper's own chat, a model configuration with a larger schema-budget band lets ToolGate send more tools per turn, which is good for capability and costs you on every turn; pick the band that matches what your work needs.

Why we built it this way

The honest tension in MCP is that more tools means more capability and also more weight. The naive answer is "install fewer servers." Our answer is to let you decide what is listed, keep each listing compact, and gate per turn where ToolPiper runs the model itself.

If you're using Claude Code daily and ToolPiper is sitting next to it, you're already getting Layer 1 from Anthropic. The work that's left to you is Layer 2: open ToolPiper's MCP Tools settings and exclude the tools you'll never use.

What about access control?

The permission list isn't just a token optimization, it's the same surface that secures access. Local clients on the same Mac connect over loopback with zero config: ToolPiper mints a short-lived bearer token at ~/Library/Application Support/ToolPiper/.toolpiper-token (mode 0600, rotated every launch) and trusts loopback at the socket level, so Claude Code just works with no key to paste. Anything off-machine, a LAN device or a PiperMesh peer, has to present a scoped Bearer tp_<64 hex> token instead. Every authenticated client shows up as a revocable row in ToolPiper's Connected Apps pane, and the tool-governance overlay lets you deny specific tools (say system_run_command) for every client or flip the tool marketplace from open browse to an explicit allow-list. Governance is a per-device, locally-edited overlay today, it can only narrow what a tier already permits, never widen it, with org-managed push (and a "Managed by your organization" lock) on the roadmap.

Try it

ToolPiper is a free download from modelpiper.com/download. Install it, connect Claude Code to its MCP server, and trim the tool selection to what you use.