weekplan_edit_ingredient

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

Annotations provide only idempotentHint=true, so the description carries most of the burden and delivers: patch-style semantics for omitted fields and the guarantee that the id is immutable so recipe references stay intact. It omits permission/auth requirements and error behavior for an unknown id, but the mutation risk profile is well disclosed.

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?

Four short sentences, front-loaded with the operation, then update semantics, then the id-stability rationale, then the naming constraint. No filler sentences.

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 three-parameter mutation with no output schema and minimal annotations, the description covers the essentials an agent needs: what it changes, how partial updates behave, and the id invariant. Return shape and failure modes for an invalid id are unaddressed but minor at this complexity.

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 100%, so the baseline is 3, but the description adds real value beyond the schema: the partial-update contract for optional fields and a language constraint ('Always use Dutch for the name') that no schema field encodes.

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 states a specific verb and resource ('Edit an existing ingredient by id'), which cleanly separates it from the list/add/delete ingredient siblings even though none are named explicitly. An agent can identify the operation immediately.

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?

It gives clear context on how to invoke a partial update ('supply only the fields you want to change; omitted fields keep their current values'), which is the key usage decision for an edit tool. It does not, however, explicitly state when to prefer this over add_ingredient or delete_ingredient.

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