VIA Network: Agentic Commerce

register_store

Register your own store on the VIA network (no thirdweb, no human wizard). You only need ONE wallet: your payout_wallet (USDC lands here, you keep 97.5%). The platform creates and operates your store's ERC-8004 identity wallet for you; you do not supply or hold it. The flat 2.5% network fee is unchanged. Your store is created PENDING and stays invisible until a human reviews it for quality (nothing illegal, immoral, or offensive) within 24 hours. On approval the store goes live and its ERC-8004 identity is minted. Poll get_store_status with the returned slug to track the decision.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	Yes	What you sell.
`slug`	No	Optional URL slug. Derived from store_name if omitted.
`email`	Yes	Contact email. Once approved, a sign-in link to manage the store is emailed here. There is no password.
`headline`	No	Short one-line tagline.
`store_name`	Yes	Public store / brand name, e.g. "Arc Lights".
`description`	No	What the store sells, for buyers and for review.
`website_url`	No	Existing website, if any.
`payout_wallet`	Yes	Your USDC payout EOA on Base. Sale proceeds (97.5%) settle here. This is the only wallet you need.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedAug 20, 2026

changedInput schema / properties / email / description

Previous value: -"Contact email. Becomes the dashboard login once approved; keep it."New value: +"Contact email. Once approved, a sign-in link to manage the store is emailed here. There is no password."

removedInput schema / properties / password

Removed value: -{
-  "description": "Dashboard password (8+ chars). Keep it: this is how the store is managed after approval.",
-  "maxLength": 200,
-  "minLength": 8,
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "store_name",
-  "kind",
-  "payout_wallet",
-  "email",
-  "password"
-]New value: +[
+  "store_name",
+  "kind",
+  "payout_wallet",
+  "email"
+]

First observedJul 27, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the transparency burden. It discloses that the platform creates and operates the ERC-8004 identity wallet, the store starts pending and invisible, human review is required, the fee split is 97.5%/2.5%, and approval triggers minting and a sign-in-link email.

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 several sentences long but every sentence adds distinct operational information: wallet requirements, fee, pending status, human review, approval, identity minting, and follow-up via get_store_status. There is no filler or repetition.

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?

Despite having no output schema and no annotations, the description covers prerequisites, the identity-wallet creation process, pending visibility, human review timeline, fee structure, approval behavior, and the exact follow-up mechanism (poll get_store_status with slug). This is sufficient for an agent to invoke the tool and handle the outcome.

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 meaningful value beyond the schema for payout_wallet (USDC lands here, you keep 97.5%) and email (sign-in link, no password), and it explains that the returned slug is used for status polling.

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 states a specific action: 'Register your own store on the VIA network' and clearly distinguishes this from sibling tools by focusing on self-service store creation, pending approval, and identity-wallet creation. It also clarifies what it is not (no thirdweb, no human wizard).

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?

Provides strong usage context: only one wallet is needed, payout_wallet receives USDC, the store is created pending, and the agent should poll get_store_status with the returned slug. It does not explicitly list exclusions or comparisons with alternatives, but the workflow context makes the intended use clear.

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?