AWS Pinpoints Why MCP Tools Fail: It's Design, Not the Protocol

AWS has published a detailed technical breakdown arguing that when AI agents built on the Model Context Protocol (MCP) misbehave, the root cause is almost never the protocol itself. Instead, according to the AWS Machine Learning Blog, the failures trace back to how developers design the tools that agents call.

The post identifies two recurring culprits: "bloat" and "confusion." Bloat happens because tool definitions get loaded into an LLM's context window on every single call, regardless of whether that tool ends up being used. When several MCP servers are connected simultaneously, their combined tool definitions can eat up a substantial chunk of available context before the model has even processed a user's question. That leaves less room for actual reasoning and task-specific information.

Confusion is a separate but related failure mode. It emerges when an LLM has too many tools to choose from, when several tools sound semantically similar, or when naming conventions are vague enough that the model can't reliably tell which function fits a given task. The result is agents that pick the wrong tool, hesitate, or produce inconsistent outputs even though every individual tool works fine in isolation.

Context Engineering as the Fix

AWS frames the solution through the lens of "context engineering," a discipline focused on controlling exactly what information an LLM sees and at what point in a workflow it sees it. Rather than treating bloat and confusion as unrelated bugs, the blog treats them as two ends of a tradeoff that tool designers have to balance deliberately. Trimming context too aggressively can strip away detail the model needs, while leaving too much in invites the ambiguity that causes confusion.

One concrete recommendation involves how tools structure their responses. A tool that returns, say, 50 fields per result will flood the context window fast, even if the agent only needed two or three of those fields to complete its task. AWS suggests designing tool outputs to default to a lean set of essential fields, with additional detail available through optional parameters only when a task actually calls for it. That single change, the company argues, can meaningfully cut down on wasted context without sacrificing functionality.

To make the guidance concrete, AWS built out a simulated K-12 educational content search API as a working example, implementing multiple versions of the same MCP tool set under different design philosophies. The comparison is meant to let developers see, side by side, how choices around field defaults, tool granularity, and naming clarity translate into measurably different context consumption and model accuracy.

The broader takeaway is a shift in where engineering teams should focus their debugging effort. Instead of treating MCP as a black box prone to unpredictable failures, AWS is effectively telling developers that the protocol is a stable foundation, and that inconsistent agent behavior is a solvable, largely self-inflicted problem rooted in how tools are scoped, named, and structured.