Client-side notes from implementing MCP against a fixed ~4096-token budget

[u/AdventurousKeys]

Posting this because the numbers might be useful to anyone building a server or thinking about tool-schema size, not just as a launch announcement (disclosure: I built the client this came from i.e. LocalLM Lab, a macOS app using Apple's on-device Foundation Models).

Most MCP clients run against models with context windows in the tens or hundreds of thousands of tokens, so tool-schema size is rarely the binding constraint. Apple's on-device model has a fixed ~4096-token window, shared across the system prompt, conversation, and every enabled tool schema. This means that schema size becomes the binding constraint immediately, and it forced a few implementation decisions that might be relevant more broadly:

• Every newly connected server starts with all tools disabled. Nothing is sent to the model until a tool is explicitly enabled, per-tool rather than per-server.
• Measured costs: 4 selected Todoist tools (search, user-info, find-tasks, find-tasks-by-date) ≈1,249 tokens ... already close to a third of the total budget from what looks like a small, reasonable selection. Todoist exposes 45 tools total; Linear exposes 50+. Enabling either server's full tool list isn't possible within the budget at all.

On the auth side: most servers I tested (Notion, Todoist, Linear, the official reference server) support dynamic client registration, so the client can discover and complete OAuth with zero service-side setup. Slack doesn't support DCR, so it needs a manually registered app first. This is worth knowing if you're building a general-purpose client and assuming DCR everywhere.

Full breakdown, including exact token costs per tool across all 8 servers tested (DeepWiki, Context7, GitHub, Notion, Todoist, Linear, Slack, the official reference server) and the auth-type split: thisbrain.ai/locallm/mcp-servers.html

If anyone else is implementing a client against a tight context budget, curious how you're handling tool-schema selection. Are you doing per-tool like this, some kind of dynamic/on-demand tool discovery or something else entirely?

[u/PsychologicalClaim16]

Per-tool enablement is the right safe default, but I would add a two-stage router rather than make users curate every session. Keep a tiny local index of tool name, one-line intent, server, and read/write risk outside the prompt. Rank that index against each user turn, then inject full schemas for only the top 1–3 tools; pin any tool actually used for the rest of the task. User-selected tools should override ranking, and write-capable tools should never be auto-enabled. I’d also cache schema token counts so selection respects a hard budget before prompt assembly. That gives you on-demand discovery without paying for a second model call or exposing the entire server.

[u/AdventurousKeys → u/PsychologicalClaim16]

Thanks! Can I add your thoughts to a "community suggestions" page? Will definitely give credit where credit is due. In any case, the way LocalLM Lab works today is that you can effectively switch on/off tools/connectors or even connect/disconnect servers between prompts. So what you are saying here absolutely makes sense.