How should teams design MCP tool definitions so LLMs choose the right tool and fill arguments correctly?

Treat tool definitions as instructions for a model, not just as function signatures. Use clear verb plus object names, concise descriptions that state purpose and constraints, and parameter metadata that explains formats, defaults, and accepted values. When values are closed sets, define them as enums. This reduces ambiguity, improves tool selection, and lowers retry loops during real usage.

How should teams write MCP tool names and descriptions so models select the right capability?

Tool selection starts with naming. Use a verb plus object pattern that mirrors the user task, so the model can map intent to capability without guessing. Keep descriptions short, specific, and outcome-focused, and state the boundary of the tool in plain language. If multiple tools overlap, differentiate them by purpose and scope rather than by implementation detail.

What should parameter metadata tell the model?

Arguments should be written as guidance, not just schema. For each parameter, explain the expected format, whether the value is required or optional, any default, and any constraint that affects the model’s choice. When a field accepts only known values, use an enum so the model can stay inside a closed set instead of inventing a free-text variant.

Why do clear tool definitions reduce retries and bad calls?

LLMs often fail in predictable ways when a tool contract is underspecified: they choose the wrong tool, omit a required argument, or fill a field with a plausible but invalid value. Better definitions reduce ambiguity at both steps, selection and argument filling, so the model spends less effort recovering from errors. That usually means fewer retry loops, fewer failed executions, and less manual correction in production.

Risk and Threat Considerations

Poorly designed MCP tool definitions create avoidable exposure because the model will often take the path that appears most obvious, not the one the developer intended. When names overlap, descriptions are vague, or parameters allow unconstrained text, the failure mode is silent misuse rather than an obvious error.

Failure mechanism: Ambiguous names, weak descriptions, and loosely typed arguments increase the chance of tool confusion, incorrect parameterisation, and unintended actions. In agentic systems, that can also widen the blast radius if a model reaches a more powerful tool than the user or workflow intended.

Impact: Teams see more retries, lower automation reliability, and higher operational risk from mis-executed actions, data exposure, or privilege misuse. In the worst case, a seemingly small prompt ambiguity becomes a control failure when the model invokes the wrong tool with valid-looking arguments.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI02 — Tool Misuse	MCP tool selection failures directly map to agent misuse of tools.
	ASI03 — Identity & Privilege Abuse	Wrong tool choice can expand effective authority in agent workflows.
Recommendation — Constrain tools with clear purpose, scope and argument rules to reduce misuse. Limit tool authority so misselection cannot trigger high-impact actions.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Tool arguments often carry credentials, tokens or other identity-bearing material.
	AC-6 — Least Privilege	Overbroad tools or ambiguous scopes increase the impact of model mistakes.
	CM-6 — Configuration Settings	Enums, defaults and parameter constraints are configuration controls for tool behavior.
Recommendation — Validate and tightly manage any secret or token fields passed to tools. Expose only the minimum tool capabilities needed for the task. Standardize tool schemas and constrain inputs to approved values.

Practitioner Guidance

What to verify: Test tool definitions against realistic user intents, not just against schema validation. A good definition should let the model distinguish adjacent tools from their names and descriptions alone, then populate required fields without guesswork.

Decision rule: If a field has a closed set of valid values, make it an enum; if the model needs to choose among similar operations, narrow the descriptions until each tool has a clear purpose, scope, and edge conditions.

Common mistake: Teams often over-explain implementation details and under-explain intent. The model does not benefit from internal API jargon if the task boundary, allowed values, and expected format remain unclear.

Practitioner takeaway: The best MCP tool definitions are written for model disambiguation first and developer convenience second, because precision in names, descriptions, and enums is what keeps tool use predictable at runtime.