Your MCP server doesn't need to put all its tools in the model's context

Halemo GPA — Mon, 03 Aug 2026 21:04:49 +0000

I built an MCP server that lets an AI agent use my own WhatsApp: search chats, send messages, transcribe voice notes, all self-hosted so my message history never leaves my box. But the most interesting problem turned out to have nothing to do with WhatsApp. It was the number of tools.

The tax nobody mentions

MCP injects every tool definition into the model's context on every request, whether or not the request uses them. My server grew to 96 tools. That's roughly 20k tokens sitting in context before the model has done anything.

The token cost was the annoying part, but not the real one. When I handed the model all 96 tools at once, it got worse at picking the right one, not better. More options, more room to be wrong.

Progressive disclosure

The obvious move, dropping tools, loses capability. So instead: serve a small hot core directly, and keep the long tail reachable through search.

The model now sees 29 core tools plus two meta-tools:

find_tool(query) ranks the full 96-tool library and returns names, descriptions, and parameter signatures.
call_tool(name, arguments) dispatches into any of them.
Always-on cost drops from ~20k to ~8k tokens, and nothing is removed, everything is one search away. Retrieval is lexical by default (IDF + stemming + a synonym map) and blends in embeddings if a provider key is present.

The part that will bite you

call_tool dispatches inside the process, past the middleware chain that normally runs on a tool call. So it has to re-apply what that chain would have done: per-tool scope enforcement and audit logging. Skip that and your retrieval layer quietly becomes a scope-bypass and an audit hole. A tool router that skips your authorization is worse than no router.

Measure it, don't vibe it

"It feels better" isn't a number. There's a small labeled eval (natural-language task to gold tool, deterministic labels) that scores whether retrieval lands on the right tool. Lexical caps around 75% recall@8 on adversarial phrasing; hybrid pushes it higher. The eval is small and mine, so treat it as a direction, not a proof.

Takeaway

If you're wiring an LLM into a big API, the tool list is a first-class design problem, not an afterthought. Serve a core, make the rest searchable, mirror your auth into the dispatch path, and put a number on the retrieval.

Code, the eval harness, and the design notes: https://github.com/HalemoGPA/whatsapp-mcp-server

Smart Home Project

Halemo GPA — Sun, 22 May 2022 01:23:26 +0000

I am going to share the full details of structured, designed and documented 👇

Smart Home project

It took much effort to do all the stuff required to document everything in the project. It would be pleasure if it helped anyone.

Anyone is free to use this as reference.

If you know anyone who has a project similar to this, Be initiative and send it to him.

Check the repo here.

DEV Community: Halemo GPA

Your MCP server doesn't need to put all its tools in the model's context

Smart Home Project

Smart Home project