We need to talk about the Model Context Protocol (MCP). For some reason, the standard advice for failing agentic pipelines has become “just upgrade to a more powerful model,” and frankly, it is killing your performance and your budget. Before you throw more GPU credits at the problem, you need to look at your MCP tool descriptions. In my 14 years of wrestling with broken integrations, I’ve learned that the most expensive model in the world won’t save you from a messy schema.
The Bias Trap: Why Length Matters
Most developers treat MCP servers like a black box. You connect a server, it lists the tools via list_tools, and you hope the LLM knows what to do. However, there is a hidden race condition in how models process these descriptions. Specifically, models like GPT-4o or Gemini 2.0 exhibit a significant “complication bias.” If Tool A has a three-sentence description and Tool B has a paragraph full of examples, the model will often gravitate toward Tool B—even if Tool A is the technically correct choice for the task.
I recently saw this in a WooCommerce integration where a simple “Get Order” tool was being ignored in favor of a “Generate Report” tool simply because the latter had a more “impressive” JSON schema. This isn’t just a quirk; it is a fundamental bottleneck in agentic logic. To build something stable, you need to stop letting third-party MCP providers dictate your model’s attention. For a deeper look at managing these interactions, check out my guide on AI coding agent context.
The “Hiding Arguments” Pattern
A common mistake I see is exposing internal state—like user_id or session_token—directly in the tool’s parameters. Not only is this a security risk, but it forces the LLM to hallucinate values it shouldn’t even care about. Consequently, the model wastes tokens trying to “guess” a user ID that your application already knows.
The “Senior Dev” workaround? Refactor your MCP tool descriptions to hide these parameters from the LLM while keeping them in the underlying function. Here is how you might transform a bloated schema into something precise:
{
"name": "bbioon_get_customer_data",
"description": "Retrieves purchase history. Use this when the user asks for their previous orders.",
"parameters": {
"type": "object",
"properties": {
"limit": {
"type": "integer",
"description": "Number of orders to return (default 5)."
},
"_user_id": {
"type": "string",
"description": "INTERNAL ONLY - DO NOT GENERATE"
}
},
"required": ["limit"]
}
}By prefixing internal arguments (like _user_id) and excluding them from the prompt via a proxy, you reduce the surface area for errors. You handle the injection of that ID on the server side, not in the prompt.
Architecture Critique: The Proxy Solution
If you are managing multiple MCP servers, you shouldn’t connect them directly to your agent. Instead, use a proxy like Master-MCP. This acts as a middleman that allows you to override MCP tool descriptions on the fly without modifying the original server code. It’s like using a WordPress filter to modify a plugin’s output rather than hacking the core files.
Furthermore, using a proxy allows for advanced logging and tool orchestration. You can see exactly which descriptions are confusing the model and “tune” them until the accuracy improves. This is much more effective than switching models every time a new “mini” or “nano” version drops. For more on building robust agents, read about mastering agentic AI with robust vibe agents.
Look, if this MCP tool descriptions stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days and I know how to make external APIs play nice with your site.
The Final Takeaway
Reliable agentic pipelines are built on standardized instructions, not just raw compute power. Specifically, you must audit your MCP tool descriptions for length bias, remove unnecessary arguments, and consider a proxy layer for orchestration. Stop chasing the “strongest” model and start building the smartest schema. Ship it.
