Agoragentic

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

Annotations provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds context by specifying 'stable anonymous' services and 'bounded paid resources,' which hints at reliability and scope, but doesn't detail rate limits or auth needs beyond 'accountless.' 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 two sentences, front-loaded with the core purpose and followed by usage context. Every word contributes value, with no redundancy or fluff, making it 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?

With annotations covering safety and idempotency, and schema fully describing parameters, the description adds useful context like 'stable anonymous' and 'accountless buyer catalog.' However, no output schema exists, and the description doesn't explain return values or error handling, leaving gaps for a browsing tool.

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

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

Schema description coverage is 100%, with clear descriptions for 'limit,' 'include_trust,' and 'include_schemas.' The description doesn't add meaning beyond the schema, such as explaining what 'trust and settlement metadata' entails or the impact of including schemas. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the action ('browse') and resource ('stable anonymous x402 services'), and specifies the domain (x402.agoragentic.com). It distinguishes from siblings by mentioning 'accountless buyer catalog for bounded paid resources,' which suggests a browsing vs. transactional role, though not explicitly naming 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 implies usage context ('accountless buyer catalog for bounded paid resources'), suggesting it's for browsing services without an account. However, it doesn't explicitly state when to use this tool versus alternatives like 'agoragentic_search' or 'agoragentic_categories,' leaving some ambiguity.

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 annotations: it explains the two-phase payment flow (unpaid attempt → payment required → paid retry), which isn't covered by annotations. Annotations provide basic hints (non-readOnly, openWorld, non-idempotent, non-destructive), but the description adds payment-specific behavior. 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 extremely concise (two sentences) and front-loaded with the core purpose. Every sentence earns its place by explaining the payment flow and retry logic without any wasted words or 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?

Given the tool's complexity (payment flow, 4 parameters, no output schema), the description is reasonably complete. It explains the key behavioral pattern (payment retry) but doesn't detail error handling or response formats. With good annotations and schema coverage, it provides adequate context for an agent to use the tool correctly.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal semantic context beyond the schema (e.g., implying 'payment_signature' is for retries), but doesn't provide significant additional meaning. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the specific action ('Call one stable x402 service by slug') and distinguishes it from siblings by focusing on direct service invocation rather than browsing, quoting, or other related operations. It provides a concrete example ('text-summarizer') that helps clarify the resource type.

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 this tool ('first unpaid attempt returns an x402 Payment Required payload') and when to retry ('Retry the same tool call with payment_signature to complete the paid call'). It distinguishes usage from siblings by focusing on paid service calls rather than browsing or quoting alternatives.

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 traits. The description adds valuable context about what data is returned (categories plus capability counts), but does not address pagination, caching, or rate limiting behavior.

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

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

Single sentence with zero waste. Front-loaded with the action verb 'List' and immediately specifies the scope (categories) and return detail (capability counts). 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 simple discovery tool with no parameters and safety annotations provided, the description is nearly complete. It explains the return structure adequately despite lacking an output schema. A mention of this being a prerequisite step to using the 'search' tool would achieve a 5.

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 with 100% schema coverage. Per evaluation guidelines, zero-parameter tools receive a baseline score of 4. The description appropriately does not invent parameters where none exist.

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 provides a specific verb ('List'), clear resource ('listing categories'), and distinguishes from action-oriented siblings (quote, register, search) by identifying this as a metadata/discovery tool. It further clarifies the return value includes capability 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?

While the description clearly indicates this is a discovery tool, it lacks explicit guidance on when to use it versus the 'search' sibling (e.g., 'use this to discover available categories before filtering searches'). Usage is implied by the zero-parameter schema but not stated.

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 read-only, non-destructive, idempotent, and open-world behavior. The description adds value by specifying the source ('from x402.agoragentic.com') and that receipts are 'anonymous,' which are not covered by annotations. It does not contradict annotations and provides useful contextual 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 a single, efficient sentence that front-loads the core action and resource. Every word contributes to clarity without redundancy, making it appropriately sized and well-structured for quick understanding.

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), rich annotations covering safety and behavior, and no output schema, the description is mostly complete. It specifies the source and anonymity, but could slightly improve by hinting at the return format or error cases, though not strictly necessary.

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 'receipt_id' fully documented in the schema. The description does not add any additional meaning beyond the schema, such as format examples or edge cases, so it meets the baseline for high schema coverage without 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 the specific action ('Fetch'), resource ('anonymous x402 edge receipt'), and key identifier ('by receipt ID'), distinguishing it from siblings like search or validation tools. It precisely defines what the tool does without being vague or tautological.

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 when you have a receipt ID from x402.agoragentic.com, but it does not explicitly state when to use this tool versus alternatives (e.g., agoragentic_search or agoragentic_validation_status) or provide exclusions. The context is clear but lacks explicit guidance on 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral details about the verification process (hash recomputation, tamper detection) and anonymity, providing context beyond annotations 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?

Description is two sentences long, front-loaded with the main action, and every word adds value. No unnecessary information or redundancy.

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

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

The tool lacks an output schema, and the description does not explain what the verification result returns (e.g., boolean, status, details). Also, the receipt object parameter has no sub-schema, but the description does not describe its structure, leaving gaps for the agent.

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

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

Schema coverage is 100% and the description essentially repeats the schema descriptions for both parameters, adding no new meaning. Baseline score of 3 is appropriate since the schema already documents parameters 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?

Description explicitly states the verb 'verify' and the resource 'minted interchange receipt', and adds technical details of hash recomputation and signature tamper detection. It distinguishes the tool from siblings like agoragentic_edge_receipt and agoragentic_validation_status by specifying its focus on 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 implies usage when needing to verify a receipt and notes that it works anonymously with receipt_id or receipt JSON, but does not provide explicit guidance on when to use this tool versus its siblings, nor does it state when not to use it.

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 (readOnlyHint, idempotentHint, destructiveHint) are present and consistent. The description adds that task mode requires auth and listing mode is anonymous, and describes different return structures. However, it does not specify behavior when both sets of parameters are provided (likely an error).

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 relatively concise given the number of features. It front-loads the purpose and uses clear separation between the two modes. Slightly verbose in the auth explanation but overall 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?

The description covers both modes, auth requirements, and expected outputs. Lacks information on error handling, rate limits, or default behavior when no parameters are provided. Fairly complete for a tool with 10 parameters and no output schema.

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% (all 10 parameters have descriptions). The description adds significant value by grouping parameters into two modes (task-related vs listing-related) and clarifying which parameters apply to which mode, along with auth implications.

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 creates a router-aware quote and distinguishes two modes: task+constraints (returns ranked providers) and listing-specific (returns price, trust snapshot, next-step guidance). This is a specific verb+resource and differentiates from sibling tools like agoragentic_quote_service and agoragentic_call_service.

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

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

Explicitly states when to use each mode: 'If you pass task + constraints' vs 'If you pass capability_id, listing_id, or slug'. Also provides authentication requirements per mode: listing mode anonymous, task mode requires auth with detailed instructions for both stdio relay and remote HTTP.

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 cover key traits (read-only, idempotent, non-destructive), but the description adds valuable context: it discloses that the tool 'errors if the quoted service exceeds this price' (for max_price_usdc) and specifies return details like 'retry behavior' and 'trust metadata,' which are not captured in annotations. 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 a single, dense sentence that front-loads the core action and efficiently lists return values. Every word contributes to understanding the tool's function without redundancy, 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?

Given the tool's moderate complexity (4 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose, key behavioral aspects, and output details. However, without an output schema, it could benefit from more explicit guidance on response structure or error handling, leaving a minor 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?

Schema description coverage is 100%, providing full parameter documentation. The description does not add meaning beyond the schema (e.g., it doesn't explain slug format or trust metadata details). With high schema coverage, the baseline score of 3 is appropriate, as the description relies on the schema for parameter semantics.

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 ('Quote one stable x402 service by slug') and specifies the resource ('stable x402 service'), distinguishing it from siblings like agoragentic_browse_services (which likely lists services) or agoragentic_call_service (which invokes a service). It provides specific output details (price, retry behavior, etc.) that further clarify its unique purpose.

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

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

The description implies usage context by specifying 'without spending,' suggesting this is a pre-call check. However, it does not explicitly state when to use this tool versus alternatives like agoragentic_quote (which may be a generic version) or agoragentic_call_service (for actual execution). Clear guidance on sibling differentiation is missing.

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 (readOnlyHint=false, openWorldHint=true) indicate a write operation with side effects. The description adds critical behavioral details: automatic key binding, session persistence, and that authentication tools work immediately after registration. 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 front-loaded with the main purpose, then explains authentication nuances and persistence. Every sentence adds value, though it could be slightly more compact without losing 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?

Given no output schema, the description explains the return (API key and access) and covers authentication edge cases for both unauthenticated and already-authenticated sessions. With simple parameters, it is complete for correct agent 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% with descriptions for both parameters (agent_name uniqueness, agent_type enum). The description does not add new parameter meaning beyond what the schema provides, so baseline score 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 states 'Register as a new agent on Agoragentic' with specific verb and resource. It distinguishes from siblings by mentioning returned API key and authenticated surface access, while siblings are about browsing, calling, categories, etc.

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?

Clear context on when to use: registration for new agents with authentication state handling. It explains session binding for unauthenticated sessions and persistence for future sessions, though it doesn't explicitly list exclusions from sibling 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 already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable domain context (supply-side marketplace, public capabilities) and workflow sequencing, but does not disclose additional behavioral traits like rate limits, response format, or pagination behavior beyond the limit parameter.

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 well-structured sentences with zero waste. The first sentence states purpose; the second provides usage context and workflow. Information is front-loaded and appropriately sized for the tool's complexity.

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 4 optional parameters and strong schema coverage, the description adequately covers the tool's purpose. It mentions the key output implication (obtaining IDs for quoting/invoking) despite the absence of an output schema, though it could briefly characterize what a 'listing' contains.

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 has 100% description coverage with clear types and examples. The description does not add semantic clarifications beyond what the schema already provides (e.g., no guidance on query syntax or price denomination), warranting the baseline score for high-coverage schemas.

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

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

The description clearly states the specific action (search) and resource (Agoragentic supply-side listings/public capabilities). It distinguishes from siblings by explicitly mentioning the workflow progression to 'quote or invoke,' which maps to agoragentic_quote and implied invocation tools in the sibling set.

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 ('when you want to browse public capabilities') and outlines the multi-step workflow (browse → quote/invoke). It implicitly signals that this tool is for discovery, not execution, though it could more explicitly state when to skip this step (e.g., 'if you already know the listing ID').

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 and idempotentHint. The description adds the important behavioral trait of not invoking a paid service, which confirms it is non-destructive and cost-free. No contradictions.

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?

Single sentence with no fluff. Every word adds value, front-loading the core action and 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?

For a simple read-only list tool with one optional boolean parameter and good annotations, the description is mostly complete. However, it does not specify the format or fields of the returned data.

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% for the single parameter 'include_inactive', and the description does not add any extra meaning 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 specifies a clear verb ('List') and resource ('Agoragentic execution verifiers, Argent/Themis high-risk posture, lifecycle states, and external verifier readiness') and distinguishes from sibling tools by focusing on validation status without invoking paid services.

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 it is a safe read operation ('without invoking a paid service') but does not explicitly state when to use this tool versus alternatives like inspect_external_supply_candidate or search_external_marketplaces.

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?

While annotations indicate idempotentHint=true and readOnlyHint=false, the description adds crucial behavioral context about the specific stateful handshake (402 challenge response flow) and what happens on invocation (returns challenge until signature supplied). It does not contradict annotations and explains the 'free' nature of the test.

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 consists of two highly efficient sentences. The first establishes purpose and cost model; the second discloses the critical behavioral contract (challenge/response). No words are wasted, and the information is front-loaded effectively.

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 this is a simple test utility with two optional parameters, no output schema, and clear annotations (non-destructive, idempotent), the description adequately covers the testing purpose and protocol behavior. It could be improved by briefly describing the success state or return value, but it is sufficient for tool selection.

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 100% schema description coverage, the schema already fully documents both parameters. The description adds minimal semantic value regarding parameters themselves, though it conceptually references the 'retry' flow matching the payment_signature parameter. Baseline 3 is appropriate when schema coverage is complete.

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 precisely states the tool tests the 'x402 402->sign->retry pipeline' specifically against Agoragentic, distinguishing it from sibling tools (categories, quote, register, search) by focusing on the payment protocol testing domain. It includes the specific verb (test) and clarifies the 'free' scope ('without spending real USDC').

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 appropriate usage context (testing/development via 'without spending real USDC') and explains the two-step invocation pattern ('Returns the PAYMENT-REQUIRED challenge until you retry'). However, it lacks explicit guidance on when to use production alternatives (e.g., agoragentic_quote) instead of this test utility.

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=true, idempotentHint=true, and destructiveHint=false, which align with a safe, non-mutating operation. The description adds that the tool explains a boundary, which is consistent but does not elaborate on output format or potential side effects (e.g., no external calls). With no output schema, the description could be more specific about the return 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 a single, front-loaded sentence that conveys the purpose directly. No extraneous 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 tool with no parameters and no output schema, the description is minimal. It explains what the tool does but not what the output looks like or how to interpret the explanation. Given the simplicity, it is adequate but could benefit from a brief note on the return type (e.g., 'returns a textual explanation').

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

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

There are zero parameters, so the input schema is effectively empty. Schema description coverage is 100% trivially. The baseline for no parameters is 4, and the description does not need to clarify parameter semantics.

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: explaining a specific boundary related to external marketplace search. The verb 'explain' and the specific resource ('no-execution, no-spend, no-settlement, no-trust-mutation boundary') make the intent clear. However, the description is jargon-heavy and might not be immediately understandable to all agents; a slight loss for accessibility.

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 compared to its siblings, such as search_external_marketplaces or list_external_supply_sources. There is no mention of use cases, prerequisites, or alternatives. The model is left to infer the tool's role without 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 mark the tool as read-only and idempotent. The description adds value by specifying 'no-execution handoff preview', clarifying that no action is taken. This supplements the safety profile well.

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?

Description is a single 14-word sentence. No redundant information. Perfectly concise while covering the essential 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?

With one parameter, no output schema, and good annotations, the description sufficiently explains the tool's action. However, it does not describe the output or return format, which could aid agent understanding.

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% with a clear description of the single parameter. The tool description does not add new information beyond what the schema provides, so 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?

Description clearly indicates inspection of an external supply candidate with a no-execution handoff preview. The verb 'inspect' and resource are specific. However, the phrase 'local public-safe' is ambiguous, slightly reducing clarity.

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?

Description implies usage for inspection and preview without execution, but does not explicitly distinguish from sibling tools like 'preview_external_handoff' or 'search_external_marketplaces'. No when-to-use or when-not-to-use guidance 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 indicate read-only, idempotent, non-destructive behavior. Description adds 'local public-safe' and 'normalized snapshots' but lacks details like pagination or result format.

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?

Single sentence with no wasted words. Purpose is front-loaded and direct.

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?

No output schema, so description should hint at response structure. 'Sources and normalized source snapshots' is vague; lacks details like fields, count, or potential errors.

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?

No parameters exist (0 params, 100% schema coverage), so description need not compensate. Baseline 4 applies; description adds no param info but also doesn't need to.

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 uses specific verb 'List' and identifies resource 'external supply sources' with qualifiers 'local public-safe' and 'normalized source snapshots'. This clearly distinguishes from siblings like 'search_external_marketplaces' or 'inspect_external_supply_candidate'.

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?

Implied usage as a listing tool, but no explicit guidance on when to use this versus alternatives like 'search_external_marketplaces'. No conditions or examples 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?

Even with annotations already providing readOnlyHint, idempotentHint, and destructiveHint, the description adds value by stating the specific actions avoided (writing receipt, opening external service, execution/payment). This goes beyond the structured data.

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 efficiently conveys the core purpose and constraints. Every word earns its place with no 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?

Given the simple nature of the tool (preview, no output schema), the description is complete enough. It covers what the tool does and its limitations, though it could optionally mention error behavior or response format.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description does not add additional meaning to the parameters beyond the schema descriptions, which is acceptable. No extra value is provided for parameter semantics.

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 ('external marketplace handoff receipt'). It clearly distinguishes from siblings by explicitly stating what the tool does NOT do (write, open, execute/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?

The description implicitly provides usage context by stating the tool is for previewing without side effects. It does not explicitly name alternative tools or when-not-to-use, but the constraints are 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds context about local and public-safe scope and lists exclusions (e.g., does not call, execute). No contradictions 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 two sentences with the purpose front-loaded and a clear list of exclusions. It is concise but could be slightly more structured for readability.

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?

While the description states the search scope and exclusions, it lacks information about return format or pagination. Given the absence of an output schema, more detail on output 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?

Schema description coverage is 100%, so the schema already documents each parameter. The description does not add new meaning or explain parameter interactions beyond what is in the schema, meeting 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 clearly states the verb 'Search' and the resource 'local public-safe external marketplace supply metadata'. It also explicitly lists actions it does not perform, distinguishing it from siblings like 'agoragentic_call_service' or 'agoragentic_quote'.

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 searching metadata but does not explicitly state when to use this tool over alternatives such as 'inspect_external_supply_candidate' or 'preview_external_handoff'. No when-not-to-use guidance is provided.

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