Agent402.Tools: pay-per-call web tools

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not required to repeat those. The description adds valuable context beyond them: per-call cost ($0.030), the fact that the hosted connector holds no wallet, payment methods, audio limits, and the return shape. 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 densely packed but every sentence earns its place. It leads with the most decision-relevant constraint (wallet-required and cost), then the core action, then technical limits, then return format, then payment alternatives. No filler 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?

For a tool that involves payment, size limits, and an external API, the description covers all essential aspects: cost, payment flow, constraints, return format, and alternative clients. An agent has everything needed to call it correctly without opening additional docs.

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% (both parameters described), but the description adds critical operational context: file size and duration limits, accepted formats, and the exact return structure ({ model, provider, text, language, duration }). This goes well beyond the schema and helps the agent decide parameters correctly.

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

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

The description states a specific action ('Transcribe audio to text'), the resource ('audio file'), and the underlying implementation ('OpenAI gpt-4o-mini-transcribe'). It clearly distinguishes the tool from siblings like web.search or catalog.find by naming the unique domain (audio transcription).

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 explains when to use this tool (provide a URL to an audio file), the constraints (max 5 minutes, 25 MB), and how to pay ('No API key needed; pay per call via x402'). It also names alternative invocation paths ('run npx agent402-mcp...' or any x402 client), giving clear routing 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?

With annotations already covering readOnly, openWorld, idempotent, and non-destructive hints, the description adds valuable behavioral context: the per-call cost ($0.02), that the page is untrusted content to analyze not follow, the exact return fields (url, title, wordCount, markdown, rendered, untrustedContent), and payment/authentication requirements (MPP, npx agent402-mcp, AGENT_KEY, AGENT402_CREDITS_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?

The description is relatively long but every sentence earns its place: the core functionality is front-loaded, followed by usage context, untrusted warning, return shape, and payment instructions. It is well-structured, scannable, and free of redundant filler.

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

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

Given the complexity (costs, authentication, untrusted content, payment methods) and existing output schema, the description covers all necessary operational details. An agent has everything needed to correctly invoke the tool and handle its result safely.

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 single parameter (url) is fully described in the schema (coverage 100%), and the description does not add additional semantic detail beyond what the schema already states. Per the rubric, baseline 3 applies when schema coverage is high and the description doesn't compensate further.

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

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

The description clearly specifies the action (render a page in a headless Chromium browser with JavaScript execution) and the outcome (extract main content as clean markdown). It distinguishes itself from plain fetching and screenshot, and the siblings (web.*) are not confused because it explicitly says when to use this over 'cheaper extract' and 'screenshot' for pixel evidence.

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

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

It explicitly states when to use (SPAs and JS-heavy sites where plain fetching returns an empty shell), when not to use (static pages – try the cheaper extract first), and provides an alternative for a different need (screenshot for pixel evidence). This is clear, actionable guidance that prevents misuse.

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. The description adds crucial behavioral details beyond that: the 165 pure-CPU tools execute free with rate-limiting and proof-of-work; wallet-only tools return a paid-access setup guide; the connector holds no wallet; and unknown slugs produce an error. These are operationally important and not inferable from the schema or 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 primary action, then delivers discovery guidance, free vs wallet-only behavior, and error handling – all in compact, dense sentences. No filler; each sentence contributes essential information. Long enough to be complete, short enough to read 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 role as a generic executor, the description covers the key aspects: how to identify slugs, parameter matching, fee structure (free vs wallet-only), rate limits, wallet absence, and error behavior. The output schema exists to explain return values, so that omission is acceptable. The description is complete for its complexity.

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

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

Schema coverage is 100% (both slug and params have descriptions). The description adds value by explaining how to obtain valid slugs (via catalog.find/search) and reinforcing that params must match the target tool's inputSchema. This context goes beyond the schema's simple field labels, though the baseline is already high due to full 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 verb and resource: 'Run an Agent402 tool by slug' – it performs execution based on a slug. It differentiates from sibling discovery tools by saying 'discover slugs with catalog.find or catalog.search', making it obvious this tool runs tools rather than finds them. The purpose is unambiguous and distinguishes itself from the catalog search/find family.

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?

Explicit guidance is given: discover slugs with catalog.find or catalog.search, then run with this tool. It also explains when NOT to use it – for wallet-only tools it returns a setup guide instead of executing, and unknown slugs point back to catalog.search. This is clear when-to-use vs alternatives, with exclusions and error handling.

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 and non-destructive, so the description adds value by detailing the output structure ({ task, results }), the 'top pick first' ordering, and the call-ready artifacts (slug, price, schema, example). It does not contradict annotations.

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

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

Three sentences each add distinct value: purpose, contrast with sibling, and next-step guidance. No filler, information is front-loaded with 'DECIDE, don't browse'.

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 output schema exists, the description adequately covers what the tool returns, when to use it, and the follow-up action. Contextual signals (siblings, annotations, schema) together make the tool fully understandable.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema, only referring to 'plain-language task' which the schema already conveys with examples.

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 it resolves a plain-language task to the single best-matching tool, with a specific verb + resource. It explicitly contrasts with catalog.search, so sibling differentiation is strong.

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: 'Prefer this for anything outside the flagship list' and names the alternative catalog.search for exploring candidates. Also instructs to use catalog.call after selection, making the call flow 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 readOnly, idempotent, non-destructive behavior. The description adds meaningful context about exact catalog size, free vs payable tools, MPP credential handling, an LLM gateway, and the return shape, going well beyond the structured annotations without contradicting them.

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

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

Dense and information-rich, with the core purpose and usage front-loaded. Some extra topics (LLM gateway, exact payment details) go beyond the bare minimum but each adds practical context for an agent deciding whether and how to call this tool.

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

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

Covers the tool's purpose, relationship to siblings, payment/auth options, response format, and next step (catalog.call). With an output schema present and annotations covering safety, nothing critical is missing for an agent to use it correctly.

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

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

Schema covers both parameters fully (query with examples, limit with default), so baseline is 3. Description adds the 'long-tail slug' use case and return shape but does not add new parameter-level semantics beyond what 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?

Description explicitly states this is a keyword search over the long catalog, distinct from the flagship set, and contrasts itself with catalog.find. The verb 'BROWSE' plus the resource (catalog) and the search nature make the tool's role unmistakable.

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

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

Provides clear when-to-use guidance: start with flagships, use this for long-tail slugs, and use catalog.find when a single decided pick is needed. Also explains how to invoke returned workflows via catalog.call, making the usage path complete.

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

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

The description discloses key behavioral traits beyond the annotations: it only records demand, never returns a tool, never runs anything, is free, and feeds into a public aggregate. These details are important for an agent deciding whether to call it and what to expect back. No contradiction with annotations; readOnlyHint=false is consistent with recording a request.

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 well-structured and scannable, front-loading purpose and usage. It is slightly padded with redundant details like catalog size 579 alongside '500+ tools', but the information is otherwise important and not excessive.

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 tool with only two parameters, the description covers everything an agent needs: when to use it, what it accomplishes, what it does not do, cost implications, and the relationship to the public API. The output schema and input schema handle the remaining 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?

The input schema already documents both parameters thoroughly (100% coverage), including examples for 'need' and a clear explanation for 'context'. The description does not add parameter-level detail, but it doesn't need to because the schema carries that burden. 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 specific action: submitting a request for a capability not covered by existing tools. It distinguishes itself from siblings by explicitly positioning this tool as the fallback after catalog.search or catalog.find fails, and clarifies that it 'records demand only' rather than returning or executing a tool.

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

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

The description gives explicit usage guidance: use this tool after catalog.search or catalog.find return nothing, instead of giving up. It also tells the agent what the tool does not do ('never returns a tool or runs anything'), which prevents misusing it as a lookup or execution tool.

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

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

Annotations already mark this read-only, idempotent, and non-destructive. The description meaningfully adds behavioral context beyond annotations: per-call cost, wallet requirement, keyless Yahoo Finance backend, no rate limits in practice, and payment/auth options. 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 long but information-dense, covering scope, alternatives, backend, symbol formats, return shape, and payment instructions with no filler. It is front-loaded with the core purpose and usage, while later sentences provide operational context. Slight bloat from multiple payment delivery options slightly prevents a 5.

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 single parameter, rich annotations, output schema, and explicit alternative routing, the description is complete for safe and correct invocation. It even covers authentication/payment requirements, which is critical for a paid connector. An agent has everything needed to decide whether and how to call it.

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%, and the single required parameter is fully documented in the schema with the same symbol format examples repeated in the description. The description adds no genuinely new parameter semantics beyond what the schema already states, so the 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 opens with a specific verb and resource: live stock/index/FX/crypto quote, and enumerates exact returned fields. It also distinguishes itself from named sibling tools (stock-history, premarket-quote, crypto-price), making its scope unambiguous.

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

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

The description explicitly tells the agent when to use this tool versus alternatives: 'single-symbol NOW read' for quotes, stock-history for OHLC time series, premarket-quote for pre/post-market, and crypto-price for richer crypto fields. This is the gold standard for usage routing.

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

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

Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds substantial context beyond annotations: wallet-required, per-call cost, namespace access rules, the returned shape ({ keys, owner, persistent }), and payment/funding options. It does not contradict annotations. High value added, though the payment detail is verbose.

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 paragraph that front-loads the most critical constraint (wallet-required, cost) before functional details. Every sentence contributes (usage, access, return shape, funding). It is slightly long for a read tool, but the density justifies the length since the financial/access context is essential.

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 is complete for an exact-key read tool. It covers the operation, retrieval modes, naming conflicts, access control, return fields (keys, owner, persistent), and payment options. Since an output schema exists, return-value documentation is already handled; the description adds the behavioral and environmental context an agent needs to call it correctly.

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

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

Schema coverage is 100%, so both parameters are documented in the schema. The description meaningfully augments this: it clarifies the key param's omission behavior (omit to list keys), the owner param's grant requirement, and the default-owner semantics. This goes beyond the schema's one-line descriptions.

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

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

The description states a specific verb ('Read from a wallet-scoped namespace'), a concrete resource, and precise scope: exact-key retrieval versus listing, with optional owner. It also names the sibling it is not ('memory-recall' for similarity retrieval), fully distinguishing it from memory.write and memory-recall without ambiguity.

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

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

Explicitly tells the agent when to use this tool (exact-key reads) versus alternatives ('for similarity retrieval over remembered text use memory-recall') and describes the ownership/access model ('reads your own namespace by default; add ?owner=… to read a namespace you've been granted access to'). This is clear and actionable routing.

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

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

Annotations only flag readOnly=false, etc., but the description adds crucial context: cost per call, payment-as-authentication, namespace ownership, TTL expiration, delete operation, max value size, and hosted vs self-hosted modes. It clearly discloses mutation and idempotency implications 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?

Dense but every sentence earns its place: cost/auth upfront, usage semantics, alternatives, examples, and hosting options. No filler, logically ordered, and front-loaded with the most important operational facts.

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, namespaces, TTL, delete, size limits, output schema), the description covers all essential operational details including return fields. The existence of an output schema reduces the need to detail return structure further, so nothing critical is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description goes further by explaining how parameters combine (e.g., 'optional TTL', 'delete:true to remove', 'owner:0x…' for grants) and gives the exact body format, adding contextual meaning beyond the schema's per-property descriptions.

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

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

The description states a specific verb (write), resource (persistent key-value memory), and scoping (paying wallet). It clearly distinguishes from siblings memory-remember/memory-recall by contrasting exact-key storage vs retrieval by meaning, so an agent can differentiate without opening schemas.

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

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

Explicitly says when to use this tool vs alternatives: 'when you want retrieval by MEANING rather than key, use memory-remember + memory-recall instead' and also explains write/delete/owner behaviors. Conditions for writing into other namespaces are given, leaving nothing to inference.

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 though annotations already mark this as readOnly and idempotent, the description adds substantial behavioral context beyond them: the connector holds no wallet, 165 tools are free, paid tools settle via x402 in USDC, and the return shape is included. This is exactly the kind of operational detail an agent needs.

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 dense but front-loaded with the core purpose and every sentence carries relevant information. The long list of chains and return fields is justified because this is a reference-style informational tool.

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

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

For a zero-parameter read-only info tool, the description is complete: it explains what the tool covers, how payment works, what rails are supported, how to check wallets, and what the response contains. Nothing else is needed for an agent to invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4. There is nothing for the description to add about parameters, and the schema already fully covers this by having an empty properties object.

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

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

The description states a clear subject: how paying for Agent402 tools works and how to manage a wallet. It goes beyond the title by enumerating the free-vs-paid split, wallet configuration, rails, and balance checking, which fully distinguishes it from 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 gives clear context for when this informational tool is relevant and even points to catalog.call for balance/history queries. It does not explicitly state when not to use it or compare it to server.describe, but the usage context is unambiguous enough for an agent.

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, establishing this is a safe read-only operation. The description adds behavioral context: it explains the scoring logic (ranked by settled call counts, USDC totals, distinct buyers for x402; by inbound USDC.e transfers for MPP), the default windows (7d/30d, rolling), and the exclusion of the host's own wallet. This goes beyond what annotations provide, though it could mention rate limits or response pagination.

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 the core purpose. Every sentence adds value: the first defines the tool, the second and third explain the two wire modes, the fourth gives the use case, and the last notes the host exclusion. No redundancy or filler.

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

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

Given the tool's moderate complexity (4 parameters, 3 enums, no required params, no nested objects, and a rich output schema not shown), the description is complete. It covers the two ledger modes, ranking criteria, default behaviors, and a non-obvious detail (host exclusion). The output schema is assumed to exist and handle return values, so the description need not explain them.

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 baseline is 3. The description adds value by explaining what each wire type's sort modes mean ('x402: rank by settled USDC (default) or by settled call count. mpp: usd = 7-day volume, calls = 7-day transfers (default).') which is not fully conveyed by the schema's enum descriptions. It also clarifies the default behavior for 'include' (external vs all). Slight deduction for not elaborating on how 'limit' affects results (e.g., rank ordering).

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

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

The description starts with a clear verb 'List ranked sellers from the on-chain settlement leaderboards' and immediately differentiates between wire=x402 and wire=mpp, specifying exactly what data is returned for each. This makes the tool's purpose distinct from siblings like 'catalog.search' (which searches for services) or 'demand.request' (which requests a service), as it focuses on ranking sellers by settled volumes.

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 'Use it to find other services in the open x402 / MPP ecosystem' and notes that 'This host's own wallet is excluded unless include is set to all', which guides when to use the tool vs alternatives. However, it does not explicitly mention when NOT to use it or compare to sibling tools like 'catalog.find' or 'catalog.search' for locating specific services.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds beyond this by noting the tool is '[free]', what content it will provide (installation, tiers, URLs), and that it should be used first. This gives the agent behavioral context not present in 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, dense sentence that front-loads the purpose and lists key topics without padding. Every element earns its place, and the structure makes it easy to scan.

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

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

As a simple, parameterless tool with an output schema, the description fully covers its role, usage, and content. The 'Call this first' directive completes the picture, making it contextually sufficient for an agent to decide when and how to invoke it.

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 zero parameters, so the baseline is 4 per rubric. The description adds some context about what the tool covers, but since there are no parameters, no additional parameter-level semantics are possible.

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 'Describe this connector' and enumerates its coverage (tools layer, installation, free vs paid tiers, discovery URLs). This is a specific verb+resource that distinguishes it from the sibling tools, which are all operational tools rather than meta-descriptions.

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

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

The instruction 'Call this first' provides explicit when-to-use guidance. Given the sibling tools are diverse operations, this tool is positioned as the mandatory entry point for understanding the connector, making the usage context crystal 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 provide readOnlyHint, idempotentHint, and openWorldHint, so the description borrows on those. It adds significant transparency: cost ($0.08/call), grounding in an independent live search index (not training data), the precise return format ({query, answer, citations, citationCount}), and payment instructions. This goes well beyond annotations, covering both safety and operational 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 well-structured and front-loaded with cost and purpose. Every sentence adds value, though the payment section is a bit lengthy. It is not verbose overall but could be slightly tightened. It maintains a logical flow from what it does, to output, to usage, to payment.

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 that the output schema exists and annotations cover safety, the description is complete for an agent to decide and call correctly. It covers purpose, use case, cost, payment, grounding, and return format. An agent knows exactly what to expect and how to invoke it.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by giving practical guidance on max_tokens ('Lower for TL;DR; higher for research questions') and by explaining that output includes citations, which connects the q parameter to the result. It does not just repeat schema descriptions but provides usage nuance.

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 'AI-generated answer to a natural-language question' and specifies the resource (grounded in live web search results with source citations). It distinguishes itself from raw search tools like web.search and web.news by emphasizing synthesis plus citations, making its purpose unambiguous.

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

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

It provides a clear usage context: 'Useful when an agent needs a synthesized answer plus the receipts to verify or follow up.' This implies when to use it, but it does not explicitly name alternatives or state when not to use it (e.g., when raw search results are sufficient). The context is clear but lacks explicit 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 cover readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds value beyond annotations: it discloses the per-call cost ($0.02/call), the wallet-required payment mechanism (MPP / npx agent-index or prepaid credits), and that the hosted connector holds no wallet — auth/payment context annotations never provide. This meaningfully enriches the behavioral profile.

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 core function and output shape are front-loaded in the first clause, and the operational/payment details are gated to the end. The auth block is long but earns its place because agents must know how to fund the call. Slightly verbose overall, but each sentence carries 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 4-param, read-only search tool with a provided output schema, the description covers the essentials: expected return shape ({ query, count, results }), freshness semantics, the web-index-lags selection cue, and the required payment path. Nothing an agent needs to call it successfully (besides what structured fields already carry) is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description contributes minor param value by mapping freshness to the same filter codes as web search (pd/pw/pm/py), but the input schema already encodes those exact values and the count range, so the description mostly reinforces rather than adds new meaning. A 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?

States a specific verb and resource ('Live news search') and enumerates exact output fields (title, URL, snippet, age, source, breaking flag). It distinguishes itself from the sibling web.search by noting it is 'optimized for current-events queries where the web index lags', which an agent can use to pick between tools without opening either schema.

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?

Gives a clear when-to-use signal: current-events queries where the web index lags, and discloses it shares the web search freshness filter. It does not name the exact siblings (web.search / web.answer) or state an explicit when-not condition, so the guidance is useful but stops short of a direct alternative-selection rule.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds material behavioral context beyond that: a $0.02/call cost, an independent search index, freshness-filter semantics, the fact that results are untrusted external content, and the output shape. It clearly warns that results should be analyzed rather than treated as instructions, which is essential for an open-web search tool.

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 dense and front-loaded: it delivers the core action, cost, output format, use case, alternatives, untrusted-content warning, and payment options in a compact block. Every segment earns its place, especially for a monetized external-data tool where the agent must understand cost and trust before calling it. The length is appropriate for the information it conveys.

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 provided output schema covers the return value, and the description nevertheless summarizes return fields as well as cost, freshness behavior, untrusted content, and optional alternatives. There is no likely missing context that would prevent an agent from invoking the tool correctly for typical web discovery tasks.

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 coverage is 100%, so the schema already documents q, count, and freshness with basic types and defaults. The description adds value by expanding freshness values (pd/pw/pm/py = past day/week/month/year), giving the max-400-char behavior context, and explaining the output composition without repeating the full schema. This is solidly above the baseline but not a unique manual for every parameter.

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

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

The description opens with a specific verb-resource pair: live web search returning ranked results (title, URL, snippet, age) from an independent index. It also positions itself against siblings by saying 'Start here to DISCOVER pages' and directing current-events queries to search-news and synthesized answers to answer, so an agent can distinguish it from the other web 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?

It gives an explicit usage path: start here to discover pages, then read the winner with extract. It names alternatives for distinct use cases—search-news for current events, answer for cited synthesized answers—and even provides cost guidance about multi-search for several queries at once. This clearly helps an agent know when to select this tool versus siblings.

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