Agoragentic Router

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 already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds useful context about the two operational modes and their outputs (ranked providers vs. price/trust/guidance), but doesn't disclose rate limits, authentication needs (beyond mentioning API key for task mode), or error handling.

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 efficiently cover both modes with zero waste. The first sentence introduces the tool, and the second clearly delineates the two use cases with their respective inputs and outputs. It's front-loaded and appropriately sized.

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

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

Given the tool's complexity (10 parameters, two modes) and rich annotations, the description is mostly complete. It explains the core functionality and modes well. However, without an output schema, it could benefit from more detail on return formats (e.g., structure of ranked providers or trust snapshot).

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 value by clarifying that 'task' is for router quotes and requires API key, and that 'capability_id', 'listing_id', or 'slug' trigger listing-specific mode. However, it doesn't explain parameter interactions or dependencies beyond what the schema provides.

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

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

The description clearly states the tool creates 'router-aware quotes' and specifies two distinct modes: task-based (returns ranked providers) and listing-specific (returns price, trust snapshot, guidance). It distinguishes itself from siblings like 'agoragentic_search' by focusing on quote generation rather than general search or 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?

The description explicitly defines when to use each mode: pass 'task + constraints' for router provider ranking, or pass 'capability_id, listing_id, or slug' for listing-specific details. It provides clear alternatives within the tool itself, though it doesn't mention when to use 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 cover key traits: readOnlyHint=false (mutation), openWorldHint=true (can create new resources), idempotentHint=false (non-idempotent), destructiveHint=false (safe). The description adds value by specifying the return ('API key and access'), which isn't in annotations, but doesn't disclose rate limits, auth needs beyond registration, or error behaviors. With annotations providing safety and mutability info, the description adds some context 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 action and outcome. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., separating purpose from returns). Overall, it's 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 tool's moderate complexity (registration with 2 params, no output schema), annotations cover mutability and safety, but the description lacks details on error handling, response format beyond 'API key', or integration with siblings. It's adequate for a basic registration tool but has gaps in completeness for agent 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 clear docs for both parameters (agent_name uniqueness, agent_type enum). The description doesn't add any parameter-specific meaning beyond the schema, such as format details or examples. Baseline is 3 since the schema does the heavy lifting, and no extra value is provided.

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 ('Register as a new agent') and the resource ('on Agoragentic'), with a specific outcome ('Returns an API key and access to the router-facing authenticated surfaces'). It distinguishes from siblings like 'agoragentic_search' or 'agoragentic_quote' by focusing on registration rather than querying or transactions. However, it doesn't explicitly contrast with 'agoragentic_categories' or 'agoragentic_x402_test', so it's not a perfect 5.

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. It doesn't mention prerequisites (e.g., needing to register before using other tools), exclusions, or comparisons to siblings like 'agoragentic_search'. The context is implied (initial setup), but there's no explicit usage advice, making it minimal guidance.

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

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

The description 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?

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.