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

The description usefully discloses sequential execution, per-entry independence, failure isolation, and the dry_run default, which is valuable safety context given no annotations are provided. However, it omits the confirm gate ('Must be true to execute') and does not clarify what a dry run returns or that actual persistence requires confirm=true and dry_run=false. This is a notable but not fatal behavioral gap.

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 four short sentences that front-load the core purpose and then add execution semantics, failure isolation, and the dry-run default. There is no filler, and every sentence contributes to an agent's ability to understand and invoke the tool.

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 bulk mutation tool with no annotations and no output schema, the description covers the core algorithm, sequential/independent execution, and the dry-run safety default. The main missing piece is explicit mention of the confirm flag, but the schema already documents that, so the description is reasonably complete for 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?

Schema description coverage is high (83%), so the baseline is 3. The description adds some algorithmic glue, such as cloning template_recipe_id via scale_recipe and swapping the designated ingredient line with each entry's ingredient_id, but it does not systematically illuminate parameters like confirm or delay_ms beyond what the schema already states.

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 'The copy-and-swap loop' and then spells out the exact per-entry sequence: clone template_recipe_id via scale_recipe, rename it, then replace the designated ingredient line. This clearly distinguishes the tool from siblings like scale_recipe (single clone) and bulk_create_subrecipes (bulk create without swap), so an agent can identify its purpose without ambiguity.

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 frames this as a batch loop over entries, which signals when to use it over single-item operations like scale_recipe. It does not explicitly name alternatives or say 'use this instead of X', but the 'for each entry' construction and the reference to scale_recipe provide enough context for an agent to infer the batch use case.

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?

There are no annotations, so the description fully carries the behavioral burden. It discloses the dry-run default, states that nothing is touched in dry-run mode, explains the exact conditions required to execute, and mentions the per-recipe success/failure report with new ingredient_ids. This is unusually complete for a 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?

Three compact sentences carry all essential information: what the tool does, the safe default, the exact execution condition, and the return value. The most important safety information is front-loaded, and every sentence 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 bulk mutation tool with no output schema and no annotations, the description covers purpose, safety, execution conditions, and the returned report format sufficiently. It could be slightly more complete by explicitly noting the alternative single-item path, but it already gives an agent enough to call and interpret 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. The description adds meaningful interaction semantics beyond the schema: dry_run defaults to true, and both dry_run:false and confirm:true are required together to execute. It also connects 'sequentially' to the delay_ms parameter concept, adding value over the raw 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 clearly states the action: 'Flag many recipes as subrecipes, sequentially.' It identifies the resource (many recipes) and the bulk nature, distinguishing it from the singular create_subrecipe sibling by implication, though it does not explicitly name the alternative or clarify the naming mismatch between 'create' and 'flag'.

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 gives concrete execution guidance: dry_run defaults true, and execution requires both dry_run:false and confirm:true. This tells the agent exactly when and how to safely invoke the tool, but it does not explicitly state when to choose this tool over create_subrecipe for single-recipe cases.

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 behavioral burden. It discloses that the resulting recipe is 'empty' and that the operation is a POST to /recipes, which signals a non-idempotent create. However, it does not mention required permissions, side effects, or what happens on success or failure, so important behavioral context is still missing.

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 sentences with no filler. The core action is front-loaded, the endpoint is a useful quick signal, and the alternative guidance is tucked naturally into the second sentence.

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 plus the rich schema is largely complete for invoking the tool: the agent knows what it creates, when to use an alternative, and what fields are expected. The main gap is that there is no output schema and the description doesn't state what the API returns, which could matter for chaining the created recipe into subsequent calls.

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 parameters are already well documented in the input schema. The tool description itself adds no parameter-level detail, but that is acceptable because the schema provides example attribute names and warns about tag behavior.

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 clear action and resource: 'Create a new empty recipe' and even gives the endpoint POST /recipes. The word 'empty' distinguishes it from clone-style operations, and the sibling list shows alternatives like create_recipe_shortcut and create_subrecipe, so there is no ambiguity about what this tool creates.

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 explicitly tells the agent when to prefer an alternative: 'Prefer scale_recipe (clone a fully-configured template) when you need label settings to match existing recipes.' This gives a concrete, decision-relevant condition rather than leaving the agent to infer when scale_recipe should be used.

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 of behavioral disclosure. It reveals it is a POST creation endpoint but does not mention side effects, ordering, duplicate handling, permissions, failure modes, or response behavior. For a mutating tool this is a meaningful gap.

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 sentences, front-loaded with the core action, and contains no filler. The endpoint and the two payload alternatives are stated compactly without sacrificing clarity.

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?

Core invocation is covered: the endpoint and accepted payload shapes are clear. But with no output schema, no annotations, and a nested fields object, the description omits the meaning of as_json, return details, and preconditions like the recipe needing to exist. An agent could call it for basic cases but not with full confidence.

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 low (33%), so the description must compensate. It adds valuable OR-logic: ingredient_id with unit+quantity, or total_grams, which goes beyond the schema's flat field list. However, the as_json parameter remains completely undocumented, and the nested field names are already present in 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: 'Add an ingredient line to a recipe.' This is easily distinguished from siblings like create_recipe (whole recipe creation) and update_recipe_ingredient (editing an existing line). Including the endpoint further removes ambiguity.

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 verb and resource imply the tool's use case: when you need to add a new ingredient line to an existing recipe. However, the description does not explicitly mention alternatives or situations when this tool should not be used, such as updating an existing line with update_recipe_ingredient. Context is present but exclusions are absent.

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 it discloses a critical non-obvious behavior: label settings are not inherited, so serving size, package yield, and tags come back unset. It also notes the POST endpoint and the parallel-list constraint. It does not describe error behavior or authentication, but the material caveats are covered.

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 the core purpose, then the endpoint, then usage context, then parameter constraints, then the critical caveat and alternative. Every sentence adds value, and the structure makes it easy for an agent to extract the key facts quickly.

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 definition is quite complete for a complex creation tool: it explains the endpoint, required nested fields, constraints, and the key behavioral caveat about label settings. However, there is no output schema and the response shape is not described, so the agent still lacks full information about what the tool returns.

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 only 50%, so the description must compensate. It does by clarifying that ingredient_ids and ingredient_weights are required, must be parallel lists of equal length, use grams, and may be arrays or comma-separated strings. The as_json parameter is left undocumented, but it is a simple boolean and the more complex fields parameter is well explained.

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 a specific verb and resource: 'Create a complete recipe with its ingredients in one request.' This clearly differentiates it from sibling tools like create_recipe and create_recipe_ingredient by emphasizing the combined recipe-plus-ingredients behavior and the shortcut endpoint.

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 positions this as 'the fastest path for building many recipes' and provides an alternative: 'use scale_recipe to clone a configured template when label settings matter.' This gives the agent a clear when-to-use and when-not-to-use rule with a named sibling alternative.

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 bears the full burden. It does disclose the mutation effect ('Flag an existing recipe as a subrecipe') and the return behavior ('Returns the new ingredient record — capture its ingredient_id'), which is helpful. However, it does not mention reversibility, permissions, idempotency, or potential side effects on the original recipe record.

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 carry the core purpose, the endpoint, the return value, and actionable follow-up instructions. There is no filler, and the most important behavior is front-loaded.

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 gives the essential flow for the main use case and names the output field to capture. But because there is no output schema and no annotation context, the vague optional fields object and the unexplained as_json flag leave an agent with uncertainty about edge cases and response formatting.

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 endpoint string ('POST /recipes/{id}/create_subrecipe') and the phrase 'existing recipe' imply that recipe_id is the ID of an existing recipe. The schema already documents fields as optional attributes. However, as_json is not explained anywhere, and the description does not add detail about what kinds of fields are accepted despite the schema coverage being only 33%.

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 action ('Flag an existing recipe as a subrecipe') and explains the consequence ('so it becomes usable as an ingredient in other recipes'). This clearly distinguishes it from sibling tools like create_recipe or create_recipe_ingredient, and the endpoint reference reinforces what resource is affected.

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 provides clear context for when to use the tool: when an existing recipe should be promoted to a subrecipe/ingredient. It also tells the agent what to do with the result, but it does not explicitly contrast with alternatives such as bulk_create_subrecipes or explain when not to use this tool.

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 transparency burden. It accurately discloses that the call retrieves one ingredient and that the response contains nutrition data and available units, but it does not describe behavior for missing IDs, error handling, or any access constraints.

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 front-loaded sentence with no wasted words. It names the action, object, and key response contents in a compact and scannable form.

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 one-parameter getter, the description names the returned data and is not misleading. Still, with no output schema, no annotations, and siblings like get_recipe_ingredient and list_ingredients, it lacks enough context to fully disambiguate the correct tool and confirm response semantics.

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 only parameter, ingredient_id, is self-descriptive, and the description reinforces that it selects a single ingredient. However, schema description coverage is 0%, and the description does not explain the expected ID format or how to discover valid IDs, leaving the agent with only the property name and type.

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 ('get'), a clear resource ('one ingredient'), and the response scope ('full nutrition data and available units'). This distinguishes it from list_ingredients (a plural listing) and implies it is a master-ingredient lookup rather than a recipe-scoped ingredient lookup.

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 gives no explicit guidance about when to use this tool instead of related tools such as list_ingredients or get_recipe_ingredient. It implies a single-record lookup, but it provides no exclusions, prerequisites, or alternative routing.

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 behavioral burden; it explicitly labels the call as reading exact settings and enumerates the returned fields, making the read-only nature apparent. It omits error/authorization details, which are not central for a simple getter.

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 with no filler: the first front-loads the operation and contents, the second adds a precise usage trigger. Every part 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?

The tool is a simple single-id getter with no output schema; the description adequately covers what the response contains and when to call it. No critical missing context remains 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 coverage is 100% and the sole parameter recipe_id is already described as 'ReciPal recipe ID.' The description adds no further parameter-level meaning, so the baseline of 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?

States the specific operation 'Get one recipe in full' and enumerates the returned content (nutrition, serving size, package yield, tags, label settings). This clearly distinguishes it from the nutrition-only sibling get_recipe_nutrition and other recipe-specific getters.

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 directs the agent to use this tool 'to read a template recipe's exact settings before cloning it,' giving a concrete trigger. It does not enumerate when to prefer siblings such as get_recipe_nutrition or list_recipe_ingredients, but the use case is clear enough for selection.

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 of explaining behavior. It indicates a read operation via 'Get,' but does not disclose the response shape, error behavior, authorization requirements, or any reliance on the recipe context. This is not misleading, but it adds little behavioral detail beyond the tool name.

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 front-loaded sentence with no filler or redundancy. Every word contributes to identifying the resource and the operation, making it easy for an agent to parse quickly.

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 read-only getter with two self-explanatory ID parameters, the description is minimally sufficient. However, with no annotations, no output schema, and no mention of relationship to sibling tools like list_recipe_ingredients or get_ingredient, it leaves some context gaps that an agent would need to infer.

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%, and the description does not explain either parameter. The names recipe_id and recipe_ingredient_id are reasonably clear, but the description does not clarify that recipe_ingredient_id identifies a line within the recipe or indicate where these IDs come from, so it does not compensate for the lack of schema-level parameter documentation.

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 the specific verb 'Get' with a precise resource, 'one ingredient line on a recipe,' which clearly distinguishes it from list_recipe_ingredients (which returns multiple lines) and get_ingredient (which would fetch ingredient master data rather than a recipe-specific line). The singular phrasing signals exactly which resource the agent will retrieve.

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 singular 'Get one' implies this tool is for fetching a specific recipe ingredient line when both IDs are known, rather than listing all lines. However, the description does not explicitly state when to use it over alternatives, mention how to obtain the required IDs, or rule out sibling tools, so the usage guidance 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 behavioral burden. It discloses that the response is limited to the nutrition sub-object, which is valuable. However, it does not mention error behavior, whether nutrition may be absent, or any authentication requirements, leaving some behavioral context unspecified.

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, focused sentence with no filler. The key qualifier 'only' is front-loaded, making the tool's scope immediately clear.

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 one-parameter read-only retrieval tool, the description provides the essential return-semantics: the nutrition sub-object. It does not explain the content of that sub-object, but with no output schema and a simple operation, the agent has enough information to invoke the tool correctly with recipe_id.

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 schema only defines recipe_id with zero description coverage, and the tool description does not explicitly explain the parameter. The mention of 'a recipe' provides contextual anchor for recipe_id, but the description does not add details about format or how to obtain the ID. Since the parameter name is self-explanatory, the gap is moderate.

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 clearly states the action ('Get') and the specific resource ('only the nutrition sub-object for a recipe'). The word 'only' explicitly distinguishes it from broader tools like get_recipe, leaving no ambiguity about its 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?

The phrase 'only the nutrition sub-object' conveys a clear use case: when just the nutrition data is needed rather than the full recipe. It does not explicitly name alternatives or exclusion conditions, but the selectivity is strongly implied.

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 behavioral transparency burden. It discloses important pagination behavior: per_page max 20, larger values silently reduced, and that callers must paginate. It also mentions that subrecipes appear in the list, which is a non-obvious behavior useful to callers.

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 sentences, no filler, and information is front-loaded with the core purpose first. Each sentence earns its place: purpose, use case, and pagination caveat.

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 list tool with no output schema, the description covers the essential operational details: account scope, pagination behavior, silent cap, and the use case for finding ingredient_id. It does not describe the response shape, but the description gives enough for an agent to know what the tool returns and how to invoke it 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 67%, but the description adds little beyond the schema. It repeats the per_page cap that the schema already documents, and provides no additional meaning for the page or search parameters beyond what the schema minimally says. The undocumented page parameter is not explained in the description.

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 clearly states the operation: 'List the account's ingredient library.' It distinguishes itself from siblings like list_recipes (recipes vs. ingredients) and list_recipe_ingredients (ingredients within a recipe) by specifying the ingredient library scope. The added context about subrecipes and ingredient_id clarifies its unique purpose.

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 gives a specific use case: finding the ingredient_id needed to add a subrecipe to another recipe. However, it does not explicitly contrast with list_recipes, get_ingredient, or list_recipe_ingredients, so the when-to-use guidance is implied rather than clearly stated.

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 provided, the description carries the burden of behavioral disclosure. It discloses the returned fields and the scope ('every ingredient line'), but it does not mention whether the operation is read-only, whether there is pagination/ordering, or how subrecipes are handled.

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 one tightly scoped sentence that leads with the action and resource, then enumerates useful output fields. There is no filler or redundant restating of the tool name.

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 one-parameter list tool with no output schema, the description adequately conveys what is returned and implies the input. It could be more complete with explicit usage boundaries or parameter semantics, but it is largely sufficient for an agent to invoke it 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?

The single recipe_id parameter has no schema-level description and overall schema coverage is 0%. The description indirectly clarifies that recipe_id identifies the recipe whose lines are listed, but it does not explicitly document the parameter or provide format/source context.

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 ('List') and resource ('every ingredient line on a recipe') and names the exact output fields (recipe_ingredient IDs, ingredient IDs, quantities, units, total_grams). This clearly distinguishes it from siblings like get_recipe_ingredient (singular) and list_ingredients (global ingredient catalog).

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 implies when to use the tool: when you need all ingredient lines for a given recipe. However, it provides no explicit guidance about when to prefer get_recipe_ingredient for a single line or list_ingredients for a catalog, and it names no alternative tools.

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 transparency burden. It discloses the pagination behavior, the hard cap of 20, the silent reduction of larger values, and the need to paginate. This is valuable behavioral context beyond the bare schema and accurately signals that this is a read-only list operation.

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 sentences with no filler. The first sentence front-loads what the tool returns, and the second adds the essential pagination warning. Every word 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 simple, read-only list tool with fully documented parameters, the description covers what is returned, the pagination constraint, and the caller's responsibility. No output schema exists, but the described fields are enough for an agent to understand the result shape.

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 schema already explains page and per_page in full. The description's mention of per_page max 20 and silent reduction mainly reiterates what the schema says, adding no new parameter-level meaning. Baseline 3 is appropriate here.

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 ('List'), a concrete resource ('recipes from ReciPal'), and the included fields ('IDs, names, and tags'). This clearly distinguishes it from the relevant siblings, such as get_recipe for fetching a single recipe or list_recipe_ingredients for a different resource.

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 establishes when to use this tool: to list recipes, with the important caveat that results are paginated and per_page is capped at 20. It does not explicitly mention alternatives or conditions for choosing get_recipe instead, but the list-vs-get context is strongly implied by the wording.

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 behavioral burden and largely meets it: it discloses the copy-and-swap semantics, notes that label settings and tags are carried forward, and warns that endpoint parameter names are unpublished. It does not cover response or error behavior, but the core mutation intent is clear.

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 and front-loaded: operation, endpoint, behavioral intent, and scale-factor guidance in three short sentences. Every sentence earns its place, and no filler is present.

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 tool with no annotations and no output schema, this description is strong: it covers the copy-and-swap scenario, the optional scale factor, and the unpublished-fields risk with a practical workaround. The main remaining gap is the meaning of as_json and the absence of return-value 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?

The fields object is given a concrete example with name and scale_factor, plus a practical caveat about unpublished parameter names, adding real value beyond the schema. recipe_id is adequately described in the schema, but as_json remains unexplained in both the description and 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 names a concrete action ('Copy (and optionally scale) an existing recipe') and a specific resource, and adds meaningful context by explaining that cloning a configured template carries label settings and tags forward. This clearly distinguishes it from create, update, and bulk-clone sibling tools.

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 identifies the intended use case: cloning a configured template and then replacing one ingredient afterward, and it clarifies that a scale factor of 1 produces a straight copy. It does not explicitly name alternatives or exclusion conditions, so it stops 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?

With no annotations, the description must carry the full behavioral burden, but it only restates the mutation and offers a use example. It does not disclose whether the update is partial or a full PUT replacement, what fields are accepted beyond name, whether auth is required, what the response looks like, or any side effects.

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 and front-loaded: it states the operation, the endpoint, and the intended use case in two sentences. There is no repetition or 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 mutating tool with no annotations, no output schema, an undocumented 'as_json' boolean, and a flexible nested 'fields' object, this description is not complete enough for fully safe autonomous invocation. It gives good purpose but lacks behavioral and response details.

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 description adds meaning to the 'fields' parameter via the renaming use case and connects ingredient_id to the resource path. However, schema coverage is only 33%, and the 'as_json' parameter is completely unexplained in both schema and description, so the description only partially compensates.

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 clearly states the operation (update), the resource (an ingredient in the library), and the exact HTTP endpoint (PUT /ingredients/{id}). The phrase 'in the library' helps distinguish this from sibling tools like update_recipe_ingredient, which operate at the recipe level.

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 gives an explicit use case: renaming ingredients, such as stripping '(copy)' suffixes. It does not explicitly name alternatives or state when not to use the tool, but the library context and concrete example provide clear practical guidance.

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. It adds useful behavioral detail: tags are silently ignored or error depending on shape, and keys are passed through to ReciPal namespaced under the resource. However, it does not disclose whether the update is partial or full replacement, what the response contains, or any side effects or permissions.

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 core description is a single front-loaded sentence with the endpoint, and the longer parameter description is dense with useful caveats rather than fluff. The scale_recipe note is slightly tangential but not wasteful.

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 no output schema and no annotations, the description should cover return/error behavior and update semantics; it does not. But it does provide enough field-level guidance and a prerequisite for an agent to likely call the tool correctly for the main use case.

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 fields parameter is richly explained with example keys, namespacing behavior, and a get_recipe first instruction, compensating for low schema coverage. However, as_json is left undocumented, and recipe_id only appears by name and in the URL pattern, so the description does not fully compensate for the 33% schema coverage.

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 the exact operation: updating a recipe's attributes, reinforced by the PUT /recipes/{id} endpoint. The resource (recipe, not recipe_ingredient or ingredient) and action are unambiguous, distinguishing it from siblings like update_recipe_ingredient and create_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?

The description implies usage for modifying an existing recipe and gives a practical prerequisite (call get_recipe first to see account-specific attribute names). It does not explicitly say when to prefer this tool over alternatives such as create_recipe or scale_recipe, and only notes an exclusion for tags.

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 behavioral disclosure burden. It goes beyond the schema by revealing that the endpoint silently ignores ingredient_id and returns 200 with the original ingredient still attached. This is a significant non-obvious behavior that would otherwise lead to silent data corruption. It does not describe all side effects or response details, but the most critical trap is disclosed.

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 and front-loaded: it states the operation, gives the endpoint, then flags the critical caveat and workaround. Every sentence earns its place with no redundant wording.

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 mutation tool with no annotations and no output schema, the description covers the core operation and the main failure mode well. However, it does not explain what the response contains beyond a 200 status, and the as_json parameter remains unexplained. The tool is usable for a simple update, but the context around parameter behavior and return value is incomplete.

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 only 25%, so the description needed to compensate. The PUT path usefully maps recipe_id and recipe_ingredient_id, and the note reinforces that ingredient_id is ignored. However, as_json is entirely undocumented in both the schema and the description, and the fields object's allowed keys are only partially addressed through schema text, not the description. This leaves a meaningful semantic gap.

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 clearly states the action and resource: 'Update one ingredient line,' reinforced by the PUT path identifying recipe and recipe_ingredient IDs. It is specific enough to distinguish updating a recipe ingredient line from updating a recipe or an ingredient master record, though it does not explicitly name sibling alternatives.

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 gives explicit when-to-use guidance ('Update one ingredient line') and clear when-not-to-use guidance: attempting to swap an ingredient via ingredient_id silently fails, and the tool must not be used for that purpose—delete and create instead. This directly prevents a likely misuse.

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