VIA Network: Agentic Commerce

buy_product

Buy a listing from anywhere on the network, settled in USDC on Base, without leaving this connector. Pass the seller_mcp_url and product_id from the listing (mcp_ref). For physical products include the full delivery block; for event passes include the attendee block; the call rejects with the missing fields listed if any are blank. Free passes are not bought here: use claim_pass. Returns the total, an order_ref and a pay_url. SIMPLEST, for VIA and network-member listings alike: if you hold a standard x402 wallet (MoonPay PayBox: call use_service with url = pay_url; or any exact-scheme x402 client), request pay_url and pay its 402; the order settles and is fulfilled in that one call, gas sponsored. Otherwise: VIA-native orders settle at the /api/x402/purchase endpoint returned (EIP-2612 permit as { order_ref, x_payment }, or a raw USDC transfer as { order_ref, payment_tx_hash }); member orders take a raw USDC transfer then confirm_purchase. Call get_shipping_quote first and pass buyer_country to include shipping. CARD: when the reply carries card_checkout_url the store takes card payments; if you act for a human with no USDC wallet, give them that link to pay by card themselves. Never ask for or handle card details. Physical network-member listings: pass delivery; the first call returns shipping options, call again with shipping_rate_handle set to the one you chose.

Input Schema

Name	Required	Description
`qty`	No
`attendee`	No	Required for event passes.
`delivery`	No	Required for physical products. Omit for digital / service.
`product_id`	Yes	The listing id from discovery (mcp_ref.product_id).
`buyer_email`	No	Network-member orders: email for the order confirmation and file delivery. Required for physical member products.
`buyer_wallet`	Yes	The buyer wallet that will settle in USDC on Base.
`buyer_country`	No	ISO 3166-1 alpha-2 destination country. Required when the seller ships; folds the shipping quote into the total.
`selected_size`	No	Variant size, for network-member products that have a size axis (e.g. S, M, L). Ignored by VIA-native listings.
`buyer_agent_id`	No	ERC-8004 agent id of the Buying Agent acting on the buyer's behalf.
`selected_color`	No	Variant colour, for network-member products that have a colour axis. Ignored by VIA-native listings.
`seller_mcp_url`	Yes	mcp_ref.seller_mcp_url from a find_seller / get_seller_products result.
`shipping_rate_handle`	No	Network-member physical products only: the shipping option handle from a previous buy_product call. Omit on the first call to get the options.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 5, 2026

addedInput schema / properties / buyer_email

Added value: +{
+  "description": "Network-member orders: email for the order confirmation and file delivery. Required for physical member products.",
+  "format": "email",
+  "type": "string"
+}

addedInput schema / properties / shipping_rate_handle

Added value: +{
+  "description": "Network-member physical products only: the shipping option handle from a previous buy_product call. Omit on the first call to get the options.",
+  "type": "string"
+}

First observedJul 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and delivers substantial non-obvious behavior: settlement in USDC on Base with sponsored gas, rejection when required blocks are blank with the missing fields listed, the 402/pay_url settlement path, and the card_checkout_url fallback. It even warns never to handle card details.

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 content is dense but nearly every sentence carries load for a genuinely complex multi-path flow, and the purpose is front-loaded. The caps labels (SIMPLEST, CARD) provide some structure, though the single long paragraph could be broken up for readability.

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 a 12-parameter, multi-step purchase tool with no output schema, the description covers all decision paths (x402 wallet, VIA-native, member, card) and even describes the return values (total, order_ref, pay_url). Nothing an agent needs to invoke it correctly appears 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 92%, so the baseline is 3 and the schema already documents the parameters. The description still adds usage meaning beyond the schema: seller_mcp_url/product_id come from mcp_ref, delivery/attendee are conditional on product type, buyer_country folds in shipping, and shipping_rate_handle requires a prior call.

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?

States a specific verb and resource with scope: 'Buy a listing from anywhere on the network, settled in USDC on Base.' It also distinguishes itself from siblings by explicitly excluding free passes ('use claim_pass'). An agent can identify the operation without opening the schema.

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?

Gives explicit routing and sequencing: use claim_pass for free passes, call get_shipping_quote first, pass delivery vs attendee blocks by product type, and the two-call shipping_rate_handle flow. It also names alternative payment paths (use_service, confirm_purchase) with their deciding conditions.

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

All VIA Network: Agentic Commerce 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.

Resources

Need Help?