Ontario Protocol

Publish your x402 API for agent discovery

ontario_list-service

Publish a provider-owned x402 API so AI agents can discover and buy it. After free validation and a Bazaar buyer-intent audit, the 0.50 USDC Launch Passport creates a signed public HTML/JSON profile, readiness and Coinbase indexing evidence, a five-query retrieval snapshot, badge, copy-ready MCP/catalog records, and 30 days of freshness maintenance. It can become eligible for strict Ontario discovery when evidence is ready and fresh. It does not guarantee Coinbase placement, ranking, traffic, purchases, a ready grade, or safety. Agent payment guidance: run free can-pay and readiness checks first; pay only when policy allows base 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 and 0.50 USDC is inside the agent budget. [PAID: 0.50 USDC via x402 on Base. Two-step flow: call without payment to receive MCP PaymentRequired, then retry with params._meta['x402/payment'] containing the signed PaymentPayload. The legacy _x402_payment base64 argument is also supported. Sign only after explicit budget and policy approval.]

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Public service name displayed on the provider profile.
`tags`	No	Public capability tags for discovery, up to ten relevant labels.
`asset`	No	Payment token contract accepted by the provider on the declared network.
`method`	No	HTTP method used to call the provider's endpoint.	POST
`source`	No	Privacy-safe aggregate acquisition bucket; never a URL or query.	direct_or_unknown
`network`	No	Provider payment network, for example base or eip155:8453. Ontario publication itself uses Base USDC.	base
`category`	No	Public capability category for the service, not a claim of certification.
`endpoint`	Yes	Provider-owned public HTTPS x402 endpoint to list. Never include secrets or sensitive query parameters.
`owner_url`	No	Public website identifying the provider; publication does not verify legal identity.
`price_usdc`	Yes	Provider endpoint price in decimal USDC, at most six decimal places. This is separate from Ontario's 0.50 USDC publication fee.
`buyer_query`	No	Public task phrase used for the point-in-time Bazaar retrieval audit. It may appear in the public profile.
`description`	Yes	Public buyer task, expected result, and important service limitations; do not include confidential text.
`price_atomic`	No	Optional provider price in six-decimal USDC units: 10000 equals 0.01 USDC. Must match price_usdc when supplied.
`_x402_payment`	No	base64 x402 PaymentPayload (USDC on Base); obtain the requirements by calling this tool without it first.
`owner_contact`	No	Optional provider contact retained for operations and omitted from public profiles. Omit when unnecessary; never send wallet credentials.
`mcp_remote_url`	No	Optional public MCP remote for read-only initialize and tools/list checks.
`mcp_server_name`	No	Optional exact MCP Registry server name.
`mcp_server_json_url`	No	Optional public MCP Registry record or exact-search JSON URL.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the 0.50 USDC paid requirement, the x402 two-step flow, 30-day freshness maintenance, and explicit non-guarantees about Coinbase placement, ranking, traffic, purchases, readiness, and safety. No statement contradicts 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.

Conciseness5/5

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

The description is organized into clear sections: main action, deliverables, eligibility, limitations, and payment guidance. It is dense but every sentence earns its place, and the most important purpose statement is front-loaded.

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?

For an 18-parameter, paid, non-idempotent publication tool, the description covers prerequisites, fee, payment mechanics, outputs, eligibility, limitations, and agent payment policy. The rich schema and output schema handle remaining parameter-level detail, so nothing essential is missing.

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, but the description adds meaningful payment semantics: the two-step call-without-payment flow, params._meta['x402/payment'] containing the signed PaymentPayload, and legacy _x402_payment base64 support. This goes beyond the schema's field-level 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?

Opens with a specific verb-resource pair: 'Publish a provider-owned x402 API so AI agents can discover and buy it.' It then details concrete outputs such as a signed public HTML/JSON profile, readiness evidence, badge, and MCP/catalog records, clearly distinguishing publication from validation or refresh sibling tools.

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?

Gives explicit sequencing: run free can-pay and readiness checks first, pay only when policy allows, and retry with a signed PaymentPayload after receiving MCP PaymentRequired. It does not explicitly name sibling alternatives, but the context makes the when-to-use conditions clear.

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.