Skip to main content
Glama

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 public profile with a signed JSON twin, 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. [PAID: 0.50 USDC via x402 on Base. Two-step flow: a call without payment returns MCP PaymentRequired; the retry carries the signed PaymentPayload in params._meta['x402/payment']. The legacy _x402_payment base64 argument is also supported. Signing happens in the caller's wallet.]

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": {
      "name": "<name>",
      "description": "<description>",
      "endpoint": "<endpoint>",
      "price_usdc": "<price_usdc>"
    },
    "name": "ontario_list-service"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesPublic service name displayed on the provider profile.
tagsNoPublic capability tags for discovery, up to ten relevant labels.
assetNoPayment token contract accepted by the provider on the declared network.
methodNoHTTP method used to call the provider's endpoint.POST
sourceNoPrivacy-safe aggregate acquisition bucket; never a URL or query.direct_or_unknown
networkNoProvider payment network, for example base or eip155:8453. Ontario publication itself uses Base USDC.base
categoryNoPublic capability category for the service, not a claim of certification.
endpointYesProvider-owned public HTTPS x402 endpoint to list. Never include secrets or sensitive query parameters.
owner_urlNoPublic website identifying the provider; publication does not verify legal identity.
price_usdcYesProvider endpoint price in decimal USDC, at most six decimal places. This is separate from Ontario's 0.50 USDC publication fee.
buyer_queryNoPublic task phrase used for the point-in-time Bazaar retrieval audit. It may appear in the public profile.
descriptionYesPublic buyer task, expected result, and important service limitations; do not include confidential text.
price_atomicNoOptional provider price in six-decimal USDC units: 10000 equals 0.01 USDC. Must match price_usdc when supplied.
_x402_paymentNobase64 x402 PaymentPayload (USDC on Base); obtain the requirements by calling this tool without it first.
owner_contactNoOptional provider contact retained for operations and omitted from public profiles. Omit when unnecessary; never send wallet credentials.
mcp_remote_urlNoOptional public MCP remote for read-only initialize and tools/list checks.
mcp_server_nameNoOptional exact MCP Registry server name.
mcp_server_json_urlNoOptional public MCP Registry record or exact-search JSON URL.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / price_usdc / description
      Previous value: -"Provider endpoint price in decimal USDC, at most six decimal places. This is separate from Ontario's 2.00 USDC publication fee."New value: +"Provider endpoint price in decimal USDC, at most six decimal places. This is separate from Ontario's 0.50 USDC publication fee."
  2. Changed1 schema field changed
    • changedInput schema / properties / price_usdc / description
      Previous value: -"Provider endpoint price in decimal USDC, at most six decimal places. This is separate from Ontario's 0.50 USDC publication fee."New value: +"Provider endpoint price in decimal USDC, at most six decimal places. This is separate from Ontario's 2.00 USDC publication fee."
  3. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Extensive disclosure beyond annotations: the 0.50 USDC Launch Passport fee, the two-step PaymentRequired-then-PaymentPayload flow, the legacy _x402_payment fallback, wallet-side signing, the 30-day freshness window, and an explicit list of what is NOT guaranteed (placement, ranking, traffic, purchases, ready grade, safety). All of this is consistent with the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), so there is no contradiction.

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?

Purpose is front-loaded in the first sentence, and the negative guarantees plus payment mechanics are in a clearly bracketed trailing block. It is dense and runs long, with some overlap between the prose and the schema field descriptions (e.g. price separation is stated twice), but nearly every clause carries actionable information.

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 mutation with an output schema already covering return values, the description supplies the missing pieces: cost, payment handshake, the two-step call sequence, signing location, freshness duration, and explicit non-guarantees. Nothing an agent needs in order to invoke it correctly appears to be 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 genuine semantics: it clarifies that price_usdc is the provider endpoint price, distinct from Ontario's 0.50 USDC publication fee, and explains how the payment argument works via params._meta['x402/payment'] with the legacy _x402_payment alternative. That materially helps an agent wire up the payment parameter correctly.

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 opening sentence gives a specific verb and resource — publish a provider-owned x402 API for agent discovery and purchase. It clearly distinguishes the paid listing/profile creation from adjacent flows like free validation and freshness maintenance, though it never names the sibling tools (e.g. ontario_validate-service, ontario_refresh-listing) that an agent should route to for those steps.

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

Usage Guidelines3/5

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

Usage is implied rather than explicit: the reader infers this is the paid publication step that follows validation and a Bazaar audit, and that it enables eventual strict Ontario discovery. There is no direct when-to-use/when-not statement or named alternative, so an agent must reconstruct the workflow from hints like 'After free validation'.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.