store

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds non-obvious context: the returned status enumeration, the privacy guarantee (NO buyer PII), and the recommended next step — genuinely useful beyond structured fields.

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 dense sentences, front-loaded with the core action and return contract, then the follow-up routing. No filler.

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

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

With no output schema, the description carries the return burden and does so: it names the coarse status values and the next step, plus the PII guarantee. An agent has everything needed to call it and act on the result.

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 single parameter is fully documented in the schema. The description reinforces that the same session_id flows between create_checkout_link and get_purchase_access but adds no format or constraint detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (poll/check) and resource (checkout session status) and ties itself to the sibling that produces the input (create_checkout_link). An agent can distinguish it from create_checkout_link and get_purchase_access immediately.

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 it (after create_checkout_link) and routes the agent to the alternative (get_purchase_access) with the exact condition ('paid') and argument (same session_id). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds a genuine behavioral contract beyond that: it commits to grounding output strictly in stored metadata and to never fabricating differences or suitability claims. 'Read-only and public' merely restates the annotations, adding no new information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action and cardinality, with no padding. The closing 'Read-only and public' clause is mildly redundant given the annotations, which keeps it from being perfectly economical.

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 two-parameter, fully documented, annotation-backed tool this covers purpose and grounding rules well. With no output schema, it could have said something about the shape of the comparison result, but nothing an agent needs in order to call it correctly 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?

Schema description coverage is 100%, so both parameters are already documented, including the fact that use_case is recorded but not used to invent claims. The description adds no syntax, format, or ID-resolution detail beyond the schema, so the 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?

States a specific verb ('Compare') and resource ('products') plus a hard cardinality bound (2–4), which cleanly separates it from single-product siblings like get_product_details. It also scopes the inputs to stored metadata. It does not, however, name or contrast itself with any sibling tool, so the differentiation is inferred rather than stated.

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 2–4 product constraint and the 'use stored metadata' framing imply when the tool applies (multi-product evaluation), but there is no explicit when-to-use/when-not statement and no alternative named for the single-product or discovery cases. Usage is left to inference from the sibling list.

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?

Goes well beyond the annotations (which only say it is non-read-only, idempotent, non-destructive, open-world) by disclosing that no card is charged autonomously, that price/price-id/name/currency are resolved server-side and client values are ignored or rejected, that the session is short-lived, and exactly what is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the side-effecting warning and keeps every sentence substantive, though the em-dash-laden clauses make it denser than it needs to be.

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

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

With no output schema, the description carries the return-value burden and does so precisely (hosted checkout URL, product summary, exact price, expiry), plus server-side price resolution and product eligibility — nothing an agent needs to call it safely 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining that client-supplied price/amount/currency/name/price-id will be ignored or rejected and that quantity is hard-fixed to 1 — useful given additionalProperties is false.

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

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

States a precise verb+resource ('creates a short-lived Stripe Checkout session/link') and scopes it to ONE product with quantity fixed at 1, which clearly separates it from read-only siblings like get_product_details and search_products.

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?

Marks the tool as SIDE-EFFECTING and states rejection conditions (unaudited/deprecated/not agent-sellable products), which implies when it can be used, but never names an alternative or tells the agent when to prefer a sibling such as get_product_preview or get_purchase_access.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so 'Read-only and public' is largely redundant, but 'public' usefully signals no auth is required. The field-by-field enumeration of the return payload is real behavioral disclosure, especially valuable since no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the purpose stated first, followed by the payload listing. The enumeration is long, but with no output schema each listed field does meaningful work rather than padding.

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

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

With no output schema, the description correctly carries the burden of describing what is returned, and it does so comprehensively. It stops short of covering failure behavior for an unknown or invalid product_id, which is the remaining gap for a single-parameter lookup.

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 schema already documents that product_id accepts a 'store:slug' id, SKU, or unambiguous slug. The description's mention of 'stable product_id/SKU' adds only marginal reinforcement beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Return the full factual detail for one product') and enumerates the exact payload, so an agent knows precisely what comes back. It does not name a sibling to contrast with, so the boundary against get_product_preview or search_products must be inferred from the 'one product' scoping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use, when-not-to-use, or alternative guidance at all. The description never says to use search_products to find an ID first, nor how this differs from get_product_preview, which returns a preview URL that is also listed here.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is partly covered, and the description reinforces 'Read-only and public'. Its real added value is the explicit disclosure of what is withheld (ZIP, private storage URLs, secrets, whole paid source files, signed download URLs), which tells the agent what to expect in the payload and prevents misuse. No auth or rate-limit detail is given, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the first front-loads what is returned, the second front-loads what is never returned, followed by a short safety tag. Every clause carries distinct information and nothing is redundant.

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

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

With no output schema, the description must describe the return shape, and it does so concretely (docs excerpts, file tree, screenshot/demo links, sample snippets) while bounding what is excluded. For a single-parameter read tool this is complete enough to call 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 description coverage is 100% and there is a single documented parameter (product_id), so the schema fully carries parameter meaning. The description adds nothing about the identifier format, 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?

States a specific verb (get/return) and resource (product previews) and enumerates exactly what is returned: documentation excerpts, file-name tree, screenshot/demo links, sample snippets. The negative list (never the purchased ZIP, private URLs, secrets, paid source files, signed URLs) clearly separates it from get_purchase_access and get_product_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The scope ('safe public previews only', 'read-only and public') implies this is the pre-purchase, non-privileged browsing tool, and the exclusion list hints at when to reach for a different tool. However, it never names an alternative sibling or states an explicit condition such as 'use this before purchase; use get_purchase_access for owned items', leaving routing to inference.

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?

Adds substantial behavior beyond the annotations: ~15 min link lifetime, single-purpose scope, ownership proven by an unguessable credential, and crucially that 'each call consumes one of the limited downloads' — which explains why readOnlyHint=false despite a GET-like verb. openWorldHint=true is not elaborated (no rate-limit or failure-mode detail), keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the 'AUTHENTICATED' precondition, then delivers scope, credential mechanism, side effect, and exclusion in four dense but waste-free sentences. Every clause earns its place.

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

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

With no output schema, the description carries the return-value burden and does so ('signed download link', ~15 min lifetime). Auth, scope, and the download-consumption side effect are all covered, leaving nothing an agent needs to call 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 100%, so the baseline is 3; the description goes slightly further by framing session_id and download_token as alternative ownership credentials (an OR relationship) and noting email is audit-only. Most per-parameter detail still lives in the schema, so it adds only modest value.

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

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

States a specific verb and resource ('returns a short-lived signed download link for THEIR order only') and clearly distinguishes itself from listing/browsing siblings via 'Cannot list or access other purchasers' orders.' An agent can tell exactly what this tool produces without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States the precise triggering condition ('for a buyer who already completed a purchase') and an explicit exclusion ('cannot list or access other purchasers' orders'). It does not, however, name a sibling alternative (e.g., check_order_status) for the pre-purchase case, so routing is left partly to inference.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description is not burdened with that. It still adds real behavioral context beyond annotations: default filtering to agent-purchasable products, the fact that include_unsellable surfaces unaudited/deprecated items that are flagged and not buyable, and the thin-result fallback fields (suggestions/did_you_mean/available_domains).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph that front-loads what the tool does before moving to query handling, return format, and the unsellable caveat. Every sentence carries information; it is on the long side but not padded, and the caveat is deliberately placed last.

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

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

With 9 parameters, no output schema, and no required fields, the description does the expected work: it explains the retrieval mode, the response shape, the low-match fallback, and the default-scope behavior. Pagination and price/verified filters are left entirely to the schema, which is acceptable but leaves a small gap for a 9-parameter 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 description coverage is 67%, so the schema carries most of the load (tags, domain, category, verified_only, include_unsellable are all described there). The description adds value only for the query parameter (natural-language handling, stopword/phrase tolerance, synonym expansion) and reinforces the include_unsellable default; it says nothing about page, page_size, max_price_usd, or verified_only.

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

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

States a specific verb and resource ('Search the Datanest catalogue of digital technical products') and specifies the query mode (natural-language intent) and the return shape (ranked product cards with canonical URLs). It is clearly distinguishable from get_product_details or compare_products by verb, but it never names a sibling or explicitly contrasts itself with the retrieve-by-id 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?

Usage is implied rather than prescribed: the query examples hint at when this tool is appropriate, and the include_unsellable note implies a default scope. There is no explicit statement of when to prefer this over get_product_details/compare_products, no mention of what to do when a query is too specific (aside from the implicit did_you_mean fallback), and no exclusions.

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