Ontario Protocol

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

Annotations already convey readOnly, idempotent, and non-destructive traits. The description adds useful context: the decision is 'free' and the 'free result is sufficient by default,' which clarifies the behavior around require_audit_receipt. 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?

Two sentences, no fluff. The first sentence states the core purpose, and the second gives crucial conditional advice. Every word 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 tool's moderate complexity, the description covers its purpose, key policy options, and the conditional flag. It does not elaborate on endpoint or max_usdc, but the output schema exists and annotations handle safety, so the description is sufficiently complete for a preflight decision tool.

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

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

Schema description coverage is low (25%), so the description carries more responsibility. It explains agent_policy (strict/standard/permissive) and offers guidance on require_audit_receipt, but leaves endpoint and max_usdc without added meaning beyond the schema's bare type declarations.

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 a specific action: 'Agents ask whether an x402 endpoint should be paid under strict, standard, or permissive policy.' This includes a verb, resource, and distinct scope (payment policy), effectively distinguishing 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 provides clear usage context: it's a pre-payment policy decision, and it advises when to set require_audit_receipt ('only when a settlement-backed receipt is required'). However, it does not explicitly name alternatives or state when not to use this tool, so it misses the top score.

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

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

The description discloses that the tool 'never signs or settles' (consistent with readOnlyHint), that 'public quality counts may include owner-funded calls and are not revenue', and that it runs a preflight check. This adds valuable behavioral context beyond the 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 paragraph that front-loads the core purpose, then efficiently lists return values and caveats without any wasted words. Every 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?

Despite having no output schema, the description enumerates all returned data points (retrieval coverage, sample ranks, alternatives, 30-day observations, price bands, HTTP 402 readiness, activation boundary) and caveats, making it complete for a read-only audit tool with rich annotations.

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

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

The input schema already provides 100% coverage with descriptions for target_url, buyer_query, and buyer_queries, including the default behavior of generating variants. The description adds context about 'five live variations' but does not add syntax or format details beyond the schema, so 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 clearly identifies a specific verb ('audit') and resource ('public x402 endpoint'), and details the scope ('five live CDP Bazaar buyer-search variations'), distinguishing it from siblings like x402_readiness_verify by focusing on buyer intent gaps.

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 as a preflight audit for measuring buyer visibility, but does not explicitly state when to use this tool over alternatives such as x402_readiness_verify or find_x402_tool. There is no exclusion or alternative guidance.

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

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

The description adds meaningful behavioral context beyond the annotations: it clarifies that the search is free, does not certify safety, and that paid Ontario publication adds no ranking score. It also mentions 'bounded source-reported recent activity,' which helps set expectations. No contradiction with readOnlyHint or idempotentHint.

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 appropriately sized for the tool's complexity. Every sentence carries distinct information: what it searches, how ranking works, what it does not do, and a special conditional path. No filler or repetition.

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

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

Given the tool's complexity, the description covers its scope, limitations, special-case routing, and relationship to safety checks. The output schema exists, so return values need not be described. The description is complete 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?

Schema coverage is 80%, and the description adds context for ranking and filtering, including budget filtering. It also reinforces the query parameter's safety constraint ('never include credentials'). However, it does not explain each parameter exhaustively, though the schema covers most.

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 a buyer-side search tool across specific markets, ranking candidates by task relevance and activity. It uses a specific verb ('search'), names the resources (Ontario profiles, Agentic Market, Coinbase CDP Bazaar), and distinguishes its scope from provider-side publication workflows seen in 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?

Provides explicit when-to-use guidance: 'This is discovery, not a safety certification; run readiness and can-pay before spending.' It also names alternatives and gives a conditional directive for provider-side intent, telling the agent to skip buyer search and use the listing validator and publication workflow.

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=false, destructive=false, idempotent=false, openWorld=true), the description discloses a paid operation with a two-step flow, a specific payment amount (0.50 USDC on Base), and explicit limitations: 'payment does not guarantee placement, a ready grade, traffic, ranking, purchases, or safety.' It also warns that 'Ontario is not Coinbase,' adding important context beyond what annotations provide.

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 with many clauses and disclaimers, making it hard to scan. It front-loads the usage condition but then becomes verbose with long lists and payment instructions. It could be structured with bullets or sections for clarity, but it is not concise.

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

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

Given the tool's complexity (15 parameters, paid, two-step flow), the description covers the critical contextual aspects: prerequisites, payment flow, and disclaimers. However, it does not explain many parameters or the output structure (though an output schema exists). It is complete enough for an agent to understand the operation but leaves gaps in parameter understanding.

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 only 13%, so the description must compensate, but it only explains _x402_payment and implicitly price_usdc. It details the two-step payment flow but omits meaning for the other 13 parameters like name, tags, endpoint, buyer_query, etc. With such a low coverage, the description fails to convey the purpose of most fields.

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 is for obtaining a public Bazaar launch passport with a comprehensive set of services, and the title says 'Publish'. It distinguishes the tool from Coinbase, but does not explicitly contrast it with sibling tools. The verb 'publish' and resource 'passport' are clear, though the scope overlaps with other Ontario tools.

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

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

The description gives explicit conditions: 'Use only when the caller owns an x402 endpoint and wants a public Bazaar launch passport...' It also instructs to 'Validate and run the free audit first' and 'run free can-pay and readiness checks first' before paying, which implicitly references sibling tools like agent_can_pay and x402_readiness_verify. It sets clear exclusions: 'payment does not guarantee placement...' providing strong guidance on when to use.

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

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

Beyond the readOnly and idempotent annotations, the description adds critical behavioral disclosures: 'This tool never invokes another tool, signs a payload, or spends funds.' It also discloses the optional 0.002 USDC receipt and the paid product costs (0.50 USDC, 0.10 USDC), which are 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?

Six dense sentences cover purpose, detailed routing logic, edge-case handling, and a safety guarantee. Every sentence conveys essential information with no filler or repetition, making it appropriately sized and well-structured.

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

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

The description fully covers decision branches, cost thresholds, preflight requirements, and safety behavior. With an output schema present, it does not need to explain return values, and the description leaves no significant gaps for the router's intended use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by mapping task categories (endpoint verification, provider jobs, evidence refresh) to the `task` parameter and explaining how `free_preflight_complete` and budget gates factor into routing. This enriches the meaning of parameters beyond their individual descriptions.

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

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

The description clearly identifies the tool as 'Free deterministic pre-purchase routing across Ontario tools' and explicitly states it is used before any paid Ontario tool. This distinguishes it from sibling tools like x402_readiness_verify and ontario_publish, which are actual execution tools rather than a router.

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

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

The description provides explicit when-to-use scenarios: endpoint verification routes to the free readiness verifier, provider jobs route to the publication product, existing profiles route to evidence refresh after the free validator, and empty calls return safe free discovery guidance. This gives clear decision criteria and differentiates from alternatives.

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 annotations by disclosing the two-step paid flow: first call without _x402_payment to receive payment requirements, then call again with the payment payload to settle and get the result. It also specifies the exact cost (0.10 USDC on Base) and the existence of a retry reference (paid_refresh_tx) for failures after settlement. This complements the readOnlyHint=false and openWorldHint=true annotations with concrete process 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 somewhat long but every sentence serves a purpose: it is front-loaded with the usage condition, then exclusions, then payment guidance, then the two-step flow. The structure is logical and scannable, but the payment guidance block is dense and could be tightened 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?

The description covers the purpose, usage boundaries, exclusions, payment flow, and retry behavior, making it highly complete for a paid mutation tool. With no output schema, a bit more detail about the expected result shape would help, but the description already implies the output involves the updated readiness observation on the profile artifacts. Overall, it is well-rounded.

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

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

All three parameters already have descriptive schema entries, so this is a high-coverage baseline. The description adds meaningful context for _x402_payment by explaining the two-step interaction and the cost, and it reminds that listing_id must be an existing paid profile. It does not repeat the schema but enriches the parameter understanding.

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 action ('refresh') and resource ('x402 Service Profile'), with the specific goal of attaching a fresh live readiness observation to the profile's HTML, JSON twin, and badge. It also differentiates from sibling tools by explicitly listing what it cannot do (edit metadata, improve grade via payment, buy ranking/traffic), 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?

This is exemplary usage guidance. It states exactly when to use the tool (existing paid Ontario provider profile needing a fresh readiness observation), when not to use it (during the 30-day included maintenance period), and provides a recommended workflow (run free can-pay and readiness checks first, pay only when policy allows). It also explicitly names unrelated actions to avoid.

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 (readOnlyHint=false, openWorldHint=true) already indicate side effects are possible, but the description adds no context about what those side effects are—e.g., whether it triggers external workflows, writes to GitHub, or requires authentication. The 'GitHub readiness workflow' hints at potential external actions but is vague.

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

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

The description is a single sentence with a clear subject and verb. It's front-loaded with 'Generate' and then enumerates outputs efficiently. Though the list is long, it contains no excessive words or redundancy.

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

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

With 10 parameters, no output schema, and no parameter descriptions, this tool demands rich context. The description only names outputs and gives no input guidance, no constraints, and no explanation of workflows like 'GitHub readiness.' An agent cannot construct a correct request from this description alone.

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 0%, and the description mentions no parameters. With 10 parameters (name, endpoint, price_usdc, etc.), the agent must guess meanings, formats, and required vs. optional fields. The description fails to compensate for the schema's lack of documentation.

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

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

The description uses a clear verb 'Generate' and lists specific concrete outputs (listing payload, x402 resource draft, MCP descriptor, GitHub readiness workflow, README snippet, registry copy) for 'one paid endpoint.' This distinguishes it from sibling tools like find_x402_tool or ontario_purchase_router, though it doesn't explicitly name them. The scope is well-defined.

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 on when to use this tool versus siblings (e.g., find_x402_tool, ontario_list-service). It doesn't state prerequisites, typical scenarios, or which tool covers other steps. The description only says what it does, not when it should be chosen.

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 useful context about cost and decision-making ('free check', '0.50 USDC publication', 'do not pay...'), but it does not clarify whether the check itself makes external calls or mutates any state, relying on annotations (openWorldHint=true, readOnlyHint=false). No direct contradiction with annotations, but the behavioral profile of the tool beyond 'check' is vague.

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 compact two-sentence block with the purpose front-loaded. It contains a slightly redundant use of 'free' and packs several concepts into a long second sentence, but every sentence contributes unique 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?

Given a simple one-parameter schema and an output schema available, the description covers purpose, usage timing, and cost context. The phrase 'grade-aware provider handoff' is jargon, but the output schema can clarify return structure, so this is acceptable.

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 sole parameter target_url is bare in the schema, but the description interprets it as 'a paid endpoint' that is being checked for readiness. This gives meaningful context to an otherwise undocumented string parameter, compensating for the 0% 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?

The description opens with 'Free check for whether a paid endpoint is ready for agent discovery and x402 payment,' giving a specific verb and resource. This clearly differentiates it from discovery/purchase siblings like find_x402_tool and agent_can_pay, though it does not name them explicitly.

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

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

The description provides explicit conditional guidance: 'validate listing metadata free before any optional 0.50 USDC publication' and 'do not pay for publication while the endpoint is not ready-grade.' This tells an agent when to use the tool (before paying) and when not to pay, though it does not mention alternative tools by name.

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