copy_recipe_to_custom

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

With no annotations provided, the description carries the transparency burden and does well: it discloses that this copies into the account ('creates a private copy'), that dry_run validates/previews without changing the account (side-effect control), and that official recipes are full-fidelity copied. It doesn't state permissions/auth requirements or reversal options, but the mutation nature and dry_run safety valve are well documented.

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 focused short paragraphs, front-loaded with the core action in the first line. Every sentence earns its place: the purpose, the why/context, and the dry_run safety behavior. Zero waste, well structured.

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?

The tool mutates account state but has no annotations (making transparency more critical), has an output schema, and 3 params at 0% schema coverage. The description covers the mutation nature and dry_run well. The main gap is servants semantics and return value behavior (output schema exists so return format need not be detailed), plus permissions. Solid but not exhaustive.

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 description coverage is 0%, so the description must compensate. It explains dry_run semantically ('validate and preview creation without changing the account'), which is genuinely useful. However, recipe_id and servings get no explanation beyond the schema, and servings' behavior (does it scale the copied recipe?) is ambiguous. Partial compensation only.

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 uses a specific verb+resource ('Copy an official Cookidoo recipe into the account's custom recipes') that clearly states what the tool does. It distinguishes itself from siblings by explicitly noting this is the supported path to obtain full recipe content before translating/editing, and the 'dry_run' validation feature is highlighted.

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 description clearly implies when to use it ('the supported way to obtain the full ingredients and instructions of an official recipe before translating or editing it'), which contextualizes it against read-only siblings like get_recipe_details. However, it doesn't explicitly name alternative tools or state when not to use it, so some implicit guidance only.

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