Agoragentic Agent OS MCP

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context about 'stable', 'anonymous', and 'accountless' services, which hints at no authentication and consistent availability. This goes beyond the 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 concise sentences with the main action verb 'Browse' up front. Every word earns its place, and the description is easy to scan.

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 output schema, no required params, no nested objects), the description is sufficient. It conveys the resource being accessed and the use case, while annotations cover safety. The missing piece is a brief note on response format, but parameters indicate what can be included.

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 descriptions cover 100% of the parameters (limit, include_trust, include_schemas), so the baseline is 3. The description does not add extra meaning beyond the schema, as it only mentions the catalog nature but not how parameters affect results.

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 'Browse stable anonymous x402 services' on a specific site, with a distinct use-case as 'accountless buyer catalog for bounded paid resources.' This distinguishes it from sibling tools like search or call by scope and intent.

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 instruction 'Use this as the accountless buyer catalog' provides explicit context for when to use the tool. However, it does not explicitly mention alternatives or when not to use it, leaving some room for interpretation.

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 the tool is not read-only and not idempotent, but the description goes further by disclosing the exact payment behavior (initial 402 response, retry with signature) and the optional max_price safety bound. This is crucial behavioral context beyond the structured 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?

Two sentences, front-loaded with the primary action, and every clause earns its place. 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?

The description covers the essential payment flow, which is the main complexity of this tool. It does not detail the success response format or explicitly state prerequisites (e.g., needing a valid slug from another tool), but the schema and sibling context make the overall picture 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?

All four parameters are already fully described in the input schema (100% coverage). The description's mention of payment_signature and max_price merely reiterates the schema details without adding substantive new meaning. The baseline of 3 is appropriate when schema carries the load.

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 action: 'Call one stable x402 service by slug.' This distinguishes it from sibling tools like browse_services or quote, which are about searching or quoting rather than executing the actual call. The verb 'call' plus resource 'service' makes the 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 implicitly conveys when to use this tool by explaining the payment flow: the first unpaid attempt returns a Payment Required payload, and a retry with payment_signature completes the call. This gives clear context for the intended usage, though it does not explicitly name alternatives or stated exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is clear. The description adds valuable behavioral context by stating it returns counts per category, which is not inferable from the schema (empty) or annotations. It doesn't cover pagination or sorting, but for a simple list tool, this is adequate.

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 sentence that conveys the full purpose and scope. It is front-loaded with the verb and resource, with zero wasted words or repetition of the tool's name.

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 has no parameters, no output schema, but strong annotations, the description is complete for its scope. It tells the agent exactly what to expect (categories with counts) and is consistent with the read-only, idempotent nature. No additional information is strictly necessary for correct 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?

The tool has zero parameters and schema coverage is 100%, so the description has no parameter burden. Per the rubric, the baseline is 4, and the description adds meaningful output semantics (counts) without needing to explain any inputs.

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 'List all available listing categories and how many capabilities are in each' uses a clear verb ('List'), specifies the resource ('categories'), and uniquely distinguishes it from sibling tools that focus on services, quotes, or receipts. It conveys both the action and the returned information (counts).

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

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

The description implies the tool is for retrieving categories and their capability counts, which is clear enough given the simple nature of the tool. It doesn't explicitly mention when not to use it, but the context from siblings—none of which handle categories—makes the appropriate use case evident. No explicit exclusions are needed for such a straightforward listing 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 already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds that the receipt is 'anonymous' and located at a specific domain, but it does not disclose error handling, return format, or any other behavioral nuances, which would be useful given the absence of an output schema.

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, focused sentence that front-loads the verb and resource, with no unnecessary words or redundancy. It is highly 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 low complexity (one parameter, no nested objects), strong annotations, and clear schema, the description is largely complete. However, it does not mention the return value or failure behavior, which could leave minor ambiguity for the agent when invoking the 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?

The input schema fully describes the sole parameter (receipt_id) with a meaningful explanation ('Stable edge receipt identifier, usually returned in the Payment-Receipt header'), achieving 100% schema coverage. The description's 'by receipt ID' adds no additional semantic value beyond what the schema already provides.

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 specifies the action ('Fetch'), the resource ('anonymous x402 edge receipt'), and the retrieval key ('by receipt ID'), while also indicating the source domain (x402.agoragentic.com). This distinguishes it from sibling tools like agoragentic_interchange_verify_receipt, which likely verify rather than fetch receipts.

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 provided about when to use this tool versus alternative sibling tools (e.g., agoragentic_interchange_verify_receipt or agoragentic_x402_settlement_check). The description only states the operation without exclusions, prerequisites, or contextual triggers.

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 provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context: hash recomputation, signature tamper detection, and anonymous operation, which are not captured by annotations. No 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?

Two concise sentences with no filler. The first sentence states the action and mechanism; the second covers input modes. 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 read-only verification tool with two optional parameters and a clear purpose, the description is complete enough for an agent to select and invoke it correctly. It doesn't describe return values, but no output schema exists and the purpose is unambiguous.

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 reinforces the two parameters and introduces the 'and/or' relationship between them, but it does not add substantial detail beyond the schema's own 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 uses a specific verb and resource: 'verify a minted interchange receipt' with explicit mechanisms (hash recomputation, signature tamper detection). It clearly distinguishes this from siblings like edge_receipt or validation_status by focusing on receipt verification and tamper detection.

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 usage context by stating it works anonymously with a stored receipt_id and/or a presented receipt JSON, implying two invocation modes. It does not explicitly name alternatives or state when not to use, but the context is sufficient for 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?

Beyond annotations (readOnly, idempotent, openWorld, non-destructive), the description discloses important behavioral context: it returns ranked providers or listing price/trust snapshot, listing mode is anonymous, task mode requires auth, and how to provide the API key in different environments. This adds real value 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 compact and front-loaded with the core verb and resource. Each sentence adds distinct information: mode 1, mode 2, auth requirements. No fluff or repetition, making it easy to scan and parse.

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 optional params, two modes, no output schema), the description provides enough context: it explains what each mode returns, how to choose modes, and the authentication nuance. Without an output schema, the description reasonably covers expected return shape via 'ranked providers' and 'listing-specific price, trust snapshot, and next-step guidance.'

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 parameters are individually documented. The description goes further by explaining how groups of parameters select different quote modes (task+constraints vs. capability_id/listing_id/slug), and highlights that task requires an API key. This semantic grouping adds meaning beyond the raw schema, though it doesn't detail every parameter.

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 purpose: create a router-aware quote, with two distinct modes (task-based provider ranking and listing-specific pricing). It provides specific verbs and resources, and the mode descriptions make the behavior concrete. However, it does not explicitly differentiate itself from sibling tools like agoragentic_quote_service, so it misses full sibling distinction.

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-to-use guidance by mapping parameter combinations to modes: task+constraints for ranked providers, or capability_id/listing_id/slug for listing-specific quotes. It also clarifies auth requirements for each mode (anonymous vs. API key). It does not mention alternative tools or exclusions, so it falls short of a 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable context: 'without spending' reinforces the read-only nature, and listing the return fields (price, retry behavior, trust metadata, sample input, exact payable URL) gives insight into what the response contains. No contradiction detected.

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 wasted words. It front-loads the primary action and then lists the key return elements. Every segment earns its place, making it easy to parse quickly.

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 (one required parameter, no output schema), the description is complete: it states the purpose, lists all major return items, and clarifies the non-spending aspect. The parameter descriptions in the schema cover the optional flags and safety bound, so 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?

Schema coverage is 100%, and each parameter has a clear description. The main tool description does not add extra semantic detail about parameters beyond what the schema already provides. It does indirectly reference include_trust and include_schemas via the return list, but not explicitly. This is adequate but not exceptional, warranting 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?

The description clearly states the tool's purpose: 'Quote one stable x402 service by slug.' It specifies the resource (x402 service), the action (quote), and the scope (by slug). It also lists the return contents, distinguishing it from sibling tools like call_service (execution) and browse_services (listing).

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: you need a known slug and want a quote before spending. The phrase 'without spending' signals this is a pre-invocation check. However, it does not explicitly mention alternatives or exclusions, such as using agoragentic_quote for a different quoting scenario, so it stops short of full guidance.

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 well beyond the annotations by disclosing side effects: it returns an API key, binds to the current session if unauthenticated, preserves existing keys, and gives explicit transport-specific persistence instructions. This enriches the annotation's readOnlyHint=false with concrete behavioral details.

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 informative and well-organized, but the third sentence is long and packs multiple instructions (session binding, persistence, transport-specific auth). It is still concise relative to the high information density, with no filler 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 registration tool with no output schema, the description covers everything an agent needs: the return value (API key), side effects (session binding), and persistence for future sessions in both stdio and HTTP scenarios. 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?

Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter-level detail beyond the schema; the parameter semantics are fully carried by the input schema. No bonus or penalty beyond baseline.

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: 'Register as a new agent on Agoragentic.' It explicitly states the tool's purpose and distinct from sibling tools that handle browsing, calling, or searching. No ambiguity.

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 for when to use the tool (initial registration) and detailed post-registration steps (persisting the API key and setting it for future sessions). While it doesn't name alternative tools, the registration role is unique among siblings, and the guidance on session binding clarifies prerequisites and outcomes.

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, idempotentHint=true, and destructiveHint=false. The description reinforces read-only behavior ('browse public capabilities') without adding extra operational details like rate limits or return formats, which is acceptable given high annotation coverage.

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 wasted words. It front-loads the action and immediately follows with usage guidance, making it easy to scan and understand.

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 read-only search tool with full schema coverage and clear annotations, the description is sufficiently complete. It covers purpose, usage, and scope. The lack of output schema is not a critical gap for a simple listing tool, similar to the high-scoring reference example.

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 has 100% parameter description coverage, so all four parameters are already documented. The description doesn't add parameter meaning, and the baseline of 3 is appropriate since the schema does the heavy lifting.

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 with a specific verb ('Search') and resource ('Agoragentic supply-side listings'). It distinguishes itself from sibling tools by noting the purpose is to 'browse public capabilities' before optionally quoting or invoking, setting it apart from call/quote 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?

Explicitly says 'Use this when you want to browse public capabilities, then optionally quote or invoke a specific listing by ID,' providing concrete usage context. It doesn't name sibling tools as alternatives, but the intended use case is clear enough.

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 readOnly, idempotent, and non-destructive. The description adds valuable context: it lists specific content categories and emphasizes 'without invoking a paid service', which is a meaningful behavioral trait 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 a single, well-structured sentence that is front-loaded with the verb and includes all essential details. Every word earns its place without redundancy.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description covers what is listed and the non-cost behavior. It could mention return format or pagination, but the current level is sufficient for the tool's simplicity.

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% because the single boolean parameter has a clear description. The tool description does not add any parameter-specific information, so the schema carries the burden. 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 lists Agoragentic execution verifiers, posture, lifecycle states, and external verifier readiness. The verb 'List' with specific resource categories distinguishes it from sibling tools like 'call_service' or 'search'.

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: use this for a read-only status listing without incurring paid service costs. It doesn't explicitly name alternatives or exclusions, but the context is strong enough to guide appropriate use.

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?

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds meaningful behavioral context: it is free, requires no auth, has no spend, and strictly confirms settlement without checking delivery or counterparty. This distinguishes the tool's behavior and limitations clearly.

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 concise (three sentences) and front-loaded with the core purpose. Every sentence contributes information about scope, constraints, or limitations; there is 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?

The description provides strong context about inputs and limitations, but with no output schema, it does not explicitly describe what the tool returns (e.g., a boolean or structured confirmation). Given the tool's simplicity, this is a minor gap; the overall context is sufficient for most agents to invoke 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?

While schema coverage is 100%, the description adds a cross-parameter constraint: 'an amount must be accompanied by a payTo or payer'. It also clarifies the matching semantics in the schema, such as 'matched as >=', which improves parameter understanding beyond individual field 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 states a specific verb + resource: 'check that a Base-mainnet USDC transfer settled on-chain for a transaction hash', with optional matching criteria. It clearly distinguishes from siblings by scoping to USDC-settled x402 payments on Base and explicitly excluding non-USDC assets and service-delivery verification.

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 when-to-use context: 'Works for any USDC-settled x402 payment on Base — yours or one you received — not just Agoragentic invocations'. It also states what it does not do ('does not verify service delivery, output quality, or counterparty identity'), implying when not to use it, though it does not name a specific alternative 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?

The description adds valuable behavioral context beyond the annotations by explaining the two-step flow: it returns a PAYMENT-REQUIRED challenge until a payment signature is supplied. This complements the annotations (readOnly=false, idempotent=true) and does not contradict 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?

The description is only two sentences, immediately stating the purpose and then describing the return behavior. There is no redundancy or unnecessary detail, making it highly 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?

For a relatively simple test tool with good annotations and schema coverage, the description sufficiently explains the challenge/retry mechanism and the no-cost aspect. The final success response is not explicitly described, but the schema's 'text' parameter indicates an echo behavior, covering the gap.

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 already documents both parameters with descriptions (100% coverage), and the description references the payment_signature's role in the retry step. However, it does not add substantial meaning beyond the schema, 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 clearly identifies the tool as a test for the x402 402->sign->retry pipeline, specifying the verb 'test' and the resource 'Agoragentic'. It also distinguishes itself from sibling tools by noting the 'without spending real USDC' aspect, making it unique among the payment-related 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 provides clear context that this is for testing the pipeline without incurring financial costs, implying it should not be used for real transactions. It does not explicitly name alternatives or exclusions, but the cost-free testing aspect serves as a strong usage guideline.

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 valuable context about what the tool does NOT do (no execution, spend, settlement, trust mutation), which complements the readOnlyHint, idempotentHint, and destructiveHint annotations. It provides a clear safety boundary without contradicting 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 a single, tightly written sentence that immediately conveys the tool's purpose. It avoids unnecessary words and is front-loaded with the action ('Explain') and the key boundary details.

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 zero-parameter explanatory tool with robust annotations, the description fully covers its purpose and behavioral boundaries. No output schema is needed for such a simple tool, and the description is contextually complete given the sibling action tools.

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?

With zero parameters, the schema coverage is trivially 100%. The description does not need to elaborate on parameters, and the baseline for zero-parameter tools is 4, which is appropriate here.

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 explains a specific boundary (no-execution, no-spend, no-settlement, no-trust-mutation) for external marketplace search. It uses a specific verb ('Explain') and resource, distinguishing it from the sibling action tools that perform executions or settlements.

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

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

The description implies the tool is used to clarify the non-action boundaries of external marketplace search but does not explicitly state when to use it versus alternatives like search_external_marketplaces or agoragentic_call_service. No exclusions or alternative references are provided.

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, idempotentHint, and destructiveHint. The description adds 'no-execution' and 'local public-safe', reinforcing and clarifying the safe, read-only nature beyond what the annotations state.

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 sentence that front-loads the verb and resource, with no unnecessary words. It conveys the key constraints and the secondary payoff efficiently.

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 one parameter and no output schema, the description covers the action and the no-execution constraint well. It leaves some ambiguity about the exact return format and how the preview differs from the sibling 'preview_external_handoff', but the simplicity makes it mostly 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 provides 100% coverage for the single parameter, including its source. The description does not add extra parameter details, which is acceptable given the schema's completeness; 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 clearly states the action 'Inspect' on 'one local public-safe external supply candidate' and mentions the secondary 'no-execution handoff preview'. This distinguishes it from siblings like 'preview_external_handoff' by combining inspection with a safe preview.

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 for safe, local inspection without execution, but does not explicitly mention when to use it over alternatives like 'search_external_marketplaces' or 'preview_external_handoff'. No exclusions or alternative recommendations are provided.

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 the tool read-only, idempotent, and non-destructive. The description adds 'public-safe' and 'normalized source snapshots,' which hint at output characteristics but do not explain these terms or disclose other behaviors like pagination or filtering. With annotations covering safety, the extra context is moderate.

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, front-loaded sentence that efficiently communicates the tool's core function. Every word adds value without redundancy.

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

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

For a parameterless list tool with good annotations, the description is adequate but leaves gaps: it does not clarify the meaning of 'public-safe' or 'normalized snapshots,' nor does it relate this tool to its siblings. There is no output schema, so a bit more detail on return value structure would improve completeness.

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 takes zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 for parameterless tools applies; no additional description is required.

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 list operation on external supply sources with a specific scope ('local public-safe') and includes output characteristics ('normalized source snapshots'). It is specific enough to differentiate from siblings like search_external_marketplaces, though it does not explicitly name 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?

No guidance is provided on when to use this tool versus alternatives such as search_external_marketplaces or inspect_external_supply_candidate. The description simply states what it does without contextual cues for 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context about the exact side effects that are avoided (writing a receipt, opening external service, execution/payment), which enriches behavioral understanding beyond the annotations. It does not contradict 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?

A single, front-loaded sentence that conveys purpose and key constraints without any filler. Every word earns its place, making it highly efficient and easy to parse.

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 core functionality and safety profile, which is sufficient for a preview tool with strong annotations. However, since there is no output schema, it would be helpful to clarify what the preview returns (e.g., redacted receipt content). Also, the combination of parameters (all optional) is not clarified, leaving some ambiguity about invocation requirements.

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 describes all three parameters with 100% coverage, so the baseline of 3 is appropriate. The description does not add extra meaning to the parameters; it only broadly refers to the handoff receipt. No parameter-specific details are provided in the description.

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 ('preview') and resource ('redacted external marketplace handoff receipt'), and clearly distinguishes from siblings by explicitly stating what it does not do (writing a receipt, opening an external service, performing execution/payment). This goes beyond a generic statement and provides clear scope.

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 context by listing side effects it avoids, which helps the agent understand when to use this preview tool versus alternatives. However, it does not explicitly name a sibling alternative or provide a direct 'use this instead of X' comparison, so it falls 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?

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description goes further by listing specific actions it does not perform, which adds valuable behavioral context about its safe, non-operational scope. This goes beyond what annotations state.

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 the purpose front-loaded in the first sentence and the negative list in the second. It is concise, well-structured, and every word contributes to clarifying scope.

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 should explain what the response looks like or how results can be used, but it does not. It also fails to reference related tools like inspect_external_supply_candidate for follow-up actions, leaving the agent without sufficient context for a tool with 9 parameters.

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

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

All 9 parameters are fully described in the input schema (100% coverage), so the description does not need to add parameter-level detail. It adds no extra semantic meaning for the parameters, but the schema already carries the load 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 clearly identifies the action ('Search'), the resource ('local public-safe external marketplace supply metadata'), and includes a negative list that distinguishes it from sibling tools that call or execute services. This makes the tool's purpose explicit and unambiguous.

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

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

The negative list ('Does not call, execute, submit, spend, settle, rank, trust, verify, ready, publish, or expose raw payloads') implies this is for read-only discovery, but there is no explicit statement of when to use it versus alternatives like list_external_supply_sources or inspect_external_supply_candidate. Usage is inferred rather than directly stated.

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