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

No annotations provided, so description carries full burden. It discloses the optional webhook for incremental updates, caching advice, and image handling. Does not explicitly mention read-only nature or auth requirements, but covers key behaviors.

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?

Description is dense with useful information, front-loaded with purpose and core details. Slightly long but every sentence adds value. Could be slightly more concise, but well structured.

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 return content (names, prices, images, IDs), caching, image handling, and presentation guidance. Lacks details on error handling or webhook format, but adequate for a dump 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%, baseline 3. Description adds meaning: explains webhook_url is for incremental updates, and gives example for supermarket_domain. Adds value beyond 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 tool dumps the full catalog for a supermarket with specific details (1-2k SKUs, names, prices, images, IDs). It distinguishes from siblings by mentioning alternative tools for normal recipe-to-cart flows.

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 states when to use (catalog dump, market analysis, storefront build) and when not (use pepesto_oneshot or pepesto_products for normal flows). Also provides caching recommendations.

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 provided, so the description carries full burden. It clearly states the tool returns credits with no side effects, but lacks detail on error conditions (e.g., missing key). Still sufficient for simple read 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?

Single sentence, no superfluous words. Every word contributes meaning. Perfectly concise.

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?

No output schema, so description should explain return value. It states returns remaining credits, but lacks format (e.g., number, string). Adequate for simple tool but could be more precise.

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?

Input schema has zero parameters, so schema coverage is 100%. Description adds no param info, which is appropriate. Baseline score of 4 applies as per guidelines.

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 that the tool returns the remaining API credits, distinguishing it from sibling tools like catalog or oneshot. The verb 'Return' and resource 'remaining API credits' are specific and unambiguous.

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?

No explicit guidance on when to use this tool versus alternatives. However, due to its specific function, usage is implied when checking API credits. Missing when-not-to-use or prerequisites.

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 full burden for behavioral disclosure. It mentions internal steps (parse + products + session) and that it returns a redirect_url, but does not cover error handling, idempotency, authentication needs, or potential side effects beyond cart creation. While the core behavior is described, more detail would improve transparency.

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 sentences, each serving a purpose: purpose, output, internal process, usage guidance. It is front-loaded with the main action and efficiently conveys all needed information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple input types, single output) and the lack of output schema or annotations, the description provides adequate context: what it does, what it returns, and when to use alternatives. However, it could be more complete by mentioning possible failure modes or prerequisites, but overall it is sufficient for agent decision-making.

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?

All four parameters are described in the input schema (100% coverage). The description loosely maps inputs to parameters (recipe URLs, free-form text, image) and gives an example for supermarket_domain, but this adds only minor context beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: turning recipe URLs, free-form text, and/or an image into a ready-to-checkout cart for a European supermarket. It specifies the output (redirect_url) and distinguishes itself from siblings by noting it internally runs parse+products+session, and recommends pepesto_parse+pepesto_products for finer control.

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 when to use this tool ('simplest end-to-end flow') and when to use alternatives ('pepesto_parse + pepesto_products + session for finer control'). This provides clear guidance for the agent to choose appropriately.

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 provided; description gives response handling instructions but does not disclose behavioral traits like authorization, rate limits, or error scenarios.

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?

Description is verbose and includes agent instructions (show/hide fields) that could be separate; not concise.

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?

Explains output fields and KgToken but lacks detail on when to use each input type and does not cover return structure.

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%; description adds context linking input types to output but does not detail each parameter's usage comprehensively.

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?

Clearly states verb 'Parse' and resource 'recipe', and enumerates output fields. However, no explicit differentiation from 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?

Describes what to do after parsing (show fields, save kg_token) but lacks guidance on when to use this tool vs alternatives or when not to use it.

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?

Despite no annotations, the description comprehensively discloses behavioral traits: it is free, requires no API key, returns instantly, parsing occurs lazily after link opening, the user is charged (not the API client), and behavior when app is not installed (app store redirect with preserved list).

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 lengthy but well-structured, front-loading the core function and then adding usage guidance, behavioral details, and presentation instructions. Every sentence adds value, though it could be slightly more concise.

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?

Without an output schema, the description fully explains the return format (Markdown with a tappable link and caption) and instructs the agent on how to present it to the user. It also covers edge cases (app not installed) and provides a complete picture of the tool's 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% with descriptions for both parameters. The description adds minimal extra semantic beyond schema, only noting that shopping_list can be multi-line and locale is optional. This is adequate given the high coverage, but does not significantly enhance parameter understanding.

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 tool's purpose: converting a free-form shopping list into a deferred deep link to the Pepesto mobile app. It specifies the key characteristics (free, public, no API key, lazy parsing) and distinguishes it from the sibling pepesto_oneshot tool.

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 explicit guidance on when to use this tool versus pepesto_oneshot, based on cost allocation and timing of basket matching. It also clarifies that this is an end-user/agent-facing handoff, not a developer-integration endpoint.

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 discloses key behavioral traits: merging items across recipes, multiple matches per ingredient for user selection, output fields (title, image, price, classification, promotion), and specific rendering instructions (skip webp images). However, it does not mention idempotency, rate limits, or authorization requirements.

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 paragraph that covers all necessary details without excessive length. It could benefit from bullet points for output fields, but the information is front-loaded with the main purpose in the first 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?

Given the absence of an output schema, the description thoroughly explains the return values (title, image, product_id, price, classification, promotion) and the merging/user-picking behavior. It provides sufficient detail for an agent to understand the tool's function and output.

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 baseline is 3. The description adds only contextual behavior (merging, picking) but does not enhance parameter semantics beyond what the schema already provides (e.g., examples, source hints).

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 'Map' and clearly states the resource transformation: KgTokens to supermarket products. It distinguishes itself from sibling tools that handle parsing (pepesto_parse) or suggestion (pepesto_suggest) by focusing on product mapping.

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 the tool is used after obtaining KgTokens from pepesto_parse or pepesto_suggest, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.

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 discloses that images are licensed for display, that kg_token should be saved for the next step, and provides display instructions. However, it does not mention whether the operation is read-only, auth needs, or rate limits.

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 long and includes instructions for how to handle results, which could be more concise. It mixes tool functionality with behavioral instructions for the agent.

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, the description explains what the output contains (title, image, ingredients, steps, nutrition, allergens, portions, kg_token) and provides instructions on not showing certain fields. It is fairly complete for a search tool but could be more structured.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only has one parameter 'query' with a description that already mentions free-text. The tool description adds some extra context about cuisine, dietary tags, etc., but does not add substantial meaning beyond the schema. Schema coverage is 100%, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches Pepesto's recipe graph by free-text query and optional filters, and mentions it returns results with various details. However, it does not differentiate from siblings like pepesto_catalog or pepesto_oneshot.

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 (searching recipes with filters) and hints at a workflow using the returned KgToken for pepesto_products. But it lacks explicit guidance on when not to use or comparisons to sibling tools.

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