Ontario Protocol

Ontario Free/Paid Purchase Router

ontario_purchase_router

Read-onlyIdempotent

Free deterministic pre-purchase routing across Ontario tools. Use this before any paid Ontario tool to decide whether the task is free-only, needs free preflight, or is eligible for a paid result after wallet, Base network, and explicit budget gates. Natural endpoint-verification tasks route to the free readiness verifier and disclose the optional 0.002 USDC settlement-backed receipt only when extra audit evidence is needed. Provider jobs such as publishing, registering, or making an x402 endpoint discoverable can route to the self-serve 0.50 USDC publication product after preflight. Existing paid profiles can route to the 0.10 USDC evidence refresh only after the free refresh validator. Empty calls return safe free discovery guidance instead of guessing a purchase. This tool never invokes another tool, signs a payload, or spends funds.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`task`	Yes	Public task description only; never include credentials or private customer data.
`network`	No	Wallet policy network; Ontario paid tools currently require Base mainnet.	eip155:8453
`max_usdc`	No	Optional explicit per-call USDC ceiling. The router never increases it.
`wallet_enabled`	No	True only when the caller can locally sign an x402 PaymentPayload.
`free_preflight_complete`	No	True only after the recommended free check has completed for this task.

Output Schema

TableJSON Schema

Name	Required	Description
`gates`	Yes
`schema`	Yes
`status`	Yes
`privacy`	No
`reasons`	No
`decision`	Yes
`free_tool`	No
`next_action`	Yes
`payment_flow`	No
`selected_tool`	Yes
`task_category`	Yes
`input_guidance`	No	Safe free task examples returned when an MCP caller invokes the router without a public task.
`paid_candidate`	No
`trust_boundary`	Yes
`router_follow_up`	No	Non-spending request template for rerunning the router after the free preflight.
`optional_paid_upgrade`	No	A non-recommended upgrade disclosed after a matching free route. The caller should stop after the free result unless the stated evidence condition applies.
`listing_maintenance_path`	No	Present for existing-profile refresh intent. Gives the free validator followed by the gated paid refresher.
`provider_publication_path`	No	Present for provider-publication intent. Gives the free launch-kit and validator followed by the gated paid publisher.

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Ontario Protocol tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.3/5.0

Disambiguation3/5

Some tools have overlapping purposes, such as bazaar_buyer_intent_gap and x402_readiness_verify both performing audits, and ontario_list-service and x402_launch_kit both generating listing materials. However, the detailed descriptions clarify the distinct contexts, so an agent can generally tell them apart.

Naming Consistency2/5

Tool names mix snake_case (agent_can_pay), hyphenated (ontario_list-service), and inconsistent prefixes (x402_ vs ontario_). The verbs also vary widely (can_pay, find, list-service, refresh-listing, readiness_verify), making the naming pattern chaotic.

Tool Count4/5

With 8 tools, the count is within a reasonable range and each tool serves a distinct part of the x402 workflow. A few tools could potentially be merged (e.g., launch_kit as part of list-service), but the count is not excessive.

Completeness3/5

The core lifecycle of discovery, readiness verification, payment policy, listing, and refresh is covered. However, there is no tool for editing or deleting an existing listing, and the refresh tool explicitly cannot modify metadata, creating a notable gap in management capabilities.

Resources

Need Help?