MCP

The Hidden Trap of Fat Agent System Design When developers build AI applications, they often start with a simple design: give the agent every tool it might ever need. This approach works perfectly in a notebook or a proof-of-concept demo. If your agent only has 10 tools, the underlying model easily selects the correct one. However, production systems do not stay small. As features expand, 10 tools become 50, then 100, and eventually hundreds. This common architecture is known as the "fat agent." By stuffing every single tool definition, JSON schema, and function description into the system prompt for every request, developers inadvertently degrade their systems. The design fails because every single request carries the weight of the entire tool catalog, leading to massive context bloat before the user's actual question is even evaluated. Why Big Tool Catalogs Destroy Model Performance Loading a massive tool catalog into an agent's prompt triggers a severe performance penalty across three key metrics: accuracy, latency, and cost. Benchmarks demonstrate that when an agent's tool pool expands from 10 to 100 tools, selection accuracy plummets from 78% to approximately 40%. At 741 tools, accuracy collapses to a mere 13.6%. In plain terms, the model calls the wrong tool nearly nine times out of ten. This failure occurs primarily due to the "lost in the middle" phenomenon. Large language models pay high attention to the very beginning and end of long prompts, while neglecting information buried in the middle. When hundreds of schemas clutter the context window, the model starts hallucinating functions, confusing similar tools, and failing. Furthermore, processing a massive prompt spike increases latency. At 500 tools, the time to first token can exceed five seconds. On top of that, sending hundreds of thousands of redundant schema tokens on every API call drives up operational costs. Implementing Semantic Tool Routing as RAG for Tools To bypass the fat agent trap, developers are adopting a pattern known as the Semantic Tool Router. If you understand Retrieval-Augmented Generation (RAG), this architecture will feel immediately familiar. Instead of retrieving text documents, you retrieve tool schemas. ```python Conceptual runtime tool selection query_vector = embedding_model.embed(user_query) selected_tools = vector_db.search(query_vector, k=5) Pass only the 5 selected schemas to the LLM response = llm.call_with_tools(user_query, tools=selected_tools) ``` The process follows three distinct steps: * **Offline Indexing**: Extract the name, description, and JSON schema for every tool in your catalog. Generate vector embeddings of the tool descriptions and store them in a vector database like Chroma or Pinecone. * **Runtime Retrieval**: When a user submits a query, embed the query and perform a cosine similarity search against the vector index to retrieve the top $K$ tools (typically $K=3$ to $K=5$). * **Just-in-Time Injection**: Inject only those $K$ selected tool schemas into the LLM prompt dynamically. This pattern limits the context size. Instead of processing 127,000 tokens of raw schema definitions, the model evaluates roughly 1,000 tokens of highly relevant tool information. Real-World Benefits and Production Guardrails Transitioning to a dynamic routing model yields dramatic improvements. Industry benchmarks, including those published by Anthropic regarding their Model Context Protocol (MCP), show token usage plummeting from 150,000 tokens down to just 2,000 tokens per request—a 98.7% reduction. However, implementing this pattern in production requires careful engineering. A primary risk is a "router miss," where the vector search fails to retrieve the correct tool. Developers can mitigate this by building fallback mechanisms, such as expanding the search parameter $K$ on failure or routing to broad tool groups. Additionally, the system is highly sensitive to the quality of tool descriptions. If your descriptions are vague or technical, the embedding models will fail to find them. Descriptions must be written using the concrete language and intent that end-users actually use. Finally, remember to avoid over-engineering: if your agent uses fewer than 20 tools, static loading remains perfectly fine. The overhead of a router is best justified once your catalog passes 50 tools.