cyberchef_recipe_create

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

The annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) establish that this is a non-idempotent write that does not destroy data, and the description's 'Create' verb is consistent with that. However, beyond confirming the write, the description discloses no behavioral context: it does not say what happens on duplicate names, whether the recipe is persisted server-side, whether operations are validated at creation time, or what the agent should expect in return. With idempotentHint=false, duplicate-handling behavior is especially relevant and is left entirely unaddressed.

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 a single seven-word sentence with the verb front-loaded and zero filler. It is efficiently structured and immediately readable. However, it is arguably thinner than the tool's complexity warrants, which slightly undercuts the conciseness.

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?

This is a mutation tool with 6 parameters, nested objects, no output schema, and 39 siblings including 9 recipe-* tools, yet the description provides only one sentence. With no output schema, the agent cannot infer the return value or success indicators, and the description does not cover them. Missing context around duplicate handling, validation behavior, and relationship to recipe_validate/recipe_test/recipe_import leaves the description incomplete for correct 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?

Schema description coverage is 83%, above the 80% threshold, so the schema carries most of the parameter documentation (name, tags, author, operations, description all have descriptions). The description's 'multiple operations' merely echoes the schema's 'List of operations' field and adds no new semantics. The few uncovered details, such as the inner metadata fields (category, complexity, estimatedTime) and the args/recipe structure inside operations items, are not compensated for by the description, keeping this at baseline.

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 ('Create') and resource ('a new recipe'), and the phrase 'with multiple operations' adds a scoping detail that aligns with the required operations parameter. It is clearly distinguishable from siblings like recipe_delete, recipe_get, and recipe_update by the create verb, though it does not explicitly name or differentiate from recipe_import, which could also be used to bring recipes in.

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?

There is no guidance on when to use this tool versus the many recipe-related siblings (recipe_validate, recipe_test, recipe_import, recipe_update). An agent gets no hints about workflow ordering, such as whether to validate operations before creating, or which sibling handles modifications to an existing recipe. Nothing in the description establishes selection criteria among alternatives.

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