NotRobophobic shop

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 does state that the action is additive ('Add') and that it returns the updated basket, which is meaningful. However, it does not mention whether duplicate variants are merged or added separately, any permission requirements, or error behavior. This is adequate but not rich.

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, focused sentences. The first sentence states the core action, the second provides a dependency hint, and the third states the return value. No words are wasted and the most important information 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?

Given the tool's simplicity num (3 flat params, no nested objects, no output schema), the description covers the essential guidance: what it does, where to source the ID, and what it returns. It omits edge-case behavior like quantity handling or basket ownership validation, but those are minor for a straightforward cart-add 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?

Schema description coverage is 100%, so every parameter already has description text in the schema. The tool description adds only a cross-reference to get-product for variant_id and implies the basket_token comes from create-basket. This is complementary but does not go beyond the schema, 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 immediately states the specific action ('Add a product variant to a basket'), which clearly distinguishes it from sibling tools like remove-from-basket, update-basket-item, and view-basket. It also references a companion tool (get-product) for obtaining variant IDs, reinforcing its specific role.

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 by telling the agent to obtain variant IDs from get-producticket and implying this is the tool for adding new items. It does not explicitly state when not to use it, nor does it contrast with update-basket-item, so it falls slightly short of a full 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?

There are no annotations, so the description carries full behavioral disclosure burden. It states that the tool returns an updated basket, but it does not disclose side effects such as whether an existing discount is replaced, whether the operation is idempotent, or what happens with an invalid code. For a state-changing 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?

Two short sentences with no filler. The core action is front-loaded, and the return behavior is stated economically.

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 tool, the description covers the basic action and return value. However, with no annotations and no output schema, it leaves important operational details unstated, such as error behavior and mutation semantics, so it is only minimally complete.

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 parameters are already documented. The description adds no additional meaning beyond the schema, and 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?

The description uses a specific verb ('Apply') and resource ('discount code to a basket'), and clearly states the return value. This makes the tool's purpose obvious and distinguishable from sibling basket operations like add-to-basket or remove-from-basket.

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 should be used when a discount code needs to be applied to an existing basket, but it gives no explicit guidance on prerequisites, invalid codes, or why it should be chosen over sibling tools. Usage context is present but only by implication.

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 it returns a basket_token and instructs to treat it as a secret, adding valuable context beyond the empty schema. It doesn't mention error conditions or state persistence, but for a simple create operation this is adequate. The token secrecy note is a helpful behavioral detail.

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 extremely concise: two sentences with no filler. It front-loads the purpose and immediately follows with the essential return token instruction. 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 tool with no parameters, no output schema, and simple semantics, the description covers all needed information: what it does, what it returns, and how to use the result. The token secrecy warning is a nice addition. Nothing essential is missing.

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?

There are zero parameters, so the schema covers everything trivially. The description doesn't need to explain parameters. Per the baseline for 0 params, a score of 4 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 states a clear verb and resource: 'Create a new basket.' It distinguishes from siblings (add, remove, view, etc.) by being the only creation tool for baskets, and it's unambiguous. The purpose is immediately obvious.

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 implicitly conveys when to use it: before other basket/checkout tools, by requiring the returned basket_token to be passed to them. It doesn't explicitly say 'use this first' but the instruction to 'keep it and pass it to every basket and checkout tool' strongly implies it as the initial step. It doesn't mention alternatives, but none are relevant since it's the only creation 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?

Annotations are empty, so the description carries the burden of behavioral disclosure. It states the required inputs and implies a read-only operation, but doesn't explicitly state that no changes are made, nor does it describe the response format or potential errors. The description adds some context beyond the schema by emphasizing the need for both order number and email, but lacks depth on 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?

The description is a single, concise sentence that front-loads the core purpose and immediately states the required inputs. Every word earns its place, with no redundancy 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 simple read-only status check with two fully documented parameters, the description is mostly complete. However, with no output schema and no annotations, it doesn't describe what the response will look like or any error conditions. An agent could call it correctly, but might be uncertain about the return format.

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 documents both parameters. The description adds the requirement that both are needed together, which is a slight enhancement, but doesn't provide additional meaning beyond what the schema already states. 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 function: checking an order's status. It identifies the specific resource (order) and the action (check status). While it doesn't explicitly differentiate from siblings, the sibling list contains no other order-status tool, so the purpose is 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?

The description provides clear context on when to use this tool: when you need to check an order's status. It also specifies the required credentials (order number and email), which is essential usage guidance. It doesn't explicitly mention alternatives, but no sibling tool serves this purpose, so the guidance is sufficient.

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 response contents (description, options, variants with SKU, price, stock) and hints at downstream use (variant IDs for basket). However, it does not disclose error behavior (e.g., unknown slug), authentication requirements, or side effects, even though 'Get' implies read-only.

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 redundancy. The first sentence front-loads the core purpose and return contents; the second adds a practical usage note about variant IDs. 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?

The tool is simple (one parameter, no output schema, no annotations). The description thoroughly covers the return content, including variant fields and the basket-relevance of variant IDs. It omits only edge-case behavior like not-found handling, but for the intended use it is sufficiently complete.

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 already fully describes the slug parameter with an example. The description simply says 'by slug', adding no new semantic information about the parameter. With 100% schema coverage, the baseline 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?

The description clearly states the tool retrieves a product's full details by slug, enumerating the included fields (description, options, variants with SKU, price, stock). This distinguishes it from siblings like search-products (which searches) and view-basket (which shows basket contents), making the tool's purpose 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?

The description implies usage context by explaining that variant IDs are what you add to a basket, telling an agent why it might call this tool (to obtain variant IDs for basket operations). It does not explicitly name alternatives or state when not to use it, so it misses the top score, but the context is clear.

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 empty annotations, the description carries the full burden. It implies a read-only list operation but doesn't explicitly state side effects, error behavior, or what happens with an invalid country code. It does not contradict annotations, but it adds minimal behavioral context beyond the action itself.

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, well-structured sentence. It front-loads the primary action, then the optional filter, then a practical usage hint. There is zero wasted text and 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 simple tool with one optional parameter and no output schema, the description covers the essential aspects: what it does, the filter, and how the result should be used. It does not detail the return format, but the reference to method ID in start-checkout hints at the output structure. Adequate for this complexity level.

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 meaning by clarifying that the country parameter is an optional filter and specifies the ISO 2-letter format, which goes beyond the schema's brief description. It provides useful context for correct usage.

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 verb 'List' and the resource 'available delivery methods', and adds the optional country filter. It is distinct from all sibling tools, none of which deal with listing shipping methods, and it even cross-references start-checkout to show how the output is used.

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 context by noting the method ID is used in start-checkout, which tells the agent this tool feeds checkout. It doesn't explicitly state when not to use it, but no sibling tool offers similar functionality, so exclusions are unnecessary. The guidance is sufficient.

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. It does disclose that the tool mutates the basket by removing a line and that it returns the updated basket. However, it omits other important behaviors such as idempotency, error handling if the item is not found, permissions, or whether removal is permanent.

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 with no filler. The core action is front-loaded and the return behavior is stated concisely; 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 simple two-parameter mutation, the description and schema cover the basics: what to provide, what it does, and what is returned. It is not fully complete because it lacks guidance on when to choose this tool over siblings and does not address failure or edge-case behavior, but the tool is simple enough that this is not a major omission.

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 coverage is 100%, so the schema already fully documents both parameters, including their sources (view-basket and create-basket). The description adds no extra parameter semantics beyond restating 'line' and 'basket', so the baseline 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?

The description names a specific verb ('Remove') and resource ('a line from a basket'), and 'Returns the updated basket' clarifies the operation's output. This makes it easy to distinguish from siblings like add-to-basket, update-basket-item, and view-basket.

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 guidance is given about when to use this tool versus alternatives such as update-basket-item or view-basket. There is no mention of when not to use it, prerequisites, or how it fits into the basket workflow beyond the schema parameter notes.

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 are empty, so the description carries the full burden. It discloses the return fields but does not explicitly state the operation is read-only, nor does it mention pagination, limits, or side effects. For a simple search tool, this is adequate but not comprehensive.

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 redundancy: the first states the action and scope, the second states the output and points to an alternative. Front-loaded and 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 the simple tool (1 param, no output schema), the description explains the key return fields but does not specify the exact response structure (e.g., array vs. object) or pagination. It is reasonably complete for the complexity but could be more explicit.

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 already documents the only parameter (query) with a description, and coverage is 100%. The description adds little beyond the schema—it ties the query to the search action but does not introduce new semantics, so a baseline 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?

The description clearly states the action ('Search the shop catalogue'), the resource, and what it returns ('matching products with their slugs, price and stock availability'). It also distinguishes itself from the sibling get-product by directing agents to that tool for full details, making its scope 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?

It explicitly names an alternative (get-product) and implies when to use each: this tool for search results, get-product for full details and variants. This provides clear usage context, though it does not enumerate other conditions or exclusions, so a slightly lower score is given.

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 does well: it explains the two payment paths, warns 'Never claim to have paid — confirm with get-order-status,' and notes the reduced address requirement for digital-only baskets. It could add more about side effects beyond converting the basket, but the key behavioral caveats are present.

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 and every sentence adds useful context: payment methods, the never-claim-paid warning, and address requirements. It is slightly longer than strictly necessary but remains efficient and well organized.

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 essential outcomes (order creation, payment links), the two payment methods, the follow-up step via get-order-status, and digital-only address handling. There is no output schema, but the description gives enough return-value context for an agent to proceed.

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 schema already documents each parameter. The description reinforces shipping_address behavior for digital-only baskets but adds little new meaning beyond the schema. This matches the baseline for high 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?

The description opens with a specific verb and resource: 'Turn a basket into an order and get payment links.' It clearly distinguishes this checkout action from sibling basket-management tools like add-to-basket and view-basket, and the payment-link focus separates it from get-order-status.

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 clear context: use this when a basket is ready to become an order and payment links are needed. It also directs the agent to get-order-status for confirmation and clarifies address requirements for digital-only baskets. It does not explicitly state when not to use the tool, but the guidance is strong.

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 of behavioral disclosure. It states the effect (change quantity, remove at 0) and the return value (updated basket). It does not mention error handling or side effects beyond the direct mutation, but for a simple update tool this is adequate and not contradictory.

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. It front-loads the core action, then states the removal behavior and return value, all in an efficient structure.

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 simple with 3 required parameters and no output schema, but the description notes the return value. It covers the primary use case and behavior, though it omits error scenarios or explicit guidance on when not to use it. Given the low complexity, this is reasonably complete.

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 each parameter is already well-documented in the schema (e.g., item_id is the basket line ID from view-basket, quantity is the new quantity, 0 removes). The description adds no additional semantics beyond what the schema provides, so it meets the baseline for high 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?

The description uses a specific verb ('Change') and resource ('basket line'), and clarifies the special case of quantity 0 removing the line. It clearly distinguishes from siblings like remove-from-basket and add-to-basket by focusing on quantity updates.

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 (to update quantity) and notes the removal behavior, which indirectly differentiates it from remove-from-basket. However, it does not explicitly state alternatives or exclusion conditions, so it falls short of a perfect score.

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 disclosure burden, and 'View' clearly signals a read-only operation with no mutation. It also discloses what the call returns, though it does not describe error cases or require auth caveats, which are minor for a simple view 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?

The description is a single, tightly written sentence that front-loads the key verb and resource before enumerating the returned data. Every word contributes meaning, with no filler or 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?

For a simple single-parameter read operation, the description is nearly complete: it states the action, the resource, and the returned elements. The absence of an output schema is partially offset by listing 'lines, quantities and subtotal', though it stops short of detailing edge cases or 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?

There is only one parameter and the schema description already fully documents it ('The basket token from create-basket.'), so schema coverage is 100%. The tool description adds no additional parameter-level meaning beyond the tool's purpose, matching the baseline for fully covered schemas.

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 ('View') and resource ('a basket'), and specifies the exact contents returned: lines, quantities and subtotal. This clearly distinguishes it from sibling mutation tools like add-to-basket, update-basket-item, and remove-from-basket.

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 appropriate use case: when you need to inspect a basket's current contents and total. However, it does not explicitly state when not to use it or point to alternatives, although sibling names make some of that context inferable.

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