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

Annotations only declare readOnly=false, destructive=false, openWorld=true; the description adds the critical side effect that passing items overwrites every existing food in the template — behavior an agent could not infer from the structured fields. It stops short of saying whether omitted fields (name, time, notes) are preserved and what the response contains.

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?

Two short sentences, front-loaded with the action and immediately followed by the one dangerous behavior. No filler.

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 5-parameter mutation tool with 40% schema coverage and no output schema, the definition covers the riskiest part (items replacement) but leaves open whether non-items fields are optional, whether omissions preserve existing values, and what the call returns on success.

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?

Schema coverage is 40%, so the description must carry weight: it explains templateId's origin and the replace-all semantics of items, which is genuinely useful. But name, notes, and most numeric fields are undocumented in both places, and it never clarifies partial-update behavior for those.

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?

States a specific verb+resource ("Changes a meal template") and names the sibling tool that supplies the identifier. It does not distinguish itself from create_meal_template or update_diet_plan, but an agent can tell what it mutates.

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?

Points the agent at list_meal_templates as the source of a valid template, which is useful routing. However, there is no explicit when-to-use/when-not guidance versus create_meal_template or delete-style flows, and no prerequisite/permission context.

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