Ontario Protocol

Ontario Free/Paid Purchase Router

ontario_purchase_router

Read-onlyIdempotent

Free deterministic routing of one public task to Ontario's free and paid tools. Returns the matching tool and a decision (free_only, run_free_preflight, or paid_recommended with the tool's price, network and budget check). Natural endpoint-verification tasks route to the free readiness verifier, with the optional 0.002 USDC settlement-backed receipt disclosed. Provider jobs such as publishing, registering, or making an x402 endpoint discoverable route to the self-serve 0.50 USDC publication product and its free validator. Paid reads it can recommend: ontario_find-api (a live-checked paid API for a task), ontario_base-balances (Base wallet balances), ontario_base-tx-check (whether a Base transaction settled) and ontario_base-gas (current Base gas prices). Existing paid profiles route to the 0.10 USDC evidence refresh and its free refresh validator. Empty calls return task examples instead of guessing a purchase. This tool never invokes another tool, signs a payload, or spends funds.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task": "<task>"
    },
    "name": "ontario_purchase_router"
  }
}

Input 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. Send a JSON number or decimal string such as 0.5, '0.50', '$0.50' or '0.50 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 if 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

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 paid upgrade the router discloses alongside a matching free route, with the evidence it adds.
`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.

Changed2 schema fields changedOct 25, 2026

changedInput schema / properties / wallet_enabled / description

Previous value: -"True only when the caller can locally sign an x402 PaymentPayload."New value: +"True if the caller can locally sign an x402 PaymentPayload."

changedOutput schema / properties / optional_paid_upgrade / description

Previous value: -"A non-recommended upgrade disclosed after a matching free route. The caller should stop after the free result unless the stated evidence condition applies."New value: +"A paid upgrade the router discloses alongside a matching free route, with the evidence it adds."

Changed1 schema field changedOct 25, 2026

changedInput schema / properties / task / examples

Previous value: -[
-  "Verify endpoint readiness before payment",
-  "Publish my x402 endpoint as a public service profile",
-  "Refresh my existing x402 service profile",
-  "Create a settlement-backed payment decision receipt"
-]New value: +[
+  "Verify endpoint readiness before payment",
+  "Publish my x402 endpoint as a public service profile",
+  "Refresh my existing x402 service profile",
+  "Create a settlement-backed payment decision receipt",
+  "Which x402 API should my agent call for web search",
+  "Check whether a Base USDC transaction settled"
+]

Changed3 schema fields changedOct 5, 2026

changedInput schema / properties / max_usdc / anyOf

Previous value: -[
-  {
-    "pattern": "^(?:(?:0|[1-9][0-9]{0,2})(?:\\.[0-9]+)?|1000(?:\\.0+)?)$",
-    "type": "string"
-  },
-  {
-    "maximum": 1000,
-    "minimum": 0,
-    "type": "number"
-  }
-]New value: +[
+  {
+    "pattern": "^\\s*(?:[Uu][Ss][Dd][Cc]?\\s*)?\\$?\\s*(?:(?:0|[1-9][0-9]{0,2})(?:\\.[0-9]+)?|1000(?:\\.0+)?)\\s*(?:[Uu][Ss][Dd][Cc]?)?\\s*$",
+    "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 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."New value: +"Optional owner-authorized per-call USDC ceiling from 0 to 1000. Send a JSON number or decimal string such as 0.5, '0.50', '$0.50' or '0.50 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",
-  0.5
-]New value: +[
+  "0",
+  "0.002",
+  "0.10",
+  "0.50",
+  0.5,
+  "0.50 USDC"
+]

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

A3.9/5.0

Behavior4/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

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.

Ontario Free/Paid Purchase Router

Tool call template

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources