SCVD General Store

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

The description richly discloses behaviors beyond the annotations: payment rides x402 and missing it returns error 402 with requirements in error.data, retries are safe only with an idempotency key, 'a second call is a second charge' unless the 402-suggested key is echoed, and the tool returns an order_id/order_url rather than the deliverable. It also covers refusal behavior for bare or shuttered shelves, explicit guarantees, and non-guarantees. No annotation contradiction 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?

The description is long but well-organized and front-loaded with purpose. It uses bullets for shelf items and clear sections for payment, retries, and guarantees. Minor redundancy exists: the 'returns an order id, not the goods' point is made twice, once near the top and again later, so it is not maximally concise, but the density of essential operational information justifies its length.

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 complex purchase tool with external human fulfillment, the description is remarkably complete: it covers item selection, required fields, pricing, delivery windows, payment mechanism, idempotency behavior, guarantee terms, failure modes, and what the response will contain. The output schema and annotations supply additional structure, but the description alone would be sufficient for an agent to invoke the tool correctly in most scenarios.

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 semantic value beyond the schema: it explains the meaning of each item_id choice, the per-item pricing and SLA, and the conditional need for detail. It also translates the schema's conditional complexity into plain language ('quick_judgment needs detail. Every other item on this shelf takes item_id alone'). This meaningfully helps an agent pick the right parameter values.

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 purpose: 'hire the keeper — a real named human — to do something in the physical or judgment world that an agent cannot do for itself.' It clearly distinguishes this labor-purchase tool from sibling buy_* tools by emphasizing human fulfillment and enumerates the exact item types via item_id. The resource and action are both specific and immediately understandable.

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 usage guidance: choose quick_judgment for a yes/no verdict, the_collab for 'everything else keeper-time can be', and the_drawer for a describe-only oddity. It also clarifies field requirements per item ('quick_judgment needs detail. Every other item on this shelf takes item_id alone'). It does not explicitly name sibling tools as alternatives, but the human-labor context and item breakdown make when-to-use 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?

The description goes far beyond the annotations, disclosing payment requirements via x402, the 402 error flow, idempotency-key behavior, retry charging rules, guarantees, and non-guarantees. It also explains refusal behavior for bare or shuttered shelves. This is rich, honest behavioral context that an agent needs. No contradiction with annotations 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?

The description is long but appropriately so, covering payment, idempotency, item-specific requirements, guarantees, and edge cases. It is front-loaded with purpose, then usage, then operational details. A few phrases are slightly repetitive, but each sentence conveys necessary information for a paid, stateful tool.

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

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

Given the tool's complexity—payment, idempotency, item selection, permanent storage—the description covers all critical aspects an agent needs: what to pass, how payment works, how retries behave, what is guaranteed, and what the result contains. The presence of an output schema reduces the need to describe return values, and the description still mentions key result fields.

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?

Although the schema already covers all parameters (100% coverage), the description adds meaningful plain-language guidance: which item_id to pass, that context_anchor requires summary, and that the result carries deliverable, cert_id, and patron_number. This helps an agent resolve the schema conditionals without parsing allOf branches, adding value 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 opens with a specific verb+resource: 'sign and store a summary of your own state' at a permanent URL for later retrieval. It clearly distinguishes this tool from siblings by framing it as agent memory that survives context resets, restarts, or handoffs, which is distinct from buying human tasks, observations, or signed records.

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 states when to use the tool: 'Use when an agent needs memory that outlives its own context window and does not depend on its operator's database.' It does not explicitly name alternatives or provide when-not-to-use conditions, but the use case is clearly delineated and the payment/retry behavior further guides correct usage.

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 discloses extensive behavioral details beyond annotations: guaranteed and non-guaranteed aspects, payment via x402, 402 error handling, idempotency key behavior, retry charges, refusal conditions, and instant completion. Annotations (readOnlyHint false, openWorldHint true, idempotentHint false) are consistent; description adds rich context without contradiction.

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 but highly structured: it starts with purpose, then item catalog, then required fields, then payment, then guarantees. Each section is front-loaded with key information, and every sentence conveys actionable detail without redundancy. The structure makes it easy to scan and extract what's needed.

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 (10 item types, distinct requirements, payment protocol, idempotency), the description covers all necessary aspects: purpose, usage, item‑specific details, payment, error handling, retries, and guarantees. It also mentions the result format (deliverable, cert_id, patron_number). No gaps are evident for correct selection and invocation.

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

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

Schema coverage is 100%, but the description adds critical parameter semantics: it explains the meaning of each item_id variant, their prices, required extra fields (e.g., tx_hash, url, digest), and the purpose of agent_name. This goes well beyond the schema's generic descriptions, enabling correct parameter selection.

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 clear, specific statement of purpose: 'have a disinterested third party go and look at something, then sign what it saw.' It distinguishes this tool from siblings (e.g., buy_signed_record, buy_memory_anchor) by focusing on third-party observation and signed evidence, not just record creation. The differentiation is explicit.

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 explicit when-to-use guidance: 'Use when an agent needs its own claim, or a counterparty's, corroborated by an outside observer...' and even mentions a use case for committing digests into Bitcoin time. It also clarifies how to choose items, payment flow, and idempotency, giving the agent full context for invocation.

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 sparse (readOnlyHint=false, destructiveHint=false, idempotentHint=false), but the description provides extensive behavioral detail: x402 payment, 402 error handling, idempotency keys for safe retries, per-item behavior (e.g., graffiti wall display separate, confession anonymized), and explicit guarantees vs non-guarantees. This goes far beyond the 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 long but well-organized into sections: purpose, item list, required fields, payment/idempotency, guarantees. Every paragraph adds operational value; some item details repeat, but this is justified given the tool's complexity and the need to avoid forcing agents to parse schema conditionals.

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 involves complex item selection, payment, and idempotency semantics. The description covers all seven items with pricing, required fields, payment flow, 402 error behavior, retry safety, and guarantee boundaries. It also mentions output fields (deliverable, cert_id, patron_number) and refers to the output schema, making it fully complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a plain-language mapping of required fields per item ('graffiti_on_a_train needs tag; coffees_for_closers needs win; the_confession needs confession') and clarifies that all other items take item_id alone, making the schema conditionals easier to resolve without parsing them.

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 'Purpose: buy a signed, dated certificate that permanently records something' and lists specific use cases. It explicitly distinguishes from buy_memory_anchor and mentions buy_simple as an alternative for hello and dibs, making the tool's scope crystal clear.

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 states 'Use when an agent wants durable, independently checkable proof that a thing happened at a time' and explicitly contrasts with buy_memory_anchor for reloadable agent state. It also notes that buy_simple sells the same hello and dibs items, giving the agent a direct alternative.

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

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

The description discloses payment requirements (x402 with error 402 containing terms), idempotency-key behavior for safe retries, the signed and verifiable nature of the response, and the fact that items cannot sell out. These are behavioral traits not present in the annotations (readOnlyHint=false, destructiveHint=false), adding significant operational value.

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 longer than strictly necessary but is well-structured with line breaks separating purpose, item list, and payment details. It front-loads the main purpose and each paragraph addresses a distinct concern. Some phrasing is poetic ('second door to the same goods') but does not waste space.

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 having no output schema, the description covers the response format ('arrives in the response'), verification endpoint, error handling, idempotency retries, and the full list of purchasable items. For a purchase tool with payment interactions, this is complete and actionable without needing additional documentation.

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 100% of parameters, so the baseline is 3. The description adds meaningful pricing and item-specific details for the item_id enum (e.g., 'small_blessing: A Small Blessing, $0.005') and reinforces that no other fields are needed. It does not restate agent_name, but the schema already describes it adequately.

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 clear verb and resource: 'buy one of the few things that need no reading at all — the front counter.' It goes on to list the exact purchasable items and distinguishes this tool from sibling buy_* tools by explaining it is a 'second door to the same goods' with the same item_id and price. This is specific and differentiates from alternatives.

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

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

The description explicitly says 'If unsure which tool to use, use this one.' It also explains when to prefer this over theme-shelf alternatives, and notes that 'there is nothing to poll, nothing to remember, no second request.' This gives the agent clear decision criteria for tool selection.

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

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

The description goes far beyond the annotations, disclosing that payment rides x402, errors return 402 with payment requirements in error.data, idempotency keys make retries safe, and repeated calls without a key cause a second charge. It also explains guarantees and non-guarantees, as well as the 'honest refusal' behavior before payment terms are issued. This is deep transparency with no contradiction to the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false).

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 but well-structured: it opens with 'Purpose,' moves to usage, then item details, then payment and idempotency behavior, and finally guarantees and retry warnings. Every sentence adds essential operational information for a payment-based tool, and the front-loaded structure makes it easy for an agent to quickly grasp the core purpose.

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 payment-involved purchase tool, this description is exceptionally complete. It covers item options, pricing, payment mechanics, error responses, idempotency, retry behavior, and guarantees. Since an output schema exists, the description doesn't need to explain return values, but it still mentions the result carries deliverable, cert_id, and patron_number. Nothing critical 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?

Although schema coverage is 100%, the description enriches the item_id parameter by listing each enum value with its price, delivery speed, and content (e.g., small_blessing: $0.005, instant, from a 45-slip jar). It also explicitly states that 'no item on this shelf needs anything beyond item_id.' This adds meaningful context the schema alone does not provide.

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 starts with a specific verb and resource: 'buy a small signed novelty — a blessing, a fortune, or a lucky totem.' It clearly differentiates from siblings by naming buy_simple as an alternative for the same items and gives concrete use cases. This goes beyond a vague statement and clarifies exactly what the tool sells.

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 states when to use the tool: 'for a live payment smoke test, or when an agent simply wants one.' It also names an alternative (buy_simple) and explains that either tool is correct for two of the items. Payment requirements and error behavior are spelled out, so an agent knows what to expect and how to proceed.

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 read-only, idempotent, non-destructive. The description adds valuable context: it has no cost ('Free'), completes when guide text returns, and is not a purchase/payment endpoint. These details prevent misinterpretation and provide behavioral clarity beyond the structured 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 three sentences, front-loaded with the tool's core purpose, then expanded with cost/completion and a differentiation from buy tools. Every sentence serves a distinct function with no redundancy, making it concise and 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?

Given the tool's simplicity (no parameters), strong annotations, and the presence of an output schema, the description is fully sufficient. It explains what the guide contains, that it's free, and how it differs from transactional tools. No critical information is omitted.

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 tool has zero parameters and the schema is empty, so the baseline is 4. The description doesn't need to elaborate on parameters; its focus on purpose and usage is appropriate. No parameter information is missing.

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 as returning the store's guide text, enumerating its contents (menu, prices, payment info, free shelf, house promises). It explicitly differentiates from siblings: 'NOT a purchase or payment endpoint — to buy, call a buy_* tool', making the tool's purpose unmistakable and distinct.

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 usage context by telling the agent when NOT to use this tool (for purchases) and directing it to buy_* tools with x402 payment. It also notes the tool is free, which helps the agent decide based on cost constraints. This goes well beyond a simple 'use for reading'.

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 only provide generic flags (readOnlyHint, destructiveHint, etc.), while the description adds substantial behavioral detail: cost (free), rate limiting (once per visitor per day), public visibility of count, and a completion condition. This goes well beyond what annotations reveal.

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, each earning its place: the action, the constraints, and the completion condition. No filler or redundancy, and the key action 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?

With only one optional parameter and an existing output schema, the description covers the tool's purpose, cost, usage limits, and completion behavior. This is complete for the tool's low 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?

Schema description coverage is 100% for the single optional parameter agent_name, so the description does not need to add parameter details. The description adds no parameter-specific meaning beyond the schema, yielding the baseline score.

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?

Description clearly states the action 'Ring the store bell' with a specific verb and resource. It adds unique constraints (free, once per day, public count) that distinguish it from the paid buy_* sibling tools.

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

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

The description clearly conveys when to use the tool: it is free and limited to once per visitor per day. It does not explicitly name alternatives or exclusions, but the context of paid siblings and the free/limit clues provide clear usage context.

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 indicate readOnlyHint=false and destructiveHint=false, and the description adds meaningful behavioral details: entries are public, and the tool completes when the result carries your entry and sticker URL. This goes beyond the structural annotations by outlining the success condition and the public nature of the output.

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, each adding distinct information: purpose, cost/benefit, publicity, and completion condition. No wasted words; front-loaded with the action verb. This is exemplary conciseness.

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 an output schema available and simple parameters (strings with max lengths), the description covers the essential non-schema context: cost, public visibility, and result shape. It's sufficiently complete for a low-complexity tool, though it doesn't mention edge cases like repeated signings or identity verification nuances.

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% (all five parameters have detailed descriptions), so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already provides, but it doesn't need to since the schema is comprehensive.

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 'Sign the guestbook' with a clear verb and resource immediately. It distinguishes the tool from the buy_* siblings by noting it is 'Free; every signer gets the visitor sticker', which positions it as a non-purchasing action.

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: it's free, entries are public, and success is defined by the result containing the entry and sticker URL. It doesn't explicitly say 'use this instead of X', but the free/public framing distinguishes it from paid sibling tools, implying the appropriate use case.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable behavioral context: 'Free, unlimited' (rate/cost), completion semantics ('Completes when the result carries valid (true/false) and the artifact record'), and scope limitations (only ids issued by scvd.store). No contradiction with 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 four sentences, front-loaded with the core purpose, and every sentence carries distinct information: scope, cost, completion behavior, exclusions, and an alternative. No redundancy or fluff.

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 moderate complexity, rich annotations, complete schema, and existing output schema, the description fully covers purpose, scope, limitations, and alternative methods. It does not need to explain return values since the output schema exists. Complete for an AI agent to select and invoke 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% (the 'id' parameter is described as 'A cert_, stamp_, or anchor_ id'). The description adds meaningful context by specifying that the id must be one scvd.store itself issued, reinforcing the parameter's provenance beyond the schema's simple format hint.

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: 'Verify anything scvd.store has ever signed — certificates, visit stamps, context anchors — by its id.' It also differentiates from siblings by explicitly excluding other x402 services and artifacts signed by other stores, 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?

The description gives explicit when-not-to-use guidance ('NOT a conformance checker for other x402 services and NOT for artifacts another store signed') and provides an alternative approach ('To verify a signature yourself without calling us, fetch the artifact's signed bytes and public key and check with any ed25519 library'). This goes beyond implicit usage.

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