Here is the uncomfortable state of the art in agentic commerce, stated as an engineering problem rather than a marketing one. Every serious stack shipped in the last eighteen months solves payments (Stripe and OpenAI’s Agentic Commerce Protocol, Google’s AP2), identity and authorization (Visa’s Trusted Agent Protocol, Mastercard’s Agent Pay), and checkout mechanics. None of them solves the input layer. When your agent decides which wireless headphones to buy, it is almost certainly reasoning over an aggregateRating field that the seller itself published, computed over a review corpus nobody independently audited. The money layer is cryptographically verified. The merchandise layer is a rumor with a decimal point.

We covered the structural reasons for this gap earlier this week. Today is the practical follow-up: how to actually fix the input layer in your own agent, today, using the Model Context Protocol. Everything below was executed against the live GoBuy endpoint at https://gobuy.ai/api/mcp on the morning of August 26, 2026. Every response excerpt, score, and parameter is real output, lightly trimmed for length. Nothing is idealized pseudodocumentation.

Why MCP Is the Right Seam for This

If you have not worked with MCP yet, the official documentation’s analogy is the fastest on-ramp: it is a USB-C port for AI applications. An open, JSON-RPC 2.0-based standard for connecting a model to external tools and data mid-reasoning, supported natively by Claude, ChatGPT, Visual Studio Code, Cursor, and a growing list of hosts. The current specification is version 2026-07-28, and the protocol supports two transports: stdio for local servers and Streamable HTTP for remote ones. GoBuy runs the remote flavor, which means no local install, no API key ceremony for read-only evidence queries, and one URL that works from every major client.

The consequence for agent architecture is significant. Product evidence is not something you bake into a fine-tune or paste into a system prompt, because it goes stale by the hour. It is something your agent fetches at decision time, in the same context window as price and availability. MCP exists precisely for that pattern.

Connecting: Thirty Seconds, No Code

Because the endpoint speaks Streamable HTTP, wiring it into an MCP host is a configuration entry, not an integration project.

In Cursor, which documents support for Streamable HTTP servers with OAuth in its MCP configuration, add this to mcp.json:

{
  "mcpServers": {
    "gobuy": {
      "url": "https://gobuy.ai/api/mcp"
    }
  }
}

Visual Studio Code discovers MCP servers through its Extensions view and agent configuration files, with IntelliSense for the schema. Claude and ChatGPT both support remote MCP connectors through their respective connector settings. From any of these hosts, your agent can immediately call the tools below in plain conversation: “check the evidence on this ASIN before we order it” becomes a real tool invocation, not a hallucinated opinion.

The Handshake: A Server That Announces Its Epistemics

The first thing a well-built MCP client does is initialize. Here is the actual serverInfo GoBuy returned this morning, verbatim:

{
  "protocolVersion": "2025-06-18",
  "capabilities": { "tools": { "listChanged": true } },
  "serverInfo": {
    "name": "gobuy",
    "version": "1.0.0",
    "description": "GoBuy marketplace-evidence tools for agentic
      commerce. Scores describe confidence in available retailer
      signals, not product quality, safety, approval, verification,
      or a purchase recommendation. Use search_products for ranked
      marketplace evidence and get_product for documented signal
      breakdowns."
  }
}

Read that description field again, because it is doing something most tool servers never do: declaring its own epistemics. The server is telling your agent, in machine-readable English, that it is an evidence provider and not a decider. It does not claim products are good. It reports how much confidence the observed retailer signals support, with documented limitations.

This is the correct division of labor for trustworthy agents. The evidence server should never be the policy engine, and the policy engine should never invent its own evidence. Your agent’s purchasing policy (score thresholds, category rules, budget caps) belongs in your code; the verified inputs belong to a source with no position in the ranking.

Note also the version negotiation: the client proposed the 2025-06-18 protocol version and the server accepted it, even though the latest spec revision is 2026-07-28. That backward compatibility is why a tool you wire up today does not silently break when the spec moves.

The Tool Manifest: Seven Tools, Three Jobs

A tools/list call this morning returned seven tools. Grouped by function:

Discovery and evidence

  • search_products(query, max_price?, limit?) - ranked marketplace-evidence search over Amazon’s catalog, limit 1 to 10, default 5. Returns evidence, source limitations, prices, and retailer links.
  • get_product(asin) - the full documented signal breakdown for one ASIN, served from a pre-computed evidence index when available.
  • list_categories() - twenty filterable categories, from Electronics and Headphones & Audio through Pet Supplies and Baby Products.

Verification gates

  • trust_verify(product_id, retailer?, price?) - returns an evidence certificate for a single listing. The optional price argument triggers a price-integrity check against historical data.
  • trust_verify_batch(products, min_score?) - certificates for a shortlist of up to 25, designed explicitly to avoid sequential timeout risk. Products in the pre-scored index of 20,000+ popular items resolve in under 100 milliseconds each; uncached ones are fetched live in parallel.

Action

  • build_shopping_list(query, max_budget_usd?, min_trust_score?, max_items?) - curated lists drawn only from the verified trust index, which the server describes plainly: “no hallucination.” Requires a developer API key (gbk_live_...) from gobuy.ai/developers.
  • place_order(asin, api_key, notes?) - creates a purchase order on behalf of a consenting GoBuy user, enforcing permission checks against the user’s own key (gobuy_sk_...).

The three-job structure matters. Discovery narrows the space, verification gates it, and action executes under explicit user consent. Most shopping agents being built today collapse all three into one tool call that searches, decides, and buys in a single breath. Separating them is what makes the policy enforceable.

A Real Certificate, Dissected

The best way to understand the data model is to look at real output. Here is the certificate returned for ASIN B0BXYCS74H, the Sony WH-1000XM5 noise-cancelling headphones, fetched live this morning (trimmed for length):

{
  "trusted": false,
  "score": 70,
  "display_label": "Cautiously supported",
  "recommendation": "CAUTION",
  "certificate_id": "gtc_1aef69116f0e",
  "product_name": "Sony WH-1000XM5 Premium Noise Cancelling
    Wireless Headphones, Midnight Blue ...",
  "issued_at": "2026-08-26T05:01:34.335Z",
  "valid_for_ms": 14400000,
  "breakdown": {
    "wilson_score": 0.7944,
    "bayesian_verified": 0,
    "suspicion_penalty": 0,
    "ai_generated_share": null,
    "price_volatility": null,
    "seller_trust": 0.7
  },
  "thresholds": { "SAFE": 75, "CAUTION": 60, "BLOCK": 0 }
}

Six details deserve an engineer’s attention:

The Wilson score is the backbone. The wilson_score of 0.7944 is the lower bound of the Wilson confidence interval on the review signal, not a raw average. This is the scoring method Evan Miller’s classic essay “How Not To Sort By Average Rating” argued for and Reddit popularized: a product with a 4.8 average from 12 reviews should not outrank one with 4.6 from 4,000, and the Wilson lower bound enforces that arithmetic automatically. Sample size is priced in, which is precisely what raw star averages and review counts fail to do. When agents obey review counts, as the Columbia-Yale ACES audit demonstrated they do, they are obeying the cheapest signal in the ecosystem to purchase in bulk. Wilson scoring deflates bulk before your agent ever sees it.

Suspicion is a penalty line, not a vibe. suspicion_penalty is its own field. Here it is zero; when manipulation signals are present, it subtracts from the evidence score explicitly and auditably. The manipulation cost is visible in the arithmetic rather than buried in a model you cannot inspect.

Nulls are published, not hidden. ai_generated_share and price_volatility came back null for this query, meaning those signals were not available for this listing at fetch time. A server that returns documented nulls is more trustworthy than one that always returns a confident-looking number. Your policy code should treat null signals as missing evidence, and the schema lets it.

The certificate is time-boxed. valid_for_ms is 14,400,000, exactly four hours. Evidence decays; a certificate that never expires is a cache poisoning your agent’s judgment with last month’s marketplace. If your agent caches certificates, honor the validity window, and re-verify at the gate before purchase rather than trusting a stale shortlist entry.

Thresholds ship with the data. SAFE at 75, CAUTION at 60, BLOCK below. The server proposes defaults so that lightweight clients work out of the box, but the descriptions are explicit that SAFE/CAUTION/BLOCK are compatibility fields, not product approvals. You are expected to set your own policy.

trusted: false on a 70. A score of 70 lands in CAUTION, and the boolean reflects the default threshold, not a moral judgment about the Sony. The headphones may be excellent; the evidence supports cautious support, not a clean pass. That distinction is the entire product.

The Decision Gate, in Code

Here is a minimal but production-shaped pattern in Python: batch-verify a shortlist, split it by policy, and only forward clean passes toward any purchase flow. It uses trust_verify_batch precisely as intended, one call instead of N sequential ones, with the 100-millisecond cached path absorbing most of the latency.

import json, urllib.request

MCP_URL = "https://gobuy.ai/api/mcp"
HDRS = {"Content-Type": "application/json",
        "Accept": "application/json, text/event-stream"}

def call(method, params, _id=1):
    req = urllib.request.Request(MCP_URL, headers=HDRS,
        data=json.dumps({"jsonrpc": "2.0", "id": _id,
                         "method": method,
                         "params": params}).encode())
    with urllib.request.urlopen(req, timeout=30) as r:
        line = next(l for l in r if l.startswith(b"data:"))
    return json.loads(line[5:])

def gate(shortlist, min_pass=75, min_review=60):
    """shortlist: list of ASINs. Returns (auto_pass, human_review, blocked)."""
    res = call("tools/call", {"name": "trust_verify_batch",
        "arguments": {"products": [{"product_id": a} for a in shortlist]}})
    certs = json.loads(res["result"]["content"][0]["text"])
    auto_pass, review, blocked = [], [], []
    for c in certs:
        s = c["score"]
        if s >= min_pass:            auto_pass.append(c)
        elif s >= min_review:        review.append(c)
        else:                        blocked.append(c)
    return auto_pass, review, blocked

auto, human, blocked = gate(["B0BXYCS74H", "B08N5KWB9H", "B09XS7JWHH"])

Three policy rules make this gate genuinely safe rather than theater:

  1. Null-aware scoring. Treat a certificate whose key signals are null as missing evidence, and route it to human review regardless of numeric score. Confidence without coverage is decoration.
  2. Re-verify at the moment of action. The four-hour validity window exists for a reason. A shortlist built at 9 a.m. and purchased at 6 p.m. should be re-certified first, especially if price changed, since passing the current price to trust_verify triggers the price-integrity check.
  3. Never let the evidence server be the purchaser. place_order exists on the same server, but it deliberately requires the user’s own gobuy_sk_... key and enforces consent checks. Your agent’s autonomy ends where the user’s money begins; keep the buy decision behind explicit user authorization even when everything above it is automated.

What This Buys You That Scraping Stars Does Not

It is worth naming the difference between this pipeline and the naive one, because at a glance both “check reviews before buying.”

The naive pipeline ingests aggregateRating and reviewCount from the listing’s own structured data. Those fields are self-reported by the party with the strongest financial interest in their value, and the FTC has spent two years running rulemaking and enforcement precisely because manipulating them is an industry. Your agent inherits the manipulation at full strength and launders it through a confident-sounding recommendation.

The evidence pipeline replaces one self-reported number with a certificate that is third-party computed, Wilson-bounded against fake-volume gaming, suspicion-penalized where manipulation signals exist, honest about its own coverage gaps, timestamped, and expiring. The agent that consumes it is not smarter about products. It is just no longer structurally gullible, and that single property is what turns “AI shopping assistant” from a liability into infrastructure.

Ship It

The full tool schemas, the developer keys for build_shopping_list, and additional examples live in the agent documentation. The endpoint is live, read-only evidence queries need no key, and the whole integration is one URL.

Before your agent spends someone’s money again, give it something better than the seller’s own scoreboard. Start at gobuy.ai. Full integration docs and developer keys are at gobuy.ai/agent-docs.