MCPツール設計：実践的アプローチとトレードオフMCP tool design: Practical approaches and tradeoffs

The Model Context Protocol (MCP) has quickly become a common way to connect large language models to external systems, and how developers design the tools exposed through an MCP server has a direct effect on whether an AI agent behaves reliably. In a post on its Machine Learning blog, AWS lays out practical guidance for MCP tool design, focusing on granularity, naming, and schema definition, along with the tradeoffs that come with each decision. For teams building agents on services such as Amazon Bedrock, these choices determine how accurately a model selects and calls tools, and how predictable the resulting behavior is.

MCP, originally introduced by Anthropic as an open standard, defines a consistent interface between models and the tools, data sources, and services they can act on. An MCP server advertises a set of tools, each described by a name, a natural-language description, and a machine-readable input schema, typically expressed in JSON Schema. The model reads these descriptions at inference time and decides which tool to invoke and with what arguments. Because the model relies almost entirely on that metadata, the quality of the descriptions and schemas becomes as important as the underlying implementation.

A central theme is tool granularity, meaning how much functionality each tool should encapsulate. Fine-grained tools that each perform a single narrow action can be easier to describe precisely, but exposing too many of them tends to overwhelm the model, increases prompt token usage, and raises the chance of an incorrect selection. Coarse-grained tools that bundle many operations reduce the number of choices, but they can become ambiguous and force the model to reason about complex parameter combinations. The blog frames this as a balance rather than a fixed rule, and it appears to recommend grouping related actions in ways that match how an agent would naturally reason about a task.

Naming and descriptions receive similar attention. Clear, unambiguous tool names and descriptions help the model distinguish between options that might otherwise look similar, such as separate tools for reading and updating the same resource. The guidance emphasizes writing descriptions for the model as the audience, stating what a tool does, when it should be used, and any important limitations. Vague or overlapping descriptions are a common cause of misrouted calls, and refining this text is often one of the cheapest ways to improve agent accuracy.

Schema design is the third pillar. Input schemas should constrain what the model can supply, using types, enumerations, required fields, and descriptive property names to reduce malformed calls. Well-structured schemas act as guardrails, catching invalid arguments before they reach downstream systems, while overly rigid schemas can prevent legitimate use cases. There is also a tradeoff around verbosity, since richer schemas and longer descriptions consume more context window and can add latency and cost. The article treats these as engineering decisions to be tuned against the specific agent and workload rather than optimized in isolation.

The broader context helps explain why this matters now. MCP has seen rapid adoption across the industry, with support emerging in numerous development tools and agent frameworks, and it complements existing function-calling and tool-use mechanisms already offered by major model providers. On the AWS side, this guidance is relevant to Bedrock Agents and the newer Amazon Bedrock AgentCore offerings, as well as open frameworks such as Strands Agents, all of which can consume tools exposed over MCP. Because MCP is model-agnostic, well-designed servers can in principle be reused across different agents and models.

For developers, the practical takeaway is that MCP tool design is an iterative process closely tied to how models interpret metadata, not just how APIs are implemented. Testing with representative tasks, observing which tools the model selects, and refining names, descriptions, and schemas accordingly is likely to yield more reliable agents than trying to specify everything upfront. As agent systems move toward production, treating tool design as a first-class concern, with attention to token cost, error handling, and maintainability, appears increasingly important. AWS positions this post as a starting set of principles rather than a definitive standard, reflecting how quickly practices around MCP and agent development are still evolving.