grocy_recipe_copy

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is mostly covered. The description's dry-run note adds a behavioral fact, but it largely restates the confirm parameter's schema description and says nothing about what the write actually does (new recipe ID, name, duplicated contents) or failure modes. Non-idempotency is not called out, leaving the agent unaware that repeated calls create multiple copies.

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?

Three short fragments, zero waste, with purpose first and the dry-run caveat immediately after. Nothing is padded or buried.

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 two-parameter mutation with no output schema, the description is minimally adequate: the agent knows what it does and how to preview. Missing are the outcome (what the copy looks like / what ID is returned) and the non-idempotent consequence of repeated calls, which matter for a write tool.

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 50%: confirm is thoroughly documented in the schema, while recipe_id has no description. The endpoint path in the description implies recipe_id identifies the source recipe to copy, which compensates slightly, but there is no clarification of the ID domain or of the new recipe's handling.

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 and resource ("Copy a recipe") plus the backing endpoint, which cleanly separates it from sibling recipe tools like grocy_recipe_consume and grocy_recipe_fulfillment. It stops short of naming those siblings or stating scope (ingredients/instructions copied?), so it is clear but not fully differentiated.

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 dry-run hint ("Omit confirm for a dry-run") gives real operational guidance on the safe invocation path. There is no explicit when-to-use vs. alternatives guidance, no prerequisites such as permissions or whether the source recipe must exist, so usage is only implied.

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