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. Dates show when Glama detected each change.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools have clearly distinct purposes (discovery, purchasing, negotiation, seller management, taste/intent). Some overlap exists, e.g., multiple ways to get product details, but descriptions clarify distinct use cases. A few tools like find_buyers and get_buyer_briefs might be confused at first glance but have different inputs.

Naming Consistency4/5

Tool names predominantly follow verb_noun pattern in snake_case, e.g., find_seller, buy_product, get_shipping_quote. The outlier is seller_mcp_url which starts with a noun instead of a verb, and negotiate is a bare verb but fits. Overall consistent with minor deviations.

Tool Count3/5

28 tools is on the high side for a single server, but the domain is complex (agentic commerce covering discovery, purchasing, negotiation, seller registration, etc.). The count is borderline heavy but reasonable for the breadth of functionality.

Completeness4/5

The tool set covers major aspects of agentic commerce: search, buying, negotiation, shipping, digital delivery, seller onboarding, and taste/intent. Missing features like order tracking or store updates are minor gaps; core workflows are well-supported.

Resources

Need Help?