AWS published 6 approaches to optimizing MCP tools to save context

AWS on July 12, 2026 published a technical guide on MCP tool design problems and proposed six practical approaches to solve them — from optimizing descriptions to server-side parameter analysis using AI. The study is based on real-world testing of an educational content search API (K-12).

Why MCP Tools Degrade Model Quality

Model Context Protocol helps LLMs use external tools, but tool definition design is often poorly executed. AWS identified two main problems:

Bloat: each MCP server loads tool definitions into the context window, even if they're not used. With multiple active servers, the window fills with definitions before the user asks their first question.

Confusion: an overcrowded context degrades the model's reasoning. LLMs confuse similar tools, make parameter mistakes, and misinterpret constraints. Semantic similarity between tools and unclear parameter names compound the problem.

Six Approaches: A Complete Solution Spectrum

AWS tested six implementations against real-world queries like "Find a fractions test for 7th grade" and "I need content aligned to TEKS":

• V1 (Raw Passthrough): exposes backend API as-is — high parameter error rates
• V2 (Rich Descriptions): detailed docstrings with examples — improves accuracy but increases size
• V3 (Schema & Defaults): renamed parameters (`discipline` → `subject`), `Literal` enums, sensible defaults — good tradeoff
• V4 (Lazy Loading): details (taxonomy) in a separate tool — minimal baseline, extra requests
• V5 (Server-side Introspection): Amazon Nova 2 Lite analyzes parameters server-side — stable behavior but adds inference calls
• V6 (Agent-as-Tool): single `question: str` parameter, all logic inside — maximum control, requires infrastructure

Key AWS Recommendations

AWS Prescriptive Guidance recommends keeping tool parameters to "roughly eight or fewer." Anthropic's research shows: shifting to on-demand detailed output reduces response tokens by roughly two-thirds.

Additionally: write specific, actionable error messages (not just "no results," but precise guidance on what to try). Use domain-appropriate parameter names instead of database column names — this dramatically reduces model confusion.

How to Choose an Approach for Your Task

There is no one-size-fits-all solution. The choice depends on parameter count (few → V3, many → V4-V5), vocabulary stability, latency requirements, and whether consistency across models is needed. For most search and filter tasks, V3 is sufficient. Specialized applications (complex taxonomy, multi-step reasoning) benefit from V4-V5.

What This Means

MCP tools currently often slow down LLM agents, but AWS demonstrated: the problem is solvable through context engineering. Engineers now have a practical playbook for balancing context and accuracy instead of blindly adding descriptions.