store

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

The description adds useful behavioral context beyond the annotations, such as returning a coarse status (paid|open|expired|unknown) and guaranteeing no buyer PII. This complements the readOnlyHint and openWorldHint annotations without contradicting them.

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, front-loaded with the core action and outcomes. Every sentence earns its place: what it does, what it returns, and the next step. No wasted words.

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 (single param, no output schema), the description is complete: it covers the status values, the absence of PII, and the recommended follow-up action. The strong annotations cover safety, so nothing else is needed.

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 provides a detailed description of checkout_session_id (including that it is returned by create_checkout_link). The description largely repeats this, adding only the 'same session_id' for the subsequent get_purchase_access call, which is minimal extra 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?

The description clearly states it polls the status of a checkout session, using the specific verb 'poll' and naming the resource. It distinguishes itself from siblings like get_purchase_access, which is for obtaining the download link after payment.

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 gives clear usage context: use after create_checkout_link, and provides an explicit next step to call get_purchase_access when status is paid. However, it does not explicitly state when not to use this tool or mention other alternatives for non-paid statuses.

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. The description adds valuable behavioral guarantees: 'Never fabricates differences or suitability claims' and 'using only stored metadata,' reinforcing the closed-world, fact-based nature. It also adds 'public,' which is not in the annotations, giving extra context.

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 purpose, followed by the key behavioral constraint. Every word earns its place; no fluff or redundant detail.

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 (2 parameters, no output schema) and the description covers the essential behavioral contract: what it compares, data sources, and constraints. It does not specify return format, which might be a minor gap, but the low complexity and clear purpose make this acceptable.

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%, with both product_ids and use_case described in the schema. The description reinforces that use_case is 'recorded, not used to invent claims,' but adds little beyond the schema's own descriptions. Baseline of 3 is appropriate because the schema carries the parameter meaning.

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 'Compare' with a specific resource ('2–4 products') and a precise scope ('using only stored metadata'). It distinguishes itself from sibling tools (check_order_status, get_product_details, etc.) by focusing on multi-product factual comparison rather than order or single-product lookups.

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 a clear use case: compare multiple products factually. It states constraints (2–4 products, only stored metadata) but does not explicitly mention when to avoid this tool or point to alternatives. The context is clear, but lacks direct exclusions or alternative references.

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?

Discloses key side-effects: 'SIDE-EFFECTING', no autonomous card charge, server-side price resolution ignoring client-supplied values, and the exact return payload. Annotations already signal readOnlyHint=false and idempotentHint=true; the description adds the crucial trust-boundary and payment-authorization context.

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?

Four sentences, each packed with distinct information. Starts with an explicit 'SIDE-EFFECTING' warning and flows logically through creation, server-side resolution, payment authorization, and product eligibility rejection.

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 create operation with no output schema, the description explicitly defines return values (URL, product summary, price, expiry), side effects (no autonomous charge), and acceptance criteria. It provides sufficient information for an agent to invoke the tool safely and 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 covers all parameters with 100% description coverage, but the description reinforces that quantity must be 1 and explains that client-supplied price/amount/currency/name/price-id are ignored/rejected, clarifying that product_id is the sole driver. This adds important meaning beyond 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 uses a specific verb 'creates' and identifies the resource: 'short-lived Stripe Checkout session/link for ONE product'. It also specifies exact return values, clearly distinguishing this from read-only sibling tools like get_product_details and check_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?

Provides clear context: intended for single-product checkout with quantity fixed to 1, and rejects ineligible products ('unaudited/deprecated/not agent-sellable'). However, it does not explicitly name alternative tools or state when not to use beyond product eligibility, though sibling tools are clearly read-only.

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; the description adds 'Read-only and public' and a comprehensive list of returned fields, which goes beyond the annotation. It also notes the product_id/SKU is 'stable', providing additional behavioral context beyond annotations.

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 long sentence, but every phrase names a specific returned field, earning its place. It front-loads the core purpose and then lists details efficiently, though it is slightly verbose.

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 a single parameter, no output schema, and strong annotations, the description fully compensates by enumerating all output fields, declaring read-only/public behavior, and noting the stable identifier. It provides everything an agent needs to invoke the tool and understand results.

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 covers the single parameter product_id comprehensively with a clear description of accepted formats. The tool description adds only 'stable product_id/SKU' which is marginal; 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 uses a specific verb ('Return') and resource ('full factual detail for one product'), then enumerates exact fields returned. It clearly distinguishes itself from siblings like get_product_preview and search_products by emphasizing comprehensive detail for a single product.

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: when full, factual details for a specific product are needed. It does not explicitly name alternatives or state exclusions, but the field enumeration and 'one product' scope make the usage context obvious.

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?

The description adds substantial behavioral context beyond the readOnlyHint annotation: it guarantees never returning private or paid content, and explicitly states the tool's public/read-only nature. This reassures the agent about safety boundaries, going well beyond the annotation.

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 zero filler. The first sentence states what it returns, the second states what it never returns, with no redundant information.

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 preview tool with one parameter and no output schema, the description is fully self-contained. It enumerates return content types and exclusions, providing all necessary context for the agent to invoke it safely and appropriately.

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

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

Schema description coverage is 100%, with the parameter fully documented as 'Product id, SKU, or unambiguous slug.' The description adds no additional parameter details, 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?

The description explicitly states 'Return SAFE public previews only' and enumerates specific content types (documentation excerpts, file-name tree, screenshot/demo links, sample snippets). It also clearly lists what it never returns, distinguishing it from siblings like 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 description clearly scopes the tool for safe public previews and emphasizes 'Read-only and public,' implying use for public display needs. The negative list ('Never returns the purchased ZIP, private storage URLs...') acts as a strong exclusion, though it does not explicitly name 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?

Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds critical behavioral context: each call consumes a limited download, links expire in ~15 minutes, and the link is single-purpose. It also states ownership proof requirements, going beyond annotation hints.

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 efficiently written in two long sentences, with the core purpose front-loaded. Each clause adds value: auth requirement, expiration, single-purpose, ownership proof, limited consumption, and non-access to other orders. 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?

Despite no output schema, the description states what is returned (signed link) and its properties. It covers when to use, how auth works, side effects (consumes one download), and limitations. It is complete for the tool's complexity.

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 covers all three parameters with descriptions (100% coverage), but the description adds semantics by explaining that session_id and download_token are alternative ownership credentials, and email is for audit. This clarifies how parameters relate to purpose, which the schema alone does not.

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 a specific verb+resource: returns a short-lived signed download link for a buyer's own completed purchase. It distinguishes from siblings by focusing on post-purchase access rather than order status, product details, or checkout creation.

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 specifies the prerequisite 'buyer who already completed a purchase' and excludes use for accessing other orders. It does not explicitly name a sibling alternative, but the context is clear enough to select this tool for download 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 declare readOnlyHint=true, so the safety profile is known. The description adds meaningful context: public access, concise product cards with stable canonical URLs, and the default filtering behavior (only agent-purchasable items unless include_unsellable=true). This goes beyond annotations without contradicting them.

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, each serving a distinct purpose: scope, return characteristics, and default/exclusion behavior. The description is front-loaded with the main action and contains no redundant words.

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 9 optional parameters and no output schema, the description covers the core use case, return format, and default behavior. It does not explain pagination or filter combination, but the schema provides parameter definitions. The absence of an output schema is partially mitigated by the mention of 'concise product cards'.

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%, and the description adds valuable parameter semantics: it explains the default behavior of returning only purchasable products and clarifies that include_unsellable surfaces flagged, non-buyable items. This complements the schema's per-parameter descriptions.

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 'Search' and the resource 'Datanest catalogue of digital technical products', establishing a specific scope. It distinguishes itself from sibling tools like get_product_details and compare_products by focusing on catalogue discovery.

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: this is the search/discovery entry point for the catalogue, returning product cards. It implies when to use it versus siblings (e.g., details, comparison, checkout) but does not explicitly name alternatives or exclusions.

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