Mon Batch Cooking

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the corpus size and language, and exactly which fields come back (identifiant, temps, calories, portions, lien), which matters because there is no output schema. It stops short of describing match semantics or ordering.

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, zero filler, with the corpus description front-loaded and the return fields appended. Nothing is repeated from the schema or annotations.

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 read-only, 8-filter search with no output schema, the description supplies the return shape and corpus scope, and annotations cover safety. It is nearly complete, missing only result ordering/pagination and whether "texte" matching is fuzzy or substring.

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% across all 8 parameters, including enum values and the 8-default/20-max behavior of "nombre". The description adds nothing about parameter behavior, 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 gives a specific verb ("Cherche") plus a precise resource ("recettes de batch cooking publiées"), with scope qualifiers: a corpus of 300+ recipes, in French. That is enough for an agent to distinguish it from lire_recette (read one) or idees_session, though the siblings are never 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?

There is no statement of when to use this search versus recettes_avec, lire_recette or idees_session, and no mention that all filters are optional or how to narrow an over-broad query. The agent must infer usage entirely from the name and schema.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed world), so the description's job is to add context. It does add genuinely useful behavior: the tool returns an ordered set of exactly 3 dishes plus a dessert, including links. It does not say what happens when filters match nothing or how the ordering is chosen, which keeps it short of 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?

A single front-loaded sentence that states the action, the exact composition of the result, the ordering guarantee, and the presence of links. No filler, no restatement of the title.

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?

There is no output schema, so the description must describe the return value — and it does, precisely (3 plats + une douceur, ordre conseillé, liens). All five parameters are optional and fully described in the schema. The only gap is edge-case behavior, e.g. fallback when no recipe matches the combined filters.

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 all five optional filters (texte, regime, appareil, sansGluten, tempsMaxMin) are already documented in the schema. The description adds no parameter-level meaning at all — notably it never mentions that a diet, appliance, gluten-free, or time constraint can be applied to the session. Baseline 3 is correct when the schema carries the load.

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 names a specific verb (propose) and a specific artifact (une session de batch cooking), and further pins down the output shape: 3 plats différents plus une douceur, dans l'ordre conseillé, avec leurs liens. That composition-oriented purpose is clearly distinct from the sibling tools (chercher_recettes, lire_recette, recettes_avec), though the description never names those alternatives 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?

Usage is implied by the purpose — an agent can infer it should call this when a user wants a multi-recipe cooking plan rather than a single recipe. However, there is no explicit when-to-use statement, no when-not-to-use, and no routing to the sibling tools for single-recipe or ingredient-lookup needs.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description goes further by disclosing the shape of the returned payload (storage/defreezing/reheating guidance, nutrition, allergens), which is real added value given there is no output schema. It does not cover failure modes or unknown-identifier behaviour.

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?

One front-loaded sentence that leads with 'Recette complète' and then enumerates the sections, with no filler. The enumeration is dense but every listed item maps to a section an agent can expect.

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 no output schema, the description correctly carries the burden of describing what comes back, and it does so thoroughly. The remaining gap is the absence of any behavioural note (unknown identifier, missing recipe), which is minor for an idempotent read.

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% and the single parameter already documents both its meaning and its format (e.g. chili-sin-carne-et-riz-complet). The description adds nothing about parameters, 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 enumerates exactly what the resource is (a complete recipe with quantified ingredients, cooking-session steps, plating, storage, nutrition and allergens), which is clear and specific. However, it never states the retrieval act relative to siblings such as chercher_recettes (search) or recettes_avec (recipes filtered by something), so differentiation is left to the tool name.

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 when-to-use guidance, no stated alternative, and no precondition. The only hint that an identifier should come from chercher_recettes lives in the input schema, not in the 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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered. The description adds valuable behavioral context beyond that: results are ranked by ingredient overlap and each result includes both used and to-buy ingredients, which tells the agent what the call produces.

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?

A single front-loaded sentence that packs the action, ranking rule, and return content with no filler. Slightly dense, but 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?

For a read-only search tool with no output schema, the description covers both the retrieval logic and the shape of each result (used vs to-buy ingredients), which is what an agent needs to call and interpret it. Missing only alternative-routing guidance.

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% with clean enum/range docs for all 7 parameters, so the schema carries the semantics. The description adds no additional parameter detail (e.g., ranking sensitivity or how ingredient matching works), leaving the baseline 3.

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 ('Trouve') and resource ('recettes') with a distinguishing ranking criterion: recipes that use the most of the ingredients already on hand. It differentiates implicitly from a generic search by emphasizing pantry-maximizing results, though it does not name sibling 'chercher_recettes'.

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 scope ('ce que l'on a', placard/réfrigérateur) implies the use case of cooking from existing supplies, but there is no explicit when-to-use framing, no prerequisites, and no routing versus 'chercher_recettes' or 'idees_session'.

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