← XBuyer Blog

Let Your AI Agent Actually Buy Things: Building on XBuyer's MCP Server

XBuyer DevRel · August 2026

Most "AI shopping" today is a polite fiction. You ask your assistant for a desk lamp, and it hands you a search link and says "buy it yourself." The last mile — the actual order — is still a human clicking "Place order." In 2026, everyone is talking about agentic commerce, but the trade is bottlenecked on one missing piece: a commerce backend an agent can genuinely call, with money it can't run away with.

We built XBuyer to close that gap. It's a marketplace your agent can search, compare, add to cart, and check out from — exposed through an open Agent API and an MCP server. And the part people worry about ("what if the AI goes on a spending spree?") is solved at the architecture level, not with a disclaimer.

This post walks through the trust problem, the architecture, a 5-minute MCP integration, and exactly where the guardrails sit. No hype about next-day delivery — we'll be honest about what this is and isn't.

Why agentic commerce is stuck on trust

The tension is simple. To automate purchasing, you have to grant an agent authority to spend. But the moment you grant that authority, you worry it will spend recklessly. Surveys of consumer sentiment on autonomous purchasing put the anxiety plainly: the overwhelming majority of people want control first, delegation second, and only a small minority are comfortable letting an agent move money directly. (We cite directional industry sentiment here, not a XBuyer-conducted study — the point holds regardless of the exact number.)

The mistake most "AI shopping" products make is treating authorization as an afterthought: bolt a card on, hope for the best, add a refund policy when something breaks. XBuyer inverts that. Authorization is a first-class primitive. Three things sit between your agent and any real money:

  • Wallet isolation — the agent never touches your card. It spends from a wallet balance you fund. The card number lives only inside Stripe's KYC boundary and never enters the agent's context.
  • Per-item authorization — every purchase requires your explicit grant. You can also put the agent in "compare-only" mode, where it can research and rank forever but can never place an order.
  • Spending limits + revocation — per-order, per-day, and per-month caps; revoke access with one click; a tamper-evident log of every action the agent took.

That's the whole thesis: you set the rules, the agent executes. It's not "let AI spend your money," it's "let AI do the hunting while you keep the keys."

Architecture in one picture

 You ──(funds, sets limits, grants per order)──► Wallet
                                                    │  (balance only, never the card)
                                                    ▼
 Agent (LLM) ── MCP / REST ──► XBuyer API ──► Checkout (asks you to authorize)
                                                    │
                                                    ▼
                                              CJ fulfillment (cross-border)

The card is deliberately off this graph. The agent's only line to money is the wallet, and the wallet only moves on an authorization you approve. If the agent is compromised, the blast radius is the wallet balance and the limits you set — not your bank account.

Wire your agent in via MCP (≈5 minutes)

We ship a runnable MCP server example at github.com/angmnon/xbuyer-mcp-example. Clone it, drop in your API key and wallet id, and your agent gets five tools:

ToolWhat it does
xbuyer_search(query, budget, category)Returns candidate products with structured AI metadata
xbuyer_compare(ids[])Dimension-by-dimension comparison table
xbuyer_cart_add(id, qty)Adds to the agent's cart
xbuyer_checkout(cart_id)Triggers an authorization prompt — you approve, then the wallet is charged
xbuyer_refund(order_id)Issues a refund against a prior order

The important line is xbuyer_checkout. It does not silently charge anything. It opens an authorization request; the order is placed only after you grant it. In compare-only mode, xbuyer_checkout is disabled entirely.

A minimal agent loop looks like this (conceptual, based on the example server):

// Agent decides what to buy within a budget
const picks = await xbuyer_search({ query: "desk lamp under $40 that doesn't look cheap", budget: 40 });
const ranked = await xbuyer_compare(picks.map(p => p.id));

// Agent presents top pick and requests authorization — no charge yet
await xbuyer_cart_add(ranked[0].id, 1);
const auth = await xbuyer_checkout(cart.id); // → human approves in the UI

if (auth.granted) console.log("Order placed. Fulfillment started.");
else console.log("Agent stopped at authorization. Nothing spent.");

The agent never sees a card number, never holds a chargeable credential, and can't exceed the wallet's balance or your per-order cap.

Where the money safety actually lives

Four guardrails, in order of when they bite:

  1. Balance boundary. The agent can only spend wallet funds you deposited. There is no card behind it to overdraft.
  2. Limit boundary. Per-order, per-day, and per-month caps. An agent told to buy a $200 chair with a $40 cap is simply blocked.
  3. Authorization boundary. checkout requires your explicit grant. You can also run the agent in compare-only mode so it can never order.
  4. Revocation + audit. Revoke the agent's access anytime; every action is logged and the log is tamper-evident. Dispute a charge? The trail shows exactly what the agent did and when.

This is a spend-control plane, not a chatbot with a buy button.

A real scenario

"Here's $50. Find the two most shade-tolerant office plants under $25 each, and order them."

The agent searches 210,000+ SKUs, filters for low-light tolerance, ranks by your criteria, adds the two winners to the cart, and surfaces an authorization request. You tap approve. The order flows to fulfillment. You never opened a product page. And if the agent had tried to sneak in a third plant, the per-order cap would have stopped it.

Honest boundaries

We'd rather be trusted than impressive, so here's the fine print:

  • Delivery is cross-border, roughly 11–13 days to the US/EU after customs. We are not a two-day-delivery play. We compete on control and peace of mind, not on shipping speed.
  • Pricing is transparent: roughly cost plus a ~20% service fee. We don't claim to be the cheapest option on every item — we claim to be the one where your agent can act within rules you set.
  • EU availability is pending VAT registration (OSS/IOSS). We're not opening EU sales until that compliance is in place. Other regions: live.
  • This is not "lie back and let AI spend your money." It's "you define the policy, the agent executes it, and you can watch or revoke every step."

Try it

If you build an agent on top of this, show us what it bought. The interesting part of agentic commerce isn't the model — it's the control plane that makes letting an agent spend safe. That's what we built, and we'd love your feedback.


Published as part of XBuyer's DevRel series. All product claims above reflect the current platform; delivery windows and pricing are stated as ranges, not guarantees.