Scaffold a recipe from an existing TD network

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only with respect to TD — no operators are created or modified'. It additionally discloses the file-writing side effect when write_path is set, validation against RecipeSchema, and the structuredContent return path — all beyond the annotations.

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 compact: three sentences that front-load the core relationship to apply_recipe, then pack in serialization scope, validation, output behavior, and read-only guarantee. Every sentence earns its place with 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?

Given the tool has 10 parameters and no output schema, the description adequately explains the return value (RecipeSchema JSON), how it is delivered (write_path or structuredContent), and that validation occurs. The schema covers parameter details, so the description provides enough contextual glue for correct selection and invocation.

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?

The input schema covers all 10 parameters with rich descriptions, so the description does not need to repeat them. It adds high-level context like 'walk a COMP's child network' (which maps to root_path) and the serialized content categories, but it does not add format or syntax details beyond the schema. Baseline 3 is appropriate.

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 opens with 'Inverse of apply_recipe', which immediately distinguishes it from the sibling apply tool. It then specifies the exact action: walk a COMP's child network and serialize it to RecipeSchema JSON. This is a specific verb+resource with clear scope.

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 explicitly names apply_recipe as the inverse alternative, giving an agent clear directional guidance on when to select this tool. It also explains the two distinct usage modes: write_path set (write file) vs. null (return structuredContent), providing concrete context for invocation.

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