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 owner-authorized per-call USDC ceiling from 0 to 1000. Use a unitless JSON number or decimal string, such as 0.5 or '0.50'; do not add a currency symbol or write 'USDC'. Omit when no budget is authorized; a budget is only a ceiling and does not grant spending authority. 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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 23, 2026

addedInput schema / properties / max_usdc / anyOf

Added value: +[
+  {
+    "pattern": "^(?:(?:0|[1-9][0-9]{0,2})(?:\\.[0-9]+)?|1000(?:\\.0+)?)$",
+    "type": "string"
+  },
+  {
+    "maximum": 1000,
+    "minimum": 0,
+    "type": "number"
+  }
+]

changedInput schema / properties / max_usdc / description

Previous value: -"Optional owner-authorized per-call USDC ceiling from 0 to 1000. Use a decimal string without a currency symbol or unit, such as '0.50', not '$0.50' or '0.50 USDC'. Omit when no spending budget is authorized; do not infer authorization from these examples. The router never increases it."New value: +"Optional owner-authorized per-call USDC ceiling from 0 to 1000. Use a unitless JSON number or decimal string, such as 0.5 or '0.50'; do not add a currency symbol or write 'USDC'. Omit when no budget is authorized; a budget is only a ceiling and does not grant spending authority. The router never increases it."

changedInput schema / properties / max_usdc / examples

Previous value: -[
-  "0",
-  "0.002",
-  "0.10",
-  "0.50"
-]New value: +[
+  "0",
+  "0.002",
+  "0.10",
+  "0.50",
+  0.5
+]

removedInput schema / properties / max_usdc / pattern

Removed value: -"^(?:(?:0|[1-9][0-9]{0,2})(?:\\.[0-9]+)?|1000(?:\\.0+)?)$"

removedInput schema / properties / max_usdc / type
```
Removed value: -"string"
```

Changed3 schema fields changedSep 20, 2026

changedInput schema / properties / max_usdc / description

Previous value: -"Optional explicit per-call USDC ceiling. The router never increases it."New value: +"Optional owner-authorized per-call USDC ceiling from 0 to 1000. Use a decimal string without a currency symbol or unit, such as '0.50', not '$0.50' or '0.50 USDC'. Omit when no spending budget is authorized; do not infer authorization from these examples. The router never increases it."

addedInput schema / properties / max_usdc / examples

Added value: +[
+  "0",
+  "0.002",
+  "0.10",
+  "0.50"
+]

addedInput schema / properties / max_usdc / pattern

Added value: +"^(?:(?:0|[1-9][0-9]{0,2})(?:\\.[0-9]+)?|1000(?:\\.0+)?)$"

First observedSep 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds critical behavioral details beyond this: 'This tool never invokes another tool, signs a payload, or spends funds.' It also states that empty calls return safe guidance rather than guessing a purchase. This provides strong transparency about side-effect-free behavior, exceeding what annotations alone convey.

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

Conciseness4/5

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

The description is long but each sentence carries meaningful information. It front-loads the core purpose and then expands on routing conditions and exclusions. No filler is present, and the structure logically flows from purpose to use cases to safety guarantees. It is slightly verbose but appropriately so given the tool's complexity.

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

Completeness4/5

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

The tool has 5 parameters, an output schema, and 20 siblings. The description covers the main routing scenarios, the conditions for each path, and the no-side-effect guarantee. It does not explicitly enumerate all sibling tools, but it provides enough routing guidance for an agent to know which path to take. The output schema exists, so return details are not required in the description.

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 the schema already documents all parameters. The description adds value by connecting parameters to the routing logic: it mentions 'wallet, Base network, and explicit budget gates' which map to wallet_enabled, network, and max_usdc. It also clarifies max_usdc is a ceiling and not spending authority. This goes beyond the schema descriptions and helps the agent understand how parameters influence routing.

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 states the tool's purpose: deterministic pre-purchase routing for Ontario tools. It specifies the verb (route), the resource (tasks across Ontario tools), and the decision outcomes (free-only, preflight, or paid). It distinguishes itself from siblings by focusing on routing before any paid tool, and explicitly notes it never invokes another tool, which is a unique differentiator.

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

Usage Guidelines4/5

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

The description explicitly says 'Use this before any paid Ontario tool' and gives clear examples of when to use it for different task types (verification, publication, refresh). It also explains the conditions for each routing path (wallet, Base network, budget gates). However, it does not explicitly name alternative tools or state when not to use it, though the context implies it is a prerequisite.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.