mcp_cook_getRecipeById

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the operation is a query (read) and that the response includes ingredients and steps, which gives some sense of the return content. However, it does not mention potential multi-result behavior from fuzzy name matching, error conditions, or lack of explicit read-only confirmation. While not misleading, it adds only modest context beyond the basic action.

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?

The description is a single, concise sentence that front-loads the essential purpose (query by name/ID for complete details) and specifies the returned content. Every word contributes value, and there is no redundancy or extraneous information.

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?

Given the tool's simplicity (one parameter, no nested objects, no output schema), the description adequately conveys the operation and the nature of the returned information ('完整详情' plus ingredients and steps). It does not describe edge cases like multiple matches or not-found behavior, which would be valuable for full completeness, but for a straightforward lookup tool, this level of detail is largely sufficient. A slightly richer statement about possible multiple results from fuzzy matching would have earned a 5.

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?

The input schema already describes the 'query' parameter as accepting a recipe name or ID with fuzzy name matching, which provides 100% coverage. The description merely repeats this information ('根据菜谱名称或ID') without adding new meaning, syntax details, or usage nuances. Therefore, baseline score of 3 is appropriate.

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?

The description clearly states a specific action (查询/query) on a specific resource (specified recipe by name or ID) and enumerates the content of the returned details (食材、步骤等). This distinguishes it from sibling tools like getAllRecipes or getRecipesByCategory, which are list or category-based, not detail lookups.

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?

The phrasing '根据菜谱名称或ID查询指定菜谱的完整详情' clearly indicates this tool is intended for retrieving a single recipe's complete details by name or ID, which is a distinct use case from listing all recipes or browsing by category. Although it does not explicitly name alternatives, the context of a targeted lookup is evident and no exclusions are implied. This meets the 'clear context, no exclusions' criterion, but stops short of explicitly naming sibling alternatives.

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