DEV Community

Cover image for AI shopping agents have no standard way to verify merchants — so we built one (MCP + verification API)
GenGEO
GenGEO

Posted on

AI shopping agents have no standard way to verify merchants — so we built one (MCP + verification API)

#agents #ai #api #mcp

AI shopping agents have no standard way to verify merchants — so we built one (MCP + verification API)

AI agents are beginning to make purchasing and recommendation decisions on behalf of users.

But there's a quiet infrastructure problem nobody's solved yet.

The gap

Most ecommerce trust systems were built for humans. Branding, visual design, reviews, SEO, reputation signals — all of it assumes a person is evaluating the store and making a judgment call.

Agents don't do that.

When an AI agent is tasked with finding and buying something, it's parsing structured data, operational signals, machine-readable policy indicators. It's not "feeling" trust. It's looking for signals it can interpret deterministically.

Here's the problem: there's currently no standard verification layer for this.

Imagine an agent receives:

Find me black running shoes under $200
Enter fullscreen mode Exit fullscreen mode

It might:

  1. Search products
  2. Compare pricing
  3. Evaluate policies
  4. Identify candidate merchants
  5. Potentially execute a transaction

At step 4 — how does the agent know whether a merchant is verified? Right now, it doesn't. There's no infrastructure for this. The agent is essentially guessing, or falling back to heuristics that weren't designed for agentic use.

That's the gap we're building into.

What we built

GenGEO is a machine-readable merchant verification registry, exposed via a simple API and an MCP server so agents can call it directly.

The design goal was deliberately narrow: don't build a ranking system, a recommendation engine, or a quality score. Just answer one question cleanly.

Is this merchant verified?

Binary. Deterministic. That's it.

The verification API

GET https://api.gengeo.co/api/verify?domain=example.com
Enter fullscreen mode Exit fullscreen mode

Verified merchant response:

{
  "domain": "example.com",
  "verified": true,
  "status": "active",
  "eligible_for_ai_agent_purchase": "yes",
  "decision": "verified",
  "registry": "GenGEO"
}
Enter fullscreen mode Exit fullscreen mode

Unverified merchant:

{
  "domain": "example.com",
  "verified": false,
  "status": "not_found",
  "eligible_for_ai_agent_purchase": "unknown",
  "decision": "verification_required",
  "registry": "GenGEO"
}
Enter fullscreen mode Exit fullscreen mode

Why binary, not scored?

We thought hard about this.

Scoring systems feel more informative — but they introduce ambiguity at exactly the wrong moment. If a score comes back 67/100, what does the agent do with that? It now needs a secondary decision layer to interpret what 67 means in context. That's complexity you're pushing into every agent that integrates with you.

Binary verification keeps the signal simple, deterministic, and easy to build conditional logic around:

if verified → proceed
if not verified → flag / fallback / surface to user
Enter fullscreen mode Exit fullscreen mode

Agents generally work better with deterministic inputs. We designed for that.

The MCP server

Beyond the REST API, we built an MCP server so agents can call verification directly as a tool — no HTTP plumbing required.

Tool:

verify_store(domain)
Enter fullscreen mode Exit fullscreen mode

Agent flow:

1. Agent identifies merchant domain
2. Calls verify_store(domain) via MCP
3. Receives verification status
4. Incorporates signal into decision workflow
Enter fullscreen mode Exit fullscreen mode

This matters more than it might look.

There's a shift happening in how agents interact with infrastructure. Agents are moving away from passive web browsing — discovering information through search — toward direct tool invocation. If verification infrastructure has to be discovered through search, it's fragile and inconsistent. If it's a callable tool, it's reliable, fast, and composable.

MCP changes the distribution model for infrastructure like this. Agents don't find you — they call you.

What GenGEO doesn't do

Worth being explicit about scope:

  • Does not rank merchants
  • Does not recommend merchants
  • Does not guarantee merchant behaviour
  • Does not guarantee transaction outcomes

It provides verification status only. The agent's decision logic — what to do with that status — stays with the agent. We're not trying to be the decision layer, just a signal in it.

The bigger picture

Traditional ecommerce infrastructure was built for humans discovering and evaluating stores. As agentic commerce grows, that infrastructure has an increasing mismatch with how agents actually work.

We think the category of "agent-native commerce infrastructure" is very early — and that verification is a foundational layer, not a nice-to-have. Before agents can reliably transact on behalf of users at scale, there needs to be a trust layer they can query.

What that layer ultimately looks like — whether it's centralised registries like this, decentralised protocols, something built into agent frameworks themselves — is genuinely an open question. We're not claiming to have the final answer. We're putting infrastructure up and seeing what the actual usage patterns look like.

Repo + feedback

The MCP server is open source:
👉 github.com/warwickwood-cell/gengeo-agent-registry

Would genuinely love feedback from people working on:

  • AI / commerce agents
  • MCP tooling and integrations
  • Agentic infrastructure
  • Trust and verification primitives

Specifically curious: if you're building agents that interact with ecommerce, how are you currently handling merchant trust signals — or are you not handling them at all?

This is early infrastructure for an early category. The interesting part isn't the API — it's whether the problem framing holds as agentic commerce matures.

Happy to dig into the technical design decisions in the comments.

Top comments (0)