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

With no annotations, the description carries the full burden; it does disclose the auth prerequisite and the ID-format expectations for the two recipe sources. However, it never says whether items are appended to or replace the existing shopping list, what happens on partially-invalid IDs, or whether quantities are merged — material gaps for a mutation with zero annotation coverage.

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 sentences, front-loaded with the action, then the ID-format caveat, then the prerequisite. Every sentence adds information an agent needs and none repeat the schema.

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?

An output schema exists so return values need no explanation, and the single parameter plus auth prerequisite are covered. The only shortfall is the unstated append-vs-replace semantics of the shopping-list mutation, which matters given no annotations.

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 would be 3, but the description adds real meaning beyond the schema's generic 'Recipe IDs, comma-separated': it gives concrete ID shapes ('r59322' for catalogue, '01M5...' for own recipes) and states both kinds can be mixed in the single string.

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 ('Add the ingredients ... to your Cookidoo shopping list'), which is distinct from every sibling tool (plan_recipe, search_recipes, upload_custom_recipe, etc.) since none of them touch the shopping list. It never names a sibling or contrasts with one, but the resource is unique enough that misselection is unlikely.

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?

Gives a clear prerequisite ('You must be connected first using connect_to_cookidoo') and names that tool explicitly, which routes the agent correctly. It also notes that catalogue and personal recipes can be mixed in one call. It stops short of any when-not guidance, e.g. what to do if the list already has items or whether plan_recipe should be preferred instead.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the implicit input (.env credentials), the authentication action, and the persistent side effect of storing a session. It does not cover failure modes (missing credentials, expired session) or whether re-calling refreshes the session, which keeps it from a 5.

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?

Front-loaded with the core action, followed by the prerequisite and a short numbered sequence of side effects. Every line 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?

For a zero-parameter, no-annotation, authenticated-setup tool with an output schema, the description covers what the tool does, when it is required, and its side effects. It is complete enough to invoke, though error and expiry behavior would make it fully self-contained.

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?

Zero parameters gives a baseline of 4. The description adds useful context that the 'missing' credentials come from a .env file, clarifying an implicit input the schema cannot express.

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 (authenticate) and resource (Cookidoo), plus the side effect of storing the session. The prerequisite line distinguishes it from every sibling tool, all of which are read or plan operations on an already-authenticated session.

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?

Explicitly says 'This tool must be called before using other Cookidoo tools,' which is exactly the routing condition an agent needs. No ambiguity about ordering versus the siblings.

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

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

With no annotations, the description carries the burden and does well: it discloses that this is a generation/validation step (not an upload) and provides detailed Thermomix settings notation that explains how step text is interpreted. It doesn't explicitly state that it has no side effects, but the 'ready for upload' framing implies it. Error handling or validation failure behavior is not described.

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 front-loaded with purpose and then a clear, necessary section on Thermomix settings notation. It is not overly verbose, and each example earns its place. The structure could be slightly tightened (e.g., the mode validation sentence could be integrated better), but overall it is efficient.

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 8 parameters (3 required) and an output schema, the description covers the main complexity: correct syntax for steps and the prerequisite of checking modes. It doesn't explain validation error behavior or detail the output structure, but the output schema fills that gap. It is nearly complete for an agent to use the tool correctly.

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 significant meaning for the 'steps' parameter by explaining the exact Cookidoo notation for Thermomix settings (time/speed, temperature, reverse, soft stir, Varoma). It also ties the 'device' and 'servings' parameters implicitly through context. Other parameters rely on schema descriptions, which are clear.

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 (generate and validate) and resource (recipe structure) and explicitly links it to the upload_custom_recipe tool, distinguishing this preparatory step from the actual upload. An agent can tell this tool is for structuring and validating data before upload without needing to inspect siblings.

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 clearly indicates the tool is used before upload_custom_recipe and that get_thermomix_modes should be called to check modes and their spelling. However, it doesn't explicitly say when not to use it or contrast with update_custom_recipe_steps, but the context is clear enough.

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

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

With no annotations, the description carries the burden and does disclose the auth prerequisite and the useful interop fact that own-recipe steps come back in the notation update_custom_recipe_steps accepts. It leaves out error behavior for invalid or foreign IDs, so it falls short of full disclosure.

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 sentences, front-loaded with the verb, resource and returned fields, followed by ID provenance and the auth prerequisite in priority order. 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?

A read-only single-parameter tool with an output schema, so return values need not be explained. Between the ID format guidance, the sibling cross-references and the connect prerequisite, an agent has everything needed to call this correctly.

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 meaning by giving two concrete ID formats and their sources, which the schema's generic 'The Cookidoo recipe ID' does not. It stops short of stating what happens when an ID of the wrong shape is passed.

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 plus the exact payload returned (ingredients, steps, times) scoped 'by its ID'. This clearly separates it from the sibling search_recipes and list_my_recipes, which produce IDs rather than details.

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?

Gives explicit provenance for the recipe_id (from search_recipes for catalogue recipes, from list_my_recipes for own recipes) and states the required precondition: connect_to_cookidoo must be called first. That is when-to-use plus a prerequisite, not just implied context.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: the list is read live from the Cookidoo recipe editor (so it reflects additions/removals), and content varies by device with TM7 extras called out. It omits the prerequisite that the agent must already be connected to Cookidoo (cf. connect_to_cookidoo) and says nothing about failure or empty-result behavior.

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?

Two sentences, front-loaded with the action and followed immediately by the trigger condition. The parenthetical mode examples and the concrete "3 Min./120°C/Stufe 1" format are load-bearing rather than 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?

An output schema exists, so return-shape explanation is unnecessary, and the description covers selection, freshness, and device variance. The one gap an agent could trip on is the Cookidoo connection/auth precondition, which is not mentioned.

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 earns above baseline by explaining what the device parameter actually changes — TM7-only modes like steaming and browning. The default of TM6 is left to the schema, which 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?

States a specific verb and resource ("List the Thermomix modes Cookidoo offers") plus the secondary value it returns ("how to write them in a step"). This is clearly distinct from the sibling tools that consume the data, such as generate_recipe_structure or update_custom_recipe_steps.

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?

"Call this before writing a recipe that uses modes" gives an explicit precondition and even scopes it (only recipes that use modes). The note that normal time/temperature/speed settings always work prevents unnecessary calls. It stops short of naming the sibling tools it complements or saying what to do if mode lookup fails.

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

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

With no annotations, the description carries the full behavioral burden. 'Show' implies a read-only operation and the connection prerequisite is disclosed, but it does not explicitly state that the operation is non-mutating or describe any error behavior when not connected.

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?

Two tightly written sentences with no wasted words. The primary purpose is front-loaded, followed immediately by the required prerequisite.

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 description covers the core purpose and connection prerequisite, and an output schema exists to explain return values. The schema also fully documents the lone optional parameter, leaving only a minor gap around explicit read-only behavior and alternative selection.

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 100%, so the single optional 'day' parameter and its YYYY-MM-DD format are fully documented in the schema. The description adds no additional parameter meaning, so the baseline score of 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?

States a specific verb and resource: showing recipes planned in the Cookidoo week plan. The parenthetical 'Meine Woche' adds useful domain context, but the description does not explicitly differentiate it from siblings such as list_my_recipes or plan_recipe.

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?

Provides a clear prerequisite ('must be connected first using connect_to_cookidoo'), but does not explain when to use this tool versus alternatives like list_my_recipes or when a week plan might be empty. Usage is largely implied by the tool name and description.

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

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

No annotations exist, so the description carries the full burden. It discloses the authentication prerequisite and the returned fields, and 'List' implies a safe read, but says nothing about ordering, pagination, result limits, or behavior when the user has no recipes.

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?

Two short sentences, zero filler: the scope and return contents come first, the prerequisite second. Every clause earns its place.

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?

With an output schema present, the description needn't explain return values, and it correctly covers the auth prerequisite for a zero-param read tool. The only real gap is absent guidance on result set size or pagination, which matters for a list operation.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter hints are given.

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 ('List ... Cookidoo recipes') and narrows scope to 'your own (created)' recipes, which separates it from the sibling search_recipes that searches the broader catalogue. It also enumerates the returned fields, so an agent knows exactly what it gets.

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 prerequisite 'You must be connected first using connect_to_cookidoo' gives a concrete precondition and names the sibling to run first. It stops short of explicitly contrasting with search_recipes (own vs. all recipes), so the 'when not to use' side is only implicit.

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

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses the authentication prerequisite and that catalogue and own recipes can be mixed, but it does not explain whether planning overwrites or appends to existing meals, how invalid IDs behave, or any side effects of this mutation.

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 two short paragraphs with no wasted words. The action is front-loaded, followed by recipe ID format guidance and the connection prerequisite.

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 simple two-parameter mutation tool with a full schema and an output schema, the description covers the key context: what it does, valid ID formats, and the authentication prerequisite. It could be slightly more complete by mentioning overwrite/append behavior or duplicate handling, but it is largely sufficient 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 100%, so the baseline is 3. The description adds value by clarifying acceptable recipe ID formats with examples ('r59322' and '01M5...') and noting that both catalogue and personal recipes can be mixed, which goes beyond the schema.

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: putting recipes into the Cookidoo week plan for a given day. This is clearly a planning mutation, distinguishable in practice from search/list/unplan siblings, though no sibling is named explicitly.

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 usage context: adding recipes to the week plan, and explicitly requires the user to be connected first via connect_to_cookidoo. It does not state when not to use it, e.g., that unplan_recipe should be used to remove entries, nor does it mention duplicate handling.

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

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

No annotations are provided, so the description carries the full burden; it does so well for a read operation, disclosing the authentication prerequisite and what a result contains (names, IDs, links). It stops short of disclosing pagination limits or rate-limit behavior, which is why it isn't a 5.

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?

Under five short sentences, front-loaded with the core action, then the return shape, then sibling routing, then the auth prerequisite. No sentence is redundant or self-evident.

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?

Output schema exists so return values needn't be fully explained, yet the description still previews the key fields. Combined with the explicit auth prerequisite and sibling routing, an agent has everything needed to call this correctly on the first attempt.

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% and all nine parameters are individually documented in the schema, so the schema does the heavy lifting. The description adds no query-syntax or filtering semantics beyond what the schema already states, so baseline 3 applies.

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?

Specific verb+resource ("Search the Cookidoo recipe catalogue") with immediate scoping: the catalogue excludes the user's own recipes. The agent can distinguish it from get_recipe_details and list_my_recipes without opening any schema.

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?

Explicit routing for every adjacent need: get_recipe_details with an ID for ingredients/steps, plan_recipe for the week plan, list_my_recipes for personal recipes. It also names the prerequisite ("You must be connected first using connect_to_cookidoo"), so an agent knows the ordering constraint.

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

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

With no annotations at all, the description carries the full burden of behavioral disclosure. It correctly signals a mutation (removal) and the auth prerequisite, but says nothing about what happens when the recipe isn't in the plan, whether the removal is reversible, or failure behavior — notable gaps for an unannotated mutation tool.

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?

Two short sentences, the core action stated first and the prerequisite second. 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?

An output schema exists so return values need not be explained, and the auth prerequisite plus day format are covered. The one shortfall is missing edge-case behavior (recipe not planned, idempotency) for an unannotated mutation.

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 100%, so both parameters (day as YYYY-MM-DD, recipe_id from get_week_plan) are already fully documented in the schema. The description adds no format or sourcing detail beyond that, so the baseline 3 applies.

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 (remove) plus resource (recipe from Cookidoo week plan) and scopes it to a given day, immediately distinguishing it from the sibling plan_recipe. An agent can tell exactly what this does without opening the schema.

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 states a clear prerequisite — you must call connect_to_cookidoo first — which is genuinely actionable sequencing guidance. It does not explicitly name the inverse/alternative (plan_recipe) or when-not-to-use conditions, keeping it just short of a 5.

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

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

No annotations, so the description carries the burden and does well: it discloses that the operation replaces rather than appends, that the device comes from the recipe and modes from Cookidoo, and that verbatim ingredient lines become links. It stops short of stating reversibility or what happens on malformed notation, which would matter for a destructive replace.

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?

Front-loads the action, then scope, then prerequisites, then formatting rules — a sensible order. The notation examples add real value, but the parenthetical sibling references and repetition of mode names make it slightly longer than necessary.

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?

Covers everything an agent needs to invoke it correctly — auth prerequisite, replace-vs-merge semantics, required notation format. With an output schema present, return values need not be described, so the only remaining gap is failure/reversibility behavior.

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; the description goes beyond it by specifying the Cookidoo notation required inside the steps string (with concrete examples) and explaining that ingredient lines present verbatim in a step get linked. It does not explicitly tie the optional ingredients parameter to its 'empty means load current from Cookidoo' fallback, though the schema does.

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?

Opens with a specific verb+resource: 'Replace the steps of an existing custom recipe, including Thermomix settings and ingredient links.' That clearly separates it from upload_custom_recipe (create) and generate_recipe_structure (build a skeleton).

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?

Explicitly names the situation ('fix or add Thermomix settings... on a recipe that was already uploaded'), the scope exclusion ('Only the steps are changed; ingredients, times and hints stay as they are'), and the prerequisite ('You must be connected first using connect_to_cookidoo'). It also routes to generate_recipe_structure and get_thermomix_modes for notation forms.

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

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

With no annotations, the description does substantial work: it discloses that Thermomix settings/modes embedded in step text become real settings, that verbatim ingredient lines become links, and that modes are fetched from Cookidoo immediately before upload (an extra live dependency). It omits auth requirements and error behavior, which matters for a write operation with zero annotation coverage.

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?

Front-loaded with purpose, then prerequisite, then behavioral detail in priority order. The third paragraph is dense but every clause carries information; only the quoted example strings add slight bulk.

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?

Output schema exists so return values need not be described, and the single parameter is fully schema-documented. The description supplies the missing pieces an agent needs — the upstream dependency, the implicit side effects, and the live mode lookup — making the definition self-sufficient 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 100% for the single parameter, so the baseline is 3; the description goes further by establishing provenance — the string must be the validated output of generate_recipe_structure — which constrains the expected format beyond the schema's terse note.

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 ("Upload a custom recipe to your Cookidoo account") and clarifies the scope as creating a brand-new recipe from scratch, which separates it from update_custom_recipe_steps. The prerequisite relationship to generate_recipe_structure is made explicit, so an agent can place it correctly among siblings.

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?

Gives a clear precondition: call generate_recipe_structure first and pass the resulting JSON here. The "brand new recipe from scratch" phrasing implies the update sibling is a different tool, but no sibling is named as an alternative and no failure/exclusion cases are offered.

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