Maître d'MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Adds valuable behavioral context: automatically applies saved dietary restrictions, cuisine preferences, rating thresholds, and blacklist. Describes return payload composition (ratings, prices, walking distance). Missing operational details: no mention of result caching, API rate limits, empty result handling, or whether 'blacklist' refers to personal or group exclusions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear Args/Returns sections. Front-loaded purpose statement followed by auto-filtering behavior. Parameter descriptions are dense but necessary given zero schema coverage. Single minor redundancy: Returns section documents output format despite existence of output schema, though this adds field-level detail that may supplement the structured schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for tool complexity (7 optional parameters, behavioral auto-filtering). Compensates completely for lack of schema descriptions via Args section. Specifies return data fields. Could improve by noting NYC-only limitation implied by location parameter examples, and error handling for invalid addresses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Exemplary compensation for 0% schema description coverage. Documents all 7 parameters with rich semantics: 'location' accepts magic strings ('home', 'work') or NYC addresses; 'price_max' uses 1-4 scale with fallback to saved preferences; 'max_results' caps at 10; 'query' supports free-text features. Examples and constraints provided for every parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb-resource-scope: 'Search for restaurants matching your criteria near a location.' Specifies automatic application of dietary restrictions and blacklist, distinguishing it from generic search tools. However, it does not explicitly differentiate from sibling 'get_recommendations' or 'search_for_group' despite their functional overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage context through parameter documentation (e.g., 'Leave empty to search all cuisines'), but lacks explicit when-to-use guidance contrasting with 'get_recommendations' (algorithmic curation vs. criteria-based search) or 'search_for_group' (group context vs. individual). No exclusion criteria or prerequisites stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.