AWS publishes 6 approaches to optimizing MCP tools and saving context

On July 12, 2026, AWS published a technical guide to the problems of MCP tool design and proposed 6 practical approaches to solving them, from optimizing descriptions to server-side parameter analysis with AI. The research is based on real-world testing of an API for searching educational content (K-12).

Why MCP tools degrade model quality

Model Context Protocol helps LLMs use external tools, but the definitions are often poorly designed. AWS identified two main problems:

Bloat: every MCP server loads its tool definitions into the context window, even if the tools are not used. With several active servers, the window fills up with definitions before the user asks the first question.

Confusion: an overloaded context degrades the model's reasoning. The LLM mixes up similar tools, gets parameters wrong and misinterprets constraints. Semantic similarity between tools and unclear parameter names make the problem worse.

6 approaches: the full range of solutions

AWS tested six implementations on real queries such as "Find a quiz on fractions for 7th grade" and "I need content aligned to TEKS":

• V1 (Raw Passthrough): exposes the backend API as is, leading to a high rate of parameter errors
• V2 (Rich Descriptions): detailed docstrings with examples, which improve accuracy but increase size
• V3 (Schema & Defaults): renamed parameters (`discipline` → `subject`), `Literal` enums, sensible defaults, a good compromise
• V4 (Lazy Loading): details (taxonomy) sit behind a separate tool, giving a minimal baseline but requiring additional requests
• V5 (Server-side Introspection): Amazon Nova 2 Lite analyzes parameters on the server, giving stable behavior but adding inference calls
• V6 (Agent-as-Tool): a single `question: str` parameter with all logic inside, offering maximum control but requiring infrastructure

Key AWS recommendations

AWS Prescriptive Guidance recommends keeping a tool's parameters to "around eight or fewer". Anthropic's research showed that switching to on-demand detailed output cuts response tokens by roughly two thirds.

Also: write specific, actionable error messages (not just "no results", but an exact description of what to try). Use domain-appropriate parameter names instead of database column names, which sharply reduces model confusion.

How to choose an approach for your task

There is no universal solution. The choice depends on the number of parameters (few → V3, many → V4-V5), the stability of the vocabulary, latency requirements and whether consistency across different models is needed. V3 is enough for most search and filter tasks. Specialized applications (complex taxonomies, multi-step reasoning) benefit from V4-V5.

What this means

MCP tools now often slow down LLM agents, but AWS has shown the problem can be solved through context engineering. Engineers now have a practical playbook for balancing context and accuracy, instead of blindly adding descriptions.