Agent402.Tools: pay-per-call web tools

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

Annotations already mark it readOnly, idempotent, and non-destructive, and the description adds cost per call, wallet requirement, max duration and file size, and the exact response shape. It also discloses that the hosted connector holds no wallet and how payment can be handled, all beyond the annotation fields.

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 price and purpose, and every sentence adds operational detail (limits, alternatives, output shape, payment routes) without repeating schema content at length. It is dense but each clause earns its place.

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

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

For a paid transcription connector with two parameters and an output schema, the description covers required input, constraints, cost, authorization/payment, alternative endpoint, and return fields. An agent has enough information to decide and call the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by giving accepted audio formats, the 4-minute/25MB constraint for the URL parameter, and explaining that language improves accuracy, which the schema does not state.

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 'Transcribe audio to text using OpenAI (gpt-transcribe)' and specifies the input (URL to audio) and output (transcript), making the operation and resource unmistakable. It also differentiates from the longer-audio endpoint /api/transcribe-pro, and no transcription sibling exists in the listed 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 concrete when-to-use context: provide an audio URL, max 4 minutes/25MB, no API key needed, and payment via x402. It explicitly contrasts with /api/transcribe-pro for 10-minute audio and explains wallet/card payment alternatives for running the connector.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds valuable context beyond them: cost ($0.01/call), wallet/payment requirements, the untrustedContent warning, and the fact that the hosted connector holds no wallet. These are behavioral traits an agent needs to invoke and handle the tool safely.

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: purpose, cost, usage guidance, safety, output shape, and payment instructions are packed into four sentences with minimal waste. The return-object list slightly overlaps with the output schema, but overall each sentence 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 the simple one-parameter schema, the output schema, and annotations covering safety, the description still supplies all remaining invocation context: when to choose it, expected output, cost, authentication, and untrusted-content handling. It forms a complete contract for the agent.

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

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

The single 'url' parameter is already fully documented in the schema as 'Public http(s) URL to render', with 100% schema coverage. The description reinforces the URL's role but adds no new format, default, or constraint 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 states a specific action ('Render a page in a real headless Chromium browser'), the resource (a URL/page), and the output (clean markdown), making the tool's function clear. It also highlights JavaScript execution, which distinguishes it from plain fetching or search-based 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?

It explicitly says when to use this tool ('SPAs and JS-heavy sites where plain fetching returns an empty shell'), when to prefer another option ('try the cheaper extract first for static pages'), and when to use a different modality ('for pixel evidence use screenshot'). This gives an agent actionable selection criteria.

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?

Goes well beyond the readOnly/idempotent/non-destructive annotations: discloses rate limiting, that no wallet is held, that proof-of-work covers free-tool cost, that wallet-only tools return a setup guide instead of a result, and the failure mode for an unknown slug. These are exactly the behaviors an agent needs before invoking.

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?

Front-loaded with the core action and the discovery hint; the parenthetical asides (rate-limited, no wallet, proof-of-work) are informative but dense. Every sentence carries content, though the payment aside could be trimmed slightly.

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

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

With an output schema present, return values need not be re-explained, yet the description usefully notes the two return modes (JSON result vs paid-access setup guide). For a dispatcher tool with a dynamic nested params object, this is complete.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds a non-obvious semantic: the shape of 'params' is not fixed — it must match the dynamically selected tool's inputSchema. It does not, however, give examples or note validation/error behavior for malformed params.

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 (Run) and resource (an Agent402 tool) with the key selector (by slug). It immediately differentiates itself from siblings catalog.find/catalog.search by naming them as the discovery path rather than the execution path.

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 how to obtain a slug ('discover slugs with catalog.find or catalog.search'), what to do with params ('must match that tool's inputSchema'), and routes the agent elsewhere when the slug is unknown ('returns an error pointing back to catalog.search'). It also separates free-CPU tools from wallet-only tools, which changes whether calling is even useful.

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 readOnlyHint, idempotentHint, and destructiveHint, but the description goes further: it discloses the return shape ({ results, workflows }), the next step (catalog.call), the payment model (166 pure-CPU tools free, rest payable via MPP or npx), and where credentials live (_meta). 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 fairly long but every sentence carries distinct information: purpose, sibling contrast, cost model, and return shape. The core purpose is front-loaded and the additional payment/gateway context is relevant enough to earn its place.

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

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

For a read-only search tool with an output schema, the description covers the essential operational details: what it returns, how to run a result, how payment works, and where the credential is. Nothing an agent needs to correctly invoke it 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 adds value by framing the query parameter with natural-language examples ('search the web for x402', 'answer a question with citations', 'decode JWT') and clarifying the tool's role as a long-tail slug lookup, which helps the agent form better query strings.

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 and resource: 'keyword search over Agent402's 500+ pay-per-call tools'. It also explicitly contrasts with the sibling catalog.find ('search explores, find decides') and lists which flagships to start with, so an agent can distinguish this tool from alternatives 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?

It gives explicit when-to-use guidance: 'Start with the listed flagships... use this when you need a long-tail slug.' It names the alternative catalog.find and explains the split between exploring and deciding. This is enough to route an agent correctly.

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 meaningful behavioral context beyond annotations: it is '[free]', it 'Records demand only', requests are 'clustered by need', and recurring requests 'get built'. It also discloses the external API endpoints, which is valuable transparency.

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

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

The description is compact and front-loaded, leading with the core purpose and free status. Every sentence adds value: usage timing, behavioral expectations, and API references. 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?

Given the output schema exists and annotations are present, the description is complete. It covers when to use the tool, what it does, what it does not do, cost, and related endpoints. An agent has enough information 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond the schema, but the schema already provides clear descriptions and examples for both 'need' and 'context'.

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: 'Tell Agent402 about a capability its 500+ tools do not cover' and explicitly distinguishes it from catalog search/find tools. It also clarifies what the tool does not do: 'it never returns a tool or runs anything.'

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 it after catalog.search or catalog.find came back with nothing that fits, instead of giving up.' It also sets expectations that this is a demand-recording tool, not a resolution tool, preventing 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 declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context: per-call cost, end-of-day data timing, four-venue consolidation with volume limitations (venueVolume not total), missing 52-week and intraday data, and hosting/payment details. 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 dense but every sentence earns its place: cost, coverage, data source, limitations, return fields, and payment options are all relevant. The most important identifying information ('End-of-day US equity quote') is front-loaded, and there is no 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?

For a single-parameter tool with an output schema and safety annotations, the description covers all essential context: what data is returned, what is excluded, cost, payment methods, and related-tool routing. Nothing an agent needs to invoke it correctly 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 description coverage is 100%, so the schema already documents the single symbol parameter, including the ticker example and the US-equity-only constraint. The description mostly repeats this coverage rather than adding new parameter-specific semantics, so a baseline 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+resource: 'End-of-day US equity quote', and precisely scopes the tool to US equities. It explicitly lists what is not covered (indices, FX, crypto) and names alternatives (crypto-price, stock-history), making it clearly distinguishable from related tools even though those names are not in the sibling list.

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 boundaries: 'US equities only; indices, FX and crypto are not covered (crypto-price serves those)' and 'No 52-week range and no intraday print: for a date range call stock-history.' This tells the agent exactly when to use this tool and when to route elsewhere, leaving no 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?

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 are all false, so the description fully carries the behavioral burden. It discloses cost, x402 payment as authentication, wallet ownership semantics, delete usage, optional TTL, the 64KB value size, the ability to write into granted owner namespaces, and the hosting/deployment options. There is no mismatch with the annotations and no hidden behavior.

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

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

The description is fairly dense and long, but every sentence adds a distinct piece of information: cost, auth, namespace ownership, usage alternatives, exact request shapes, size limits, and deployment options. It could be tightened by moving the deployment note to the end or into annotations, but it remains efficient for a tool with this operational 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?

The output schema already covers return values, and the description covers the key operational context: billing, authentication, namespaces, TTL, deletion, size limits, and alternative memory tools. It is complete enough for a paid, wallet-scoped memory primitive, with only minor implicit semantics like overwrite behavior left untold but inferable from 'persistent key-value storage'.

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 adds meaningful semantics beyond the 100% schema coverage: it explains how TTL and delete are represented, clarifies that 'delete: true' is a special killer operation, defines 'owner' as another wallet's granted namespace, and provides an inline JSON body format. It does not merely restate the schema; it connects the parameters to real usage patterns, though the schema already supplies the baseline.

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

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

The description clearly states this is persistent, wallet-scoped key-value memory for agents, with an explicit write body and delete mode. It differentiates from memory-remember/memory-recall by contrasting exact-key storage with retrieval by meaning, making its distinct role 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 explicitly routes the agent to memory-remember + memory-recall when retrieval by meaning is desired, and explains the write/delete patterns and TTL behavior. It does not explicitly mention memory.read for exact-key reads, but the distinct names and storage semantics imply it, and the cost/authentication prerequisites are clearly stated. Some exclusion guidance is present but not exhaustive.

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

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

Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds valuable behavioral context beyond annotations: the hosted connector holds no wallet, 166 pure-CPU tools run free, and paid tools settle in USDC via x402. 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 dense but front-loaded with purpose and adds genuinely useful reference material. The long enumeration of supported chains is arguably over-detailed for a description, but it serves the wallet-setup reference role. Every section earns its place.

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

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

For an informational zero-parameter tool with an output schema, this description is complete: it explains what the tool does, what it returns, what payment rails are covered, how to configure wallet/spend controls, and where to check balance/history via a sibling tool. Nothing an agent needs to decide whether to invoke it 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?

The tool has zero parameters, so the schema already fully covers parameter semantics. The description appropriately focuses on the return payload and conceptual content rather than inventing parameter details, which is exactly the right division of labor.

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 purpose: explaining how paying for Agent402 tools works and how to manage a wallet. It names specific covered topics (free vs paid split, wallet configuration, spend caps, settlement rails, balance checking) and the return shape, which strongly distinguishes it from sibling tools like catalog.call or market.quote.

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

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

The description implies this tool is the entry point for understanding payment setup before using paid tools, and it explicitly routes balance/history lookups to catalog.call on wallet-balances / wallet-transactions. It lacks an explicit 'use when / don't use when' formulation, but the context is sufficient for an agent to select it appropriately.

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?

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses the cost ($0.01/call), payment options, the untrustedContent flag warning, and the exact return structure. It also mentions the source ('independent search index'), providing a clear behavioral picture with no contradictions.

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

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

The description is thorough but not bloated, front-loading the core purpose and then covering usage, security, and payment in logical order. The payment section is slightly lengthy with three options, but each adds necessary detail for a paid tool; no sentences are wasted.

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 paid live-news tool with security implications, the description covers all essential context: purpose, freshness semantics, usage differentiation, untrusted content warning, return format, and payment requirements. Since an output schema exists, return values need no further explanation. 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 descriptions already cover all four parameters with types and defaults (e.g., 'pd, pw, pm, or py (past day/week/month/year)'). The description adds minimal beyond that, only cross-referencing the freshness filter to web search. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description explicitly states 'Live news search' and details the exact output format (results[] with fields like title, url, age, source), clearly distinguishing it from general web search. It even names the sibling tool 'search' as the alternative for non-news pages, leaving no ambiguity.

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

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

The description specifies when to use the tool ('current-events queries where the web index lags') and when not to ('for general pages use search'), naming the alternative explicitly. It also notes the freshness filter is identical to web search, aligning usage expectations.

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, it discloses the wallet-required cost, marks results as untrusted content to be analyzed rather than followed, explains that results come from a live independent index outside the training cutoff, and describes the returned object shape. None of this contradicts the readOnly/openWorld/idempotent 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 dense but front-loaded with the cost, return contract, and primary use case. The long payment-instruction tail is functionally relevant for a wallet-required tool, so it is not gratuitous, though it prevents a top score for concision.

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 three-parameter, read-only search tool with an output schema and safety annotations, the description covers selection, output shape, freshness, cost, authentication/payment, and trust handling. Nothing material appears missing for an agent to decide to call it and understand the interaction.

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, but the description adds value by giving freshness filter semantics (pd/pw/pm/py = past day/week/month/year) and by stating results are ranked, which clarifies q and freshness behavior. It does not add much beyond the schema for count, but the added freshness meaning justifies a 4.

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 and resource: 'Live web search' returning 'ranked results[]' from an independent index, and explicitly positions it as the tool for discovering pages. It differentiates itself from siblings by pointing to search-news for current events, answer for synthesized answers, and search-lite for quick samples, so an agent can distinguish it 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?

It gives clear selection guidance: 'Start here to DISCOVER pages, then read the winner with extract' and names alternatives for quick sampling, current events, synthesized answers, and batched queries. This is explicit when-to-use plus alternatives, leaving little to inference.

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