Agoragentic Agent OS MCP

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

Annotations already cover key behavioral traits (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true), so the description doesn't need to repeat these. It adds value by specifying the tool is for 'stable anonymous' services and 'accountless buyer catalog,' providing useful context beyond annotations. No contradictions are present.

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 and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and usage context. Every sentence adds value without redundancy, 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 complexity (browsing services with parameters), annotations provide rich behavioral context (read-only, non-destructive, etc.), and schema coverage is complete. The description adds necessary context about the tool's role as a catalog for accountless buyers. A 5 would require more detail on output or edge cases, but it's largely complete for this setup.

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 all parameters well-documented in the input schema (limit, include_trust, include_schemas). The description doesn't add any parameter-specific information beyond the schema, so it meets the baseline of 3 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 action ('browse') and resource ('stable anonymous x402 services on x402.agoragentic.com'), making the purpose understandable. It distinguishes from siblings by specifying it's for 'accountless buyer catalog for bounded paid resources,' though it doesn't explicitly name alternatives. A 5 would require naming specific sibling tools for differentiation.

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 on when to use this tool: as 'the accountless buyer catalog for bounded paid resources,' implying it's for browsing services without an account. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for informed usage.

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

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

Annotations provide readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: it discloses the two-step payment flow (first attempt returns Payment Required, retry with signature completes), which is critical for correct usage. It doesn't contradict annotations, but could mention more about error handling or rate limits.

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, followed by essential usage details. Every sentence earns its place by explaining the payment workflow concisely. No wasted words 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?

Given the complexity (payment flow, 4 parameters), annotations cover safety and idempotency, and schema coverage is 100%, the description is mostly complete. It explains the critical payment behavior. However, without an output schema, it doesn't describe return values (e.g., what 'completes' means), leaving a minor gap. Sibling context is adequate.

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 all parameters (slug, payload, max_price_usdc, payment_signature). The description adds some context by mentioning payment_signature is used 'on the paid retry', but doesn't provide additional meaning beyond what the schema states (e.g., format details or examples). Baseline 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 specific action ('Call one stable x402 service by slug') and resource ('x402 service'), distinguishing it from siblings like agoragentic_browse_services (which lists services) or agoragentic_quote_service (which quotes prices). It explicitly mentions the payment flow, which is unique among the sibling tools.

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

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

The description provides explicit guidance on when to use this tool: for calling a service by slug, with a two-step process (first unpaid attempt, then retry with payment_signature). It implicitly distinguishes from alternatives like agoragentic_quote_service (for quoting) or agoragentic_browse_services (for browsing), though it doesn't name them directly. The payment workflow is clearly outlined.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and behavior. The description adds minimal context by implying it returns counts of capabilities per category, but does not disclose further traits like rate limits or auth needs, adding some value but not rich 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 a single, efficient sentence that front-loads the key action and resource. It has zero waste, clearly stating the tool's function without unnecessary elaboration, making it appropriately sized and well-structured.

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

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

Given the tool's simplicity (0 parameters, no output schema) and rich annotations covering key behavioral aspects, the description is mostly complete. It could improve by specifying return format or usage context, but it adequately supports the agent for a read-only listing operation.

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 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description adds no parameter information, which is acceptable as there are none, so it meets the baseline for this case without needing to compensate.

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 'List' and the resource 'all available listing categories', specifying what the tool does. It distinguishes from siblings by focusing on categories rather than quotes, registration, search, or testing, making the purpose specific and differentiated.

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 no guidance on when to use this tool versus alternatives like 'agoragentic_search' or other siblings. It lacks explicit context, exclusions, or recommendations, leaving usage unclear beyond the basic purpose.

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 provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds context by specifying 'anonymous' (implying no user authentication needed) and 'edge receipt' (hinting at a specific type of receipt), which are not covered by annotations. No contradictions with annotations exist.

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 key information ('Fetch one anonymous x402 edge receipt') and includes essential details like the source ('from x402.agoragentic.com'). There is no wasted verbiage, 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 low complexity (1 parameter, no output schema), the description is mostly complete. It covers the purpose and source, and annotations handle behavioral traits. However, it lacks details on output format or error handling, which could be useful for an agent invoking the tool, though not strictly required.

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% description coverage, with the 'receipt_id' parameter fully documented. The description does not add any extra meaning beyond the schema, such as format examples or edge cases. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but 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?

The description clearly states the specific action ('Fetch'), the resource ('one anonymous x402 edge receipt'), and the method ('by receipt ID from x402.agoragentic.com'). It distinguishes this tool from siblings like 'agoragentic_search' or 'agoragentic_validation_status' by focusing on retrieving a single receipt via ID rather than searching or checking status.

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

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

The description implies usage when you have a receipt ID to fetch a specific receipt, but it does not explicitly state when to use this tool versus alternatives like 'agoragentic_search' (which might handle broader queries) or 'agoragentic_validation_status' (which could check receipt validity). No exclusions or prerequisites are mentioned, leaving some ambiguity in 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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing the verification process (hash recomputation, signature tamper detection) and noting anonymous operation, which goes beyond what annotations convey.

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 with two sentences. The first sentence covers purpose and method; the second adds usage context. No unnecessary 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?

While the description explains input parameters and behavior, it omits what the tool returns (e.g., verification result). Since there is no output schema, the description should cover the output format or indicator for 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 coverage is 100% and already describes both parameters (receipt and receipt_id). The description merely restates them ('stored receipt_id and/or presented receipt JSON') without adding new semantic details, so baseline score 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 tool verifies a minted interchange receipt using hash recomputation and signature tamper detection. It specifies the action (verify) and the resource (interchange receipt) with technical details, distinguishing it from siblings like agoragentic_edge_receipt.

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 indicates the tool works anonymously with either a stored receipt_id or a presented receipt JSON, providing clear usage context. However, it does not explicitly state when not to use it or offer alternatives among siblings.

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 (readOnlyHint, idempotentHint), the description discloses auth mechanisms for task mode, explains the return structure for both modes, and notes that listing quotes work anonymously. This provides rich behavioral context that annotations alone do not cover.

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 at roughly 5 sentences, front-loading the purpose and then detailing modes and auth. Every sentence adds value 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 complexity (10 parameters, two modes, no output schema), the description covers return types, auth requirements, and parameter grouping. It is sufficiently complete for an agent to understand and 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?

All 10 parameters are fully described in the schema (100% coverage), and the description adds semantic grouping by mode (task vs. listing). It clarifies that 'slug' is an alternative to 'listing_id', adding value beyond schema descriptions.

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

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

The description clearly states the tool creates a router-aware quote and explicitly defines two distinct modes: task quote and listing quote. It explains what each mode returns (ranked providers vs. listing-specific price/trust/guidance), making the purpose highly specific and well-distinguished from the tool itself.

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 excellent within-tool usage guidance, detailing when to use each mode (task vs. listing) and the auth requirements (anonymous for listing, API key for task). However, it does not differentiate from the sibling tool 'agoragentic_quote_service', which could cause confusion about which to 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?

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable context beyond this: it specifies retry behavior, trust metadata, sample input, and that it returns a payable URL without spending, which are not covered by annotations. No contradictions exist.

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 efficiently conveys the tool's purpose, key behaviors, and output details without unnecessary words. It is front-loaded with the core action and includes all essential information concisely.

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 annotations cover safety and idempotency, and the description adds behavioral context like retry and trust metadata, it is mostly complete. However, there is no output schema, and the description doesn't detail the exact structure of returned data (e.g., format of price or sample input), leaving a minor gap for a tool with 4 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?

Schema description coverage is 100%, so the schema fully documents all parameters (slug, include_trust, max_price_usdc, include_schemas). The description does not add any parameter-specific details beyond what's in the schema, such as explaining slug formats or price units, but the high coverage justifies the baseline score of 3.

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 ('Quote') and resource ('one stable x402 service by slug'), specifying it returns price, retry behavior, trust metadata, sample input, and payable URL without spending. It distinguishes from siblings like agoragentic_call_service (which likely executes the service) and agoragentic_browse_services (which lists 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 usage for obtaining service details before execution, with context like 'without spending' suggesting it's a pre-call check. However, it doesn't explicitly state when to use this versus alternatives like agoragentic_quote (which might be a similar tool) or agoragentic_search, 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?

Beyond annotations, description discloses key behavioral traits: key binding to session, persistence requirements, and output (API key). 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?

Well-structured single paragraph, front-loaded with primary action. Every sentence adds value, though could be slightly more organized. Very concise.

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, description provides sufficient context: registration action, auth binding, persistence advice. Somewhat lacking explicit return format, but otherwise complete for a registration 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 coverage is 100%, so baseline 3. Description adds minimal new meaning beyond schema: mentions uniqueness requirement for agent_name, but agent_type remains as in schema. Adequate but not exceptional.

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

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

Description clearly states the tool registers a new agent, returns an API key, and provides authenticated access. It distinguishes itself from sibling tools like browsing or calling services by focusing on registration.

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 guidance on when to use (registration flow) and authentication behavior: binding new key to unauthenticated session, keeping existing key for authenticated sessions, and persisting the key for future sessions with platform-specific instructions.

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 beyond annotations by specifying that it searches 'public capabilities' and that results can be used for 'quote or invoke a specific listing by ID', which clarifies the tool's role in a workflow. Annotations already cover safety and behavior (readOnlyHint: true, destructiveHint: false, etc.), so the bar is lower, but the description enhances understanding without contradicting 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 appropriately sized and front-loaded, with two sentences that efficiently convey the tool's purpose and usage guidelines without any wasted words. Every sentence earns its place by providing essential information, making it easy to understand 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 moderate complexity (4 parameters, no output schema), the description is mostly complete, covering purpose and usage. However, it lacks details on behavioral aspects like pagination or result format, which could be useful since there's no output schema. Annotations provide safety context, but the description could add more on operational behavior.

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 description does not add specific meaning beyond what the input schema provides, as schema description coverage is 100%, clearly documenting all parameters (limit, query, category, max_price). The baseline is 3 since the schema does the heavy lifting, and the description does not compensate with additional details like format examples or constraints beyond the schema.

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

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

The description clearly states the specific action ('Search Agoragentic supply-side listings directly') and resource ('public capabilities'), distinguishing it from siblings by mentioning the purpose to 'browse public capabilities' and the optional follow-up actions ('quote or invoke a specific listing by ID'), which differentiates it from tools like agoragentic_categories or agoragentic_register.

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 ('Use this when you want to browse public capabilities') and implies alternatives by mentioning optional follow-up actions ('then optionally quote or invoke a specific listing by ID'), which suggests agoragentic_quote as an alternative for quoting and other tools for invocation, providing clear context without 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, indicating safe, non-destructive behavior. The description reinforces this by stating the tool does not invoke a paid service and lists read-like content (verifiers, posture, states). No contradiction exists.

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

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

The description is a single sentence that immediately states the tool's purpose and key differentiator (no cost). Every word is essential, and it is front-loaded with the most critical 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 has only one optional parameter, no output schema, and rich annotations, the description sufficiently covers what the tool lists and its safe, cost-free nature. No gaps are evident for a simple status-listing 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 coverage is 100% for the single boolean parameter 'include_inactive', which is fully described in the schema. The description does not add additional meaning beyond the schema, so a 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 explicitly states the tool lists 'Agoragentic execution verifiers, Argent/Themis high-risk posture, lifecycle states, and optional external verifier readiness' without invoking a paid service. This specific verb+resource combination clearly distinguishes it from sibling tools like agoragentic_call_service (which incurs cost) and agoragentic_browse_services (which lists 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 notes 'without invoking a paid service,' implying this tool is for safe, free queries, contrasting with tools that have costs. It does not explicitly list when-not-to-use or provide direct alternatives, but the context is clear enough for an agent to select this tool for non-paid status checks.

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 that the tool returns a PAYMENT-REQUIRED challenge until retried with a payment signature, revealing a retry mechanism and payment simulation behavior. Annotations cover safety (readOnlyHint=false, destructiveHint=false) and idempotency, but the description enriches this with specific pipeline flow 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 concise and front-loaded, with two sentences that efficiently convey the tool's purpose and behavior. Every sentence earns its place by explaining the test scenario and retry mechanism 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?

Given the tool's complexity (simulating a payment pipeline with retries) and lack of output schema, the description is fairly complete. It explains the core behavior and expected challenges. However, it could be more complete by detailing the return format or success conditions beyond the PAYMENT-REQUIRED challenge.

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 fully documents both parameters. The description does not add meaning beyond the schema, such as explaining the relationship between text and payment_signature in the pipeline context. Baseline 3 is appropriate as the schema handles parameter documentation 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 states the tool's purpose: testing a specific pipeline (x402 402->sign->retry) against Agoragentic without spending real USDC. It specifies the verb 'test' and resource 'pipeline', and distinguishes from siblings by focusing on a test scenario rather than categories, quotes, registration, or search operations.

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 for when to use this tool: for testing the pipeline without real payment. It implies usage for development or verification purposes. However, it does not explicitly state when not to use it or name alternatives among siblings, though the free testing focus naturally suggests alternatives for paid operations.

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 the specific boundary context but no additional behavioral traits.

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, concise, no wasted words.

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

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

For an explanatory tool with no parameters and annotations covering safety, the description is complete enough; minor vagueness on the boundary terminology.

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, so baseline 4 applies. Description adds no param info but is unnecessary.

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 verb 'explain' and the resource 'no-execution, no-spend, no-settlement, no-trust-mutation boundary for external marketplace search', distinguishing it from siblings like search or 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?

No explicit guidance on when to use this tool versus alternatives; it's implied 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 (readOnlyHint=true) and non-destructive behavior. The description adds the 'no-execution handoff preview' phrase, which reinforces the read-only nature, but does not disclose additional behavioral details like response format or side effects. 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 a single sentence and is concise. It is front-loaded with the primary action. However, combining two actions in one sentence slightly reduces clarity. Overall, it is efficient without being overly verbose.

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

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

The tool lacks an output schema, yet the description does not explain what the agent can expect as a return value. The phrase 'inspect ... and a no-execution handoff preview' is vague about the output format. Given the low complexity (1 param, no nested objects), the description should at least hint at the response structure.

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

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

The input schema already provides a clear description for the only parameter, achieving 100% schema description coverage. The tool description adds no additional meaning or context beyond what the schema already provides, so a 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 clearly states the verb 'inspect' and the resource 'external supply candidate', but it adds an extra element 'no-execution handoff preview' which could cause confusion with the sibling tool 'preview_external_handoff'. The main purpose is discernible but not perfectly distinct.

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

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

The description provides no guidance on when to use this tool versus alternative sibling tools such as 'preview_external_handoff' or 'search_external_marketplaces'. There are no explicit when-to-use or when-not-to-use instructions.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no further behavioral details such as data freshness, pagination, or permission requirements. It merely restates the resource nature.

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 of 13 words, efficiently conveying the purpose. It is front-loaded and contains 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?

Given no parameters and no output schema, the description adequately explains what the tool lists. However, it could be more complete by clarifying the scope (e.g., 'all local supply sources') or providing examples of source snapshots.

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, and schema coverage is 100% (trivially). The description does not need to explain parameters. The baseline for zero-parameter tools is 4, and the description minimally adds context by naming the resource to be listed.

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 'list' and the resource 'local public-safe external supply sources and normalized source snapshots', leaving no ambiguity about the tool's function. It distinguishes itself from sibling tools like 'search_external_marketplaces' which imply searching rather than 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 provides no guidance on when to use this tool versus alternatives or mentions any prerequisites or context. It lacks any 'when to use' or 'when not to use' information, which is critical for an agent to decide between 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, destructiveHint. Description adds crucial behavioral context: no writing, no external service opening, no payment, which goes beyond annotations and clarifies safety.

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, front-loaded with verb and resource. Every part 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?

Given 3 optional params, rich annotations, and no output schema, the description fully equips an agent to invoke correctly without missing critical details.

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 has 100% coverage with clear descriptions for all 3 optional parameters. Description does not add further meaning beyond schema, earning baseline 3.

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 explicitly states what it does not do (no writing, external service opening, or payment), distinguishing it from sibling tools like 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?

Implicitly indicates use for safe preview without side effects, but lacks explicit when-not-to-use or alternative references. Siblings provide context but not mentioned.

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 it as read-only, idempotent, and non-destructive. The description adds behavioral context by stating it is 'local public-safe' and enumerating excluded actions, enhancing transparency without contradicting 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?

Two sentences: one for purpose, one for exclusions. Every word adds value—no redundancy or fluff.

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

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

For a read-only search tool with 9 parameters, the description sufficiently conveys its scope and limitations. Lack of output schema means return format is not described, but this is acceptable given the simple search nature.

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. The tool description does not add extra semantic detail beyond the schema, but it contextualizes the overall search purpose.

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 searches 'external marketplace supply metadata', using a specific verb and resource. The explicit list of actions it does NOT perform ('does not call, execute, submit, spend, settle...') effectively distinguishes it from sibling tools that perform those actions.

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 by listing what the tool does not do, guiding the agent away from using it for execution tasks. However, it does not explicitly compare to sibling tools like 'agoragentic_search' or provide when-not-to-use scenarios.

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