Ontario Protocol

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is largely covered. The description adds useful behavioral context beyond that: the tool is free, returns a three-way decision with reasons and report evidence, and require_audit_receipt triggers only an optional settlement-backed receipt handoff rather than submitting payment.

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 tight sentence that front-loads the core decision and follows with the optional receipt handoff. Every clause earns its place, with no redundant restatement of the name or annotations.

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 annotations cover safety semantics, all four parameters are fully described in the schema, and an output schema exists, the description is nearly complete for an agent to call the tool correctly. It could be slightly stronger with an explicit pointer to when an agent should choose this over sibling readiness or verification tools, but the core decision context is present.

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 every parameter, including endpoint safety, max_usdc ceiling semantics, agent_policy defaults, and require_audit_receipt behavior. The description reiterates the policy modes and receipt handoff but adds no new parameter-level semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a specific verb and outcome: a free pre-payment policy decision returning allow, review, or deny for one x402 endpoint. It is clear what the tool does, though it does not explicitly differentiate itself from sibling verification tools such as x402_readiness_verify or agent_trust_preview.

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 phrase 'Free pre-payment policy decision' implies this belongs before a payment is attempted, and the description notes that require_audit_receipt adds an optional post-allow handoff. However, it gives no explicit when-not guidance and does not name an alternative tool for related checks, leaving the agent to infer 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 declare readOnly/idempotent/openWorld/non-destructive, and the description adds real context beyond them: it is free, rate-limited, and returns only 'safe signals and issues' rather than the paid evidence bundle or attestation. This sets expectations about output scope and throttling that the annotations do not convey.

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

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

A single dense sentence with the free/rate-limited/free-tier framing front-loaded before the scope and the paid contrast. 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?

With an output schema handling return values and annotations covering the safety profile, the description supplies the remaining essentials: cost tier, rate limiting, and free-vs-paid output scope. Only the explicit alternative tool choice is left implicit.

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 already documented. The description reinforces that only one public endpoint per call is previewed and that it must be public, but adds no format or identifier semantics beyond the schema 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?

States a specific verb+resource: a live trust preview for one public endpoint, and immediately contrasts it with the paid trust scan that adds evidence/attestation. An agent can tell what it gets without opening the schema, though no sibling tool is named directly.

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?

'Free live, rate-limited' and 'for one public endpoint' give clear selection context, and the mention of the paid trust scan that 'adds them' signals the upgrade path. It stops short of an explicit 'use this when X, use the paid/other tool when Y' statement.

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 goes well beyond the annotations by stating that the audit 'never signs or settles' and that quality counts may include owner-funded calls and are not revenue. It also clarifies 'Free read-only provider audit,' matching the readOnlyHint and idempotentHint while adding meaningful caveats that annotations alone could not convey.

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

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

The description is dense and front-loaded with the core 'read-only provider audit' purpose. While the first sentence is long and lists many output types in a run-on structure, every clause contributes useful information 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 complex tool with an output schema, annotations, and three parameters, the description covers purpose, safety guarantees, data-quality caveats, and the main operational boundary. It does not explain how this tool relates to siblings or when a caller should pick it instead, which leaves minor contextual ambiguity.

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 schema already explains target_url and buyer_query well. The tool description does not add substantial parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate; the 'five variations' behavior is already documented in the buyer_queries schema description.

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 names a specific verb-and-resource pair: it runs a read-only provider audit against one public x402 endpoint across CDP Bazaar buyer-search variations. It also enumerates the concrete outputs (retrieval coverage, sample ranks, price bands, activation boundary), which distinguishes it from sibling tools like x402_readiness_verify or find_x402_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 implies usage context: this is for auditing buyer visibility of an x402 endpoint and explicitly positions itself as free and read-only. However, it never explicitly states when to choose this tool over its siblings, nor does it name any alternatives or exclusion criteria, so the agent is left to infer 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?

Goes well beyond the annotations (readOnly/openWorld/idempotent) by disclosing that nothing is probed, that listings may be dead or mispriced, that activity is bounded and source-reported, and that paid publication confers no ranking advantage. These are exactly the expectations an agent needs before trusting results, and they are not derivable from structured 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?

Purpose and scope are front-loaded in the first clause, and the caveats and alternative routing follow logically. The closing sentence on provider-side publication queries is dense and somewhat opaque—mixing a validator pointer with a 0.50 USDC pricing note—which slightly blunts an otherwise tight description.

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

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

With annotations and an output schema present, the description needn't explain return shape, and it covers sources, ranking policy, freshness limits, budget filtering, and one key alternative. The remaining gap is in a crowded sibling set of 18 tools where more than one alternative is named for disambiguation.

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 real meaning by framing max_usdc as an optional budget ceiling, network as Base-oriented filtering, and clarifying that active_only depends on source-reported or fresh-profile evidence. It does not add syntax-level detail for network identifiers, but the schema already carries 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?

States a specific verb and resource ('free buyer-side search' for x402 tools) and enumerates the exact sources searched (Ontario strict-ready profiles, Agentic Market, Coinbase CDP Bazaar). It also describes the return contract ('unverified marketplace candidates ranked by task relevance'), which lets an agent distinguish it from retrieval-style siblings without opening a 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?

Explicitly names the alternative for live-verified results: 'ontario_find-api returns live-checked candidates,' giving a clear selection condition. It also signals the buyer-side vs provider-side split in the final sentence. It stops short of routing against other overlapping siblings such as ontario_task_fit, agent_can_pay, or bazaar_buyer_intent_gap, so it is clear 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 readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds meaningful behavioral context beyond these: it specifies the scan scope (what it checks), the output form (paths and remediation), and the key guarantee of never exposing source contents. This reassures an agent about safety and output boundaries.

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

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

Two sentences, no filler. The first sentence front-loads the purpose and scope; the second clarifies outputs and a critical safety constraint. Every word adds value.

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

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

The description covers what the tool scans, what it returns, what it never returns, and its public-repo requirement. An output schema exists for return values, so no further explanation of the response shape is needed. Complete for an agent to call this 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% for the single parameter repository_url, with a clear format and description. The tool description does not add extra semantic detail about the parameter (e.g., URL validation rules or expected format), but the schema already covers it adequately. 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 states a specific verb ('scan'), a specific resource ('one public GitHub repository'), and enumerates the exact categories checked (x402 implementation, HTTP 402 tests, payment configuration, buyer documentation, discovery metadata, CI gates, sensitive filenames). It also clarifies what it returns (paths and remediation) and what it never returns (source contents). This distinguishes it from sibling audit/verification tools, which likely target broader or different scopes.

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 a pre-deployment use case but does not explicitly contrast this tool with the sibling tools like ontario_x402-implementation-audit or x402_readiness_verify. An agent would need to infer when to pick this over those. No exclusions or alternative-routing guidance is provided.

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

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

Adds substantial context beyond annotations: cost ($0.002 USDC), failure policy (no charge on failed read), no account/API key, and the full two-step x402 payment flow including the PaymentRequired response, the params._meta['x402/payment'] retry, and the legacy base64 argument. This also explains why readOnlyHint=false despite being a read (payment is transferred), so no contradiction.

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

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

The capability sentence is front-loaded and the payment block is bracketed and clearly separated. It is longer than typical, but nearly every clause (price, no-charge-on-failure, no API key, payment retry mechanics) carries decision-relevant information for the agent.

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?

Output schema exists, so return-value explanation is not required, yet the description still summarizes the returned fields (symbol, decimals, raw/formatted amount, block number). Combined with full payment-mechanics disclosure and scope limits, nothing an agent needs to call it successfully 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% and both meaningful parameters (address, tokens with max 20) are already documented in the schema. The description restates required/optional shape and adds only the constraint that named extras are not discovered beyond the listed set, which is marginal added meaning.

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?

Opens with a specific verb-and-resource statement: reads ETH, USDC, ~25 widely held Base tokens, plus up to 20 caller-named ERC-20 contracts, for any address. It also names the data source (Base mainnet RPC) and the returned fields, which clearly separates it from siblings like ontario_base-gas and ontario_base-tx-check.

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?

States prerequisites ('Required: address'), scope restrictions ('Base mainnet only'), and explicit exclusions ('no prices or USD values; tokens outside the list and your extras are not discovered'). It does not explicitly route to an alternative sibling when the exclusions apply, so it falls short of a 5.

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 give only hint flags, and the description goes well beyond them: the exact price ($0.0015 USDC), the no-charge-on-failure policy, the two-step x402 payment flow with the PaymentRequired retry and params._meta path, and that signing happens in the caller's wallet. That is substantial operational context an agent needs. It does not cover idempotency or whether repeated paid calls re-charge, leaving a small gap.

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 output inventory is front-loaded and every clause maps to a real capability. The main inefficiency is the price being stated twice, once inline ('$0.0015 USDC on Base') and again in the bracketed PAID block, plus the payment boilerplate lengthening an otherwise tight definition.

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 an output schema exists, the description need not explain return values, yet it still summarizes them usefully. Combined with cost, failure semantics, and the full payment handshake, an agent has everything needed to invoke this paid tool correctly.

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

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

Schema description coverage is 100%, so both `blocks` and `_x402_payment` are already documented in the schema. The description restates the 5–50 range and default without adding new meaning, which is the expected baseline when the schema does the work.

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 precise verb/resource statement ('Base gas price') and enumerates exactly what is returned: base fee, priority fee percentiles over the last 20 blocks, ready-to-sign maxFeePerGas values, L1 data-fee bound, and transfer cost estimates from Base mainnet. It is clearly distinguishable from siblings like ontario_base-balances and ontario_base-tx-check.

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 states the required/optional parameters and the caveat 'Estimates, not inclusion guarantees,' which implies usage for gas estimation. However, it never says when to prefer this tool over siblings or what conditions should steer an agent elsewhere; the guidance is implied rather than explicit.

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 annotations by disclosing pricing ($0.002 USDC on Base), the no-charge-on-not-found policy, the two-step x402 payment handshake (MCP PaymentRequired then signed PaymentPayload in params._meta), the legacy _x402_payment fallback, and that signing happens in the caller's wallet. This also explains why readOnlyHint=false despite the operation being a verification call.

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 capability and return payload before the commercial/payment details; every sentence is informational. Minor redundancy: the $0.002 USDC on Base price is stated twice, once inline and once in the bracketed paid-flow block.

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, single-purpose verification tool with an output schema, the description covers inputs, outputs, pricing, failure semantics, network scope, and the payment handshake. An agent has everything needed to invoke it correctly on the first call and to interpret a PaymentRequired response.

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 expected_to and expected_amount as producing 'match flags' against the decoded USDC transfer, and by explaining the _x402_payment retry mechanics. It does not restate formats (atomic units, address patterns), which the schema already covers.

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?

Opens with a specific verb+resource ('Verify Base transaction by hash') and enumerates exactly what is returned: status, block, timestamp, confirmations, decoded USDC/ERC-20 transfers, EIP-3009 authorizations, and match flags. This clearly separates it from siblings like ontario_base-balances or ontario_base-gas.

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 names the use case ('so an x402 payment receipt or PAYMENT-RESPONSE can be checked as settled') and states prerequisites: required hash, Base mainnet only, no account or API key. It does not name an alternative sibling for non-payment transaction inspection, so it falls short of a 5.

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 annotations: discloses the price ($0.005 USDC on Base), the two-step x402 payment handshake (unpaid call returns MCP PaymentRequired, retry carries PaymentPayload in params._meta['x402/payment']), the legacy _x402_payment fallback, that signing happens in the caller's wallet, and that no match means no charge. It also sets the correct expectation with 'Recommendations, not a safety guarantee.' This is exactly the behavioral disclosure annotations cannot carry.

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 purpose question and a one-line answer, then pricing/behavioral notes, then a bracketed payment-mechanics block. The bracketed section is dense but cleanly separated, and every sentence carries information. Slightly heavy at the front with the 'ranked by task fit, price and Bazaar-reported repeat buyers' run-on.

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?

An output schema exists so return values need no explanation, yet the description still names what comes back (live price, network, ready-to-call request). Combined with full payment-flow disclosure and the 'no account, no API key' onboarding facts, an agent has everything needed to call this correctly on the first attempt.

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, but the description adds real meaning on the payment parameter — the two-step flow and where the signed payload goes — which the schema does not explain. It also frames 'task' as the required input and ties 'limit' implicitly to the 'up to 5' return cap.

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 — a live API finder that returns up to 5 x402-paid APIs verified by a fresh unpaid probe with a valid Base USDC 402. The verification and ranking criteria make the operation concrete. It does not, however, distinguish itself from the similarly named sibling 'find_x402_tool' or from 'ontario_task_fit', so an agent cannot route between them from this text alone.

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 opening question 'Which x402 API should my agent call?' implies the discovery use case, and 'Required: task' plus 'No live match, no charge' gives some selection context. But there is no explicit when-not guidance and no mention of the close siblings find_x402_tool, ontario_task_fit, or bazaar_buyer_intent_gap that an agent would need to compare against.

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 annotations by disclosing the price (0.10 USDC on Base), the exact two-step x402 flow, where the proof goes in params._meta, that a legacy base64 argument is also accepted, and that signing occurs in the caller's wallet. It also sets honest expectations that payment does not guarantee approval, traffic, ranking, or safety — non-obvious behavior an agent cannot get from readOnlyHint=false / idempotentHint=false.

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 first sentence front-loads the action and the second the expectation-setting caveat, with payment mechanics bracketed off so they can be skipped by a reader who only needs intent. The bracket block is dense but every clause (price, flow, fallback argument, signing location) carries operational weight — one sentence about rejection reasons or moderation timing would have been the only justified addition.

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?

An output schema exists so return values need no explanation, and the description covers the cost, the payment protocol, and the no-guarantee caveat — the three things most likely to trip an agent on a paid write. It stops short of saying what happens after submission (review/moderation, listing latency, duplicate handling for an agent already listed), though that is secondary to correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns a bump because it explains payment mechanics that the schema only hints at — the schema documents _x402_payment while the description reveals the preferred _meta['x402/payment'] transport and when each applies. The other listing fields (name, tags, agent_card_url) are left entirely to the schema.

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

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

States a specific verb and resource — 'Submits a public directory listing for an agent the caller owns' — which disambiguates the otherwise confusing name 'list-agent' (submission, not enumeration). The ownership scope ('an agent the caller owns') further separates it from ontario_list-service, the sibling for a different resource type.

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

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

It gives procedural guidance for the payment handshake (call without payment, then retry with the signed payload) and notes validation is free, which is useful when-to-call context. However, it never states when to choose this over siblings like ontario_refresh-listing for updates or ontario_validate-agent for pre-checks, so alternative routing is left 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?

Extensive disclosure beyond annotations: the 0.50 USDC Launch Passport fee, the two-step PaymentRequired-then-PaymentPayload flow, the legacy _x402_payment fallback, wallet-side signing, the 30-day freshness window, and an explicit list of what is NOT guaranteed (placement, ranking, traffic, purchases, ready grade, safety). All of this is consistent with the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), so there is no contradiction.

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

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

Purpose is front-loaded in the first sentence, and the negative guarantees plus payment mechanics are in a clearly bracketed trailing block. It is dense and runs long, with some overlap between the prose and the schema field descriptions (e.g. price separation is stated twice), but nearly every clause carries actionable 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 an 18-parameter paid mutation with an output schema already covering return values, the description supplies the missing pieces: cost, payment handshake, the two-step call sequence, signing location, freshness duration, and explicit non-guarantees. Nothing an agent needs in order to invoke it correctly appears to be 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, but the description adds genuine semantics: it clarifies that price_usdc is the provider endpoint price, distinct from Ontario's 0.50 USDC publication fee, and explains how the payment argument works via params._meta['x402/payment'] with the legacy _x402_payment alternative. That materially helps an agent wire up the payment parameter 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 opening sentence gives a specific verb and resource — publish a provider-owned x402 API for agent discovery and purchase. It clearly distinguishes the paid listing/profile creation from adjacent flows like free validation and freshness maintenance, though it never names the sibling tools (e.g. ontario_validate-service, ontario_refresh-listing) that an agent should route to for those steps.

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?

Usage is implied rather than explicit: the reader infers this is the paid publication step that follows validation and a Bazaar audit, and that it enables eventual strict Ontario discovery. There is no direct when-to-use/when-not statement or named alternative, so an agent must reconstruct the workflow from hints like 'After free validation'.

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 and openWorld, so the safety bar is lower. The description still contributes real behavioral facts beyond that: it never invokes another tool, never signs a payload, never spends funds, and prices are disclosed up front (0.002, 0.10, 0.50 USDC). The decision vocabulary (free_only, run_free_preflight, paid_recommended) is useful context the annotations cannot express.

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 purpose is front-loaded, but the description is a dense run-on chain of product names, currency amounts and parentheticals that is hard to scan. Several clauses (listing each paid read it can recommend) could be trimmed without losing selection guidance.

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?

An output schema exists, so return values need not be explained, and the description still covers safety posture, decision states, price disclosures and the empty-call fallback. The only real gap is guidance for ambiguous tasks that map to more than one branch, which is not addressed.

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 tying parameters to routing outcomes: wallet/budget checks feed the paid_recommended decision and the free_preflight_complete gate is mirrored by the run_free_preflight outcome. It reinforces but does not contradict the schema's statement that a budget ceiling grants no spending authority.

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 first sentence states a specific verb and resource: route one public task to Ontario's free and paid tools and return a matching tool plus a decision. This clearly separates it from execution siblings like ontario_find-api or x402_readiness_verify, which it only recommends. It stops short of 5 because the middle of the description buries the router concept under product names and prices.

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?

Concrete routing cases are given: endpoint-verification tasks go to the readiness verifier, provider jobs such as publishing/registering go to the 0.50 USDC publication product, existing profiles go to the 0.10 USDC refresh, and empty calls return examples instead of guessing. It never states negative guidance such as when to call ontario_find-api directly instead of routing through here, so it falls short of explicit when-not coverage.

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 the annotations, the description discloses the payment model (0.10 USDC via x402 on Base), the two-step PaymentRequired retry flow, where the signed payload goes, legacy payment support, and that signing happens in the caller's wallet. It also explains what the tool cannot do and notes automatic freshness during the first 30 days, giving strong behavioral context for a mutation 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 purpose is front-loaded and the payment details are grouped at the end. Every sentence carries useful information, though the negative constraint sentence and the payment paragraph make it denser than a minimal definition.

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 mutation tool with annotations and an output schema, the description is complete enough: it covers the action, payment prerequisites, retry mechanics, limitations, and freshness timing. Return-value details can be left to the output schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful meaning beyond the schema by explaining the x402 payment flow, the params._meta['x402/payment'] retry location, and support for the legacy _x402_payment base64 argument. It does not explain paid_refresh_tx in detail beyond the schema description.

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: attaching a fresh live readiness observation to an existing paid Ontario provider profile's canonical HTML, JSON twin, and badge. It also draws boundaries by saying it cannot edit metadata, improve grades by payment, or buy ranking/traffic. It does not explicitly distinguish itself from the sibling ontario_validate-refresh tool, so it falls short of a 5.

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

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

The description implies when the tool is useful by mentioning freshness maintenance and the first 30 days of the launch passport, but it does not explicitly state when to use this tool versus ontario_validate-refresh or other sibling tools. The negative constraints clarify what the tool cannot do, but they are not alternatives 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?

Beyond the annotations, the description discloses data-handling behavior (task text and tool descriptions go to TypeSafe, Ontario does not persist task text, zero retention not promised), a prohibition on secrets/personal data, quota-exhaustion fallback to deterministic routing, and the hard boundary that it never executes tools or authorizes payment. That is exactly the extra context annotations cannot convey.

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

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

Purpose is front-loaded in the first sentence and every subsequent sentence carries a distinct constraint (consent, privacy, non-execution, fallback). It is dense prose rather than a structured list, which slightly hurts scanability for a six-parameter 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?

The return-or-abstain behavior and the no-execution boundary are stated, and an output schema exists to cover return shape. The gap is the multi-step payment context: the description never explains how free_preflight_complete, wallet_enabled, and max_usdc sequence with ontario_purchase_router.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including the network/payment constraints. The description echoes the allow_typesafe privacy warning but adds no new semantics for max_usdc, wallet_enabled, or free_preflight_complete, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'task-to-tool matching', plus the optional Jev inference mode, so an agent knows this maps a task to a tool rather than executing anything. It does not, however, distinguish itself from plausible siblings such as find_x402_tool or ontario_purchase_router, so the agent must infer which matcher to pick.

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 conditions for the allow_typesafe branch ('With allow_typesafe=true...', 'Without consent, only Ontario's deterministic router is used'), which is useful. But it never says when to use this tool versus find_x402_tool, ontario_find-api, or ontario_purchase_router, leaving sibling selection 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?

Annotations provide readOnlyHint=false and destructiveHint=false, but the description adds meaningful behavioral boundaries: 'Never publishes, signs or spends' and 'for free.' These clarify side-effect risks beyond the structured flags. It does not discuss other potential side effects, but the key safety constraints are disclosed.

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

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

The description is two short sentences with no redundant phrasing. The primary action is front-loaded, and the critical exclusion ('Never publishes, signs or spends') is stated immediately. Every word adds value.

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

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

The tool is moderately simple with a complete input schema and an output schema, so the description need not cover return values. It covers the purpose, timing, cost, and key side-effect constraints. It does not mention prerequisites like authentication, but for a validation tool this is not a significant gap.

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

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

Schema description coverage is 100%, so all six parameters are already fully documented. The description only refers to them collectively as 'an agent listing payload' and adds no additional meaning beyond the schema. 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 names a specific verb ('Validate') and resource ('agent listing payload') and adds the scope 'before publication.' The sentence 'Never publishes, signs or spends' clearly differentiates it from sibling tools such as ontario_list-agent or payment-related tools, even without naming them.

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 phrase 'before publication' gives clear timing context for when to use the tool. However, it does not explicitly mention alternatives or state when not to use it, nor does it name any sibling tools. The usage guidance is implied rather than explicit.

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 concrete behavioral guarantees beyond the annotations: no refresh, no signing, no spending, plus the existence of a cooldown check. This matters because readOnlyHint=false and idempotentHint=false leave the agent unsure how safe the call is; the explicit 'never spends/refreshes' resolves that. It does not say what state the call does touch (the reason readOnlyHint is false).

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

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

Two sentences, both front-loaded: the first states what it does and that it is free; the second eliminates the three risks an agent would worry about. No padding.

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?

An output schema exists, so return shape need not be explained, and the safety profile and cooldown mention cover the main behavioral unknowns for a 2-parameter validation tool. Only the interaction with ontario_refresh-listing and the retry reference's role in a validation check are left unstated.

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 both parameters (listing_id, paid_refresh_tx) are already documented in the schema. The description adds no parameter-level meaning, which is acceptable given full schema coverage.

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

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

States a specific verb and resource — 'check ... refresh eligibility' on 'an existing paid provider profile' — which an agent can distinguish from the sibling ontario_refresh-listing. It does not name that sibling explicitly, so the negative-space framing is only implied.

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?

'for free' and 'Never refreshes' imply this is the side-effect-free pre-check before a paid refresh, but no alternative (ontario_refresh-listing) is named and no explicit when-to-use or when-not-to-use condition is given. Usage must be inferred.

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?

Despite readOnlyHint=false, the description discloses exactly what write occurs: a public signed readiness report is saved during a live scan with an 8 s budget, plus an exact-URL Bazaar lookup. It adds the failure mode ('endpoint_unreachable with the fix') and safety boundaries ('never publishes, signs or spends'), which annotations alone would not convey.

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

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

It is one dense paragraph, but the core action and the key flag (verify_now) are front-loaded and every clause carries information. It is slightly packed with fee and error-mode details that could be split, but nothing is 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 18 parameters and a complex scan-and-report behavior, the description covers inputs, side effects, the verify_now branch, the return shape (grade, score, report_published, Bazaar presence, top findings, or endpoint_unreachable), and an output schema exists for field detail. Nothing an agent needs to call 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 coverage is 100%, so every one of the 18 parameters is already documented in the schema, including verify_now's effect. The description reinforces verify_now semantics but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb and resource: 'Free provider listing preflight' that 'Validates public service metadata, runs a live readiness scan ... and an exact-URL Bazaar lookup.' It is clearly separable from sibling write tools like ontario_list-service and from ontario_validate-agent by naming the x402 service-listing object and the free preflight scope.

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 states the trigger context (preflight for the 0.50 USDC Ontario launch passport) and an explicit branching rule: 'verify_now=false skips the scan and the report.' It also rules out the publishing path with 'Never publishes a listing, signs or spends,' implying ontario_list-service is the alternative, though that sibling is not named outright.

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, openWorldHint=true, and destructiveHint=false. The description adds meaningful context by specifying that the output is 'validated' and scoped to 'one paid endpoint,' and its 'Generate' wording is consistent with a non-destructive, read-only drafting operation. No contradiction exists.

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

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

A single dense sentence that front-loads the action and then lists the specific outputs. Every word earns its place, and the scope constraint 'for one paid endpoint' adds precision without padding.

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 rich input schema, output schema, and safety-revealing annotations, the description is largely complete: it names all artifact types and the scope. The only notable gap is the lack of relationship to sibling tools and workflow timing, which is partially captured under usage guidelines.

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 input schema already documents all ten parameters thoroughly. The description adds no additional parameter-level semantics beyond framing the tool as producing artifacts for one paid endpoint, which is appropriate given the schema already carries the burden.

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 begins with a specific verb, 'Generate,' and enumerates six concrete deliverables (listing payload, x402 resource draft, MCP descriptor, GitHub readiness workflow, README snippet, registry copy) for a paid endpoint. This makes the tool's purpose immediately distinguishable from generic or sibling operations.

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

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

The description provides no guidance on when to use this tool versus alternatives such as ontario_list-service, ontario_validate-service, or x402_readiness_verify. It states what is generated but not the intended workflow position, prerequisites, or situations where another sibling would be more appropriate.

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 annotations declare readOnlyHint=false, but the description frames the tool as a 'free check' that will 'inspect without payment,' which implies a read-only inspection. This is a contradiction. Even though the description usefully notes that the check is free and that publication is an optional 0.50 USDC step, the annotation conflict is disqualifying under the rubric.

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 definition is two sentences and front-loads the purpose before describing outputs. It is efficient overall, though terms like 'ready-grade' and 'handoff' are slightly dense and could be clearer.

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

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

The tool has an output schema, so the return values do not need full explanation. However, given the read-only contradiction and the lack of detail about rate limits, auth, or endpoint-unreachable behavior, the description is only adequate rather than 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?

There is one parameter with 100% schema description coverage, and the schema already explains that it is a public service or x402 endpoint URL. The description adds no additional meaning about the parameter beyond what the schema provides, so the baseline score is appropriate.

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

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

The description states a specific verb and resource: checking whether a paid endpoint is ready for agent discovery and x402 payment. It is distinct from most siblings, but it does not explicitly differentiate itself from adjacent tools such as x402_verification_reports or x402_launch_kit.

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 word 'Free' and the mention of optional 0.50 USDC publication imply this is a pre-publication readiness check, but there is no explicit statement of when to use it versus alternatives. It also does not define when not to use it or what prerequisites are required.

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 non-destructive behavior, so the safety profile is well covered. The description adds that the data is public and recent, which is mild contextual value, but it does not describe pagination or what a report contains.

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?

One short sentence with no filler; 'public' and 'recent' add meaningful scope and the description is front-loaded. It could be improved by an explicit verb, but as written it is economical and to the point.

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 simple read-only tool with one fully documented parameter and an output schema does not require extensive prose, but the description is too terse to fully orient an agent among many x402-related siblings. Some usage context or a pointer to a complementary tool would complete 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 single parameter limit is fully documented in the schema, including a default and description. The tool description repeats 'recent public readiness reports' but adds no semantic detail beyond the schema's parameter description, so the baseline 3 applies.

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

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

The description characterizes the tool as a public ledger of recent x402 readiness reports, making the resource and scope clear and separating it from action-oriented siblings like x402_readiness_verify. It lacks an explicit verb such as 'list' or 'retrieve,' so the operation is inferred rather than stated.

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

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

No guidance is given about when to use this tool versus sibling tools such as x402_readiness_verify, x402_launch_kit, or ontario_x402-implementation-audit. An agent must infer the use case entirely from the resource description and the readOnlyHint.

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