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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context, such as output format, error handling, or limitations. It primarily focuses on usage triggers rather than disclosing how the tool behaves.

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 front-loaded with a clear main sentence, followed by a labeled TRIGGERS section with four bullet-like examples. It is slightly longer than necessary but each trigger is informative. The structure is logical and aids scanning.

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?

For a simple read-only lookup tool with two parameters and no output schema, the description adequately covers purpose and usage. It lacks details about return behavior or edge cases, but the annotations and schema fill in safety and parameter information. The tool's low complexity means less is required.

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?

Both parameters have descriptive schema entries with 100% coverage, so the schema already explains meaning. The description's triggers provide real-world examples (e.g., 'dairy-free substitute for X') that map to the dietaryNeed parameter, but this does not add substantial new semantic information beyond the schema.

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 it retrieves ingredient substitutions for dietary needs, allergies, or missing ingredients. The verb 'Get' and resource 'ingredient substitutions' are specific, and the trigger examples further clarify what it does. It distinguishes from sibling nutrition tools by focusing on substitutions rather than analysis or planning.

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 TRIGGERS section explicitly lists example queries that should use this tool, such as 'substitute for X' and 'vegan alternative for X'. This provides clear contextual guidance on when to invoke. However, it does not mention alternative tools or when not to use this tool, so it falls short of the highest bar.

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