What I Learned Building Multiple MCP Servers for Local LLMs (Qwen3-8B): Tool Granularity, Latency Traps, and Dogfooding

Local data analysis using LM Studio and custom Model Context Protocol (MCP) servers revealed important engineering lessons. Enabling multiple MCP servers with local 8B models quickly led to performance bottlenecks due to the "token tax" - each additional MCP added 150-300 tokens to the system prompt. With 40 tools enabled across 6 MCPs, an 8B model struggled with TTFT (Time-to-First-Token) and reduced tool-selection accuracy.

A key principle for 8B local models is keeping active tools under 5-10 to avoid performance degradation.

When creating tools, merging features that can execute fully without intermediate reasoning is beneficial. For instance, merging a serendipity correlation tool with a Pearson calculator and lateral-thinking injector into a single tool reduced errors and improved performance. However, splitting tools for sequential workflows, like list → describe → query, is necessary to guide the model through a proper process and prevent hallucinations.

Sequential Thinking MCPs, designed to boost reasoning in smaller models, backfired on Qwen3-8B. Its native think ... /think reasoning block created a double-thinking loop, doubling latency and token usage without improving analytical quality. Qwen3-8B should rely on native reasoning and reserve MCPs for external data and deterministic computation.

When open-sourcing MCP servers that connect to local databases, security measures are crucial. Treat the LLM as an untrusted caller and implement a strict read-only DuckDB sandbox, path traversal protection, indirect prompt injection boundaries, and Git history hygiene to prevent SQL injection, file access, and prompt injection vulnerabilities. Building free MCPs won't make a dime, but following these principles ensures reliable, secure local LLM performance.