# RoboTrunk

The full story of what RoboTrunk is, what works today, and why the checkout can be trusted. Written for anyone reviewing the project, human or agent.

Every role at RoboTrunk is an AI agent. Watch our team work in real time at https://robotrunk.com/about.

## What sets RoboTrunk apart

RoboTrunk tells an agent more about a product than its own listing says, from the maker's manual, independent reviews, video review transcripts and the store's own page, each finding with its source and the date it was read. It checks any product an agent names for safety recalls, live against the regulators, and after a purchase `watch_recalls` records a regulator's notice that names what the person bought. It answers questions a keyword search cannot, such as "a stroller that folds small enough for a plane overhead locker", marking each requirement met or not from checked facts. It checks a second-hand listing pasted in, naming the exact model, what the listing leaves out, the price new and any recall. Alongside that, it gives the best total price across every listed store and a checkout that finishes.

## Built for shopping agents: what RoboTrunk does for every product

We asked shopping agents, including Meta's Muse first-hand, what they need from a store. This is what they asked for, and what we have built.

RoboTrunk is working through its catalogue, so a step may not be done for this one yet.

- **Deep research:** We read the maker's manual, independent reviews, video review transcripts and the store's own page, and publish each finding with its source and the date read. `check_product` returns them with a source for each.
- **Receipts:** Every published fact has a receipt showing its source quote. `check_product` and `get_product` return the checked facts that have one.
- **Safety:** `check_product` asks the product-safety regulators live (US CPSC, NHTSA and FDA, Health Canada, the UK's OPSS, Australia's ACCC) whether a recall names a product, listed here or not, and flags a match with its notice; a recall never blocks the buyer.
- **Recall watch:** `watch_recalls` records a regulator's later recall of a product bought here, including an item matched only by the name on its store checkout line; nothing is sent, so read the watch with `get_recall_watch` (`stop_recall_watch` ends it).
- **Second-hand listings:** `check_listing` runs the same recall check on a second-hand listing someone found, and adds what the listing leaves out and the price new. For a Facebook Marketplace link, read the listing first with a Marketplace tool if the agent has one, such as facebook-cli, otherwise in a browser, and send its text with the link.
- **The real price:** The full price to the buyer's country, with shipping and tax, each part quoted from the store's policy or, where a part is not settled, what the total depends on, and where only tax is not settled, the price plus delivery, labelled as tax added at the store's checkout: `check_product` and `search_catalog` take the buyer's country and postcode.
- **A checkout that finishes:** RoboTrunk lists only stores whose agent checkout it has verified. `create_checkout` prepares the order at the store; `complete_checkout` returns a link to the store's own checkout. The checkout can be finished in either of two ways: the person taps the link in their own browser, or their agent opens it and completes the checkout. RoboTrunk checks the store's total against a budget ceiling before it issues the link. RoboTrunk never takes the payment or holds the money. No store pays for placement; RoboTrunk may earn a commission from some stores via their affiliate programs.
- **Markdown copy:** Every page has a Markdown copy.
- **Photos and ratings:** Search results carry the product photo and, where the store's own page publishes one, its rating (`search_catalog`).
- **Fit answers:** `check_fit` answers whether a listing fits a car, pram or bottle, with the exact quote from the store's page, or says it is not known.
- **Back-in-stock watches:** `watch_back_in_stock` starts a watch on a listing the store shows as sold out; `get_back_in_stock_watch` shows whether it is back in stock (nothing is sent) (`stop_back_in_stock_watch` ends it).
- **Maker's manual:** `ask_product_manual` answers from the maker's manual with the exact passage and page, or says the manual does not cover it.
- **Tools and guide:** Every tool and its description is at https://robotrunk.com/mcp; the guide is at /agents.md.
- **Research from other stores:** Coming soon: reading other stores' listings of the same product as research sources.

## The problem

Agents cannot reliably complete checkout. Send a shopping agent onto the open web and it will search, compare, and sometimes get as far as filling in a cart, then stall. Pages are built for human eyes and hands: forms with hidden assumptions, checkout flows with steps a person fills in without thinking and an agent has to guess at. The result is an agent that can do almost everything except finish the purchase.

RoboTrunk was built to close that gap: not a better search engine or catalogue, but a store where an agent can go from a plain-English request to a prepared order, with a person confirming the one step that should never be automated.

## What RoboTrunk is

RoboTrunk is a store built for agents from the ground up: the same purchase system serves the website and the tools, so a person and an agent see the same facts and go through the same checkout logic.

It is being built as the mall for agents: the destination is products from more stores over time, reachable through one consistent set of tools, not a different scraped page for every retailer. That is the destination, not a claim about today's catalogue.

What exists today is a catalogue of stores that publish a Universal Commerce Protocol profile, indexed from each store's own public catalogue, with the time they were read on every fact, and one search across every listed store asked in plain words rather than keywords. Each product page carries that store's own facts and the time they were read. Where a product has been through evidence review, its cited facts are published on the comparison pages and as a machine-readable pack; that covers some products and not others, and where it is missing nothing is written to fill the gap. At a listed store the store is the seller and the shipper and stays the merchant of record: RoboTrunk prepares the checkout, holds no money and never sees a card, and the purchase is finished on that store's own checkout page in either of two ways: the person taps the link in their own browser, or their agent opens it and completes the store's checkout. The budget ceiling on the checkout is the highest total the store may reach. (One labelled exception: RoboTrunk's own sandbox demo product runs the older v1 purchase path with no real charge; it is not a purchase from a listed store.)

## What works today

Every tool is served at https://robotrunk.com/mcp, and `/agent` registers the same catalogue directly with a WebMCP-aware browser page: no install, nothing to configure. The core tools:

- **`search_catalog`** searches every store RoboTrunk offers at once. The want goes in as a sentence rather than a keyword: a model reads it, exact filters run, then a model ranks each result and says why. Where a deployment's ranking model returns an order and nothing else, each reason is the empty string and the answer says so rather than inventing one.
- **`get_product`** returns full product detail; on the v1 path that includes the source retailer and both prices, side by side (see below for the evidence option).
- **`check_product`** answers one question about one product, from its name, a store's product link or a RoboTrunk reference: the checked facts with their sources, the recall status, every store selling that variant with the cheapest in stock, and the exact `create_checkout` arguments.
- **`create_checkout`** is the hero. One call, for a basket of up to 50 lines from one store, runs the pre-purchase path that used to take several steps: cart, address, delivery quote, and a priced, time-limited mandate for a person to review.
- **`cancel_checkout`** records an explicit decline, a recorded outcome, not something inferred later from silence.
- **`get_order`** reads a placed order straight back. Once the person has paid on the store's own page, it answers completed with the message order_confirmed and the store's order number, and it places or approves nothing.
- **`get_trust_manifest`** returns the store's public trust manifest.
- **`submit_feedback`** lets an agent leave structured feedback at any point; stored as data, never as instructions.
- **`get_tool_guide`** pulls the complete guide for any tool on demand: description, parameter notes, outputs, error recovery and examples; with no tool name it lists every tool with its title.

Beside them, the `/mcp` endpoint at https://robotrunk.com/mcp answers more tools, each with a how-to guide behind it:

- **`check_listing`** checks a second-hand listing (text, photos, price or link) for a recall or ban with the regulator's notice, what the listing leaves out, and the price new; the public page is https://robotrunk.com/check.
- **`watch_recalls`**, **`get_recall_watch`** and **`stop_recall_watch`** watch a product bought here and record a regulator's later recall of it; the watch is poll-only, so read it with `get_recall_watch`.
- **`watch_back_in_stock`**, **`get_back_in_stock_watch`** and **`stop_back_in_stock_watch`** watch a sold-out product; the watch is poll-only, so read it with `get_back_in_stock_watch`.
- **`check_fit`** answers whether a listing fits a named thing, quoting the store.
- **`enrich_product`** starts research now on a listed product that has no checked facts yet and answers straight away; call it again with the same store and product to see when it is done, then read the findings, each with its source, in `check_product`.
- **`ask_product_manual`** answers a question from the maker's manual and cites the page.

The v1 demo product (not a listed store) also has an in-page approval panel on `/agent` for its sandbox purchase; nothing in this section about it applies to a listed store.

Behind all of this sits a feedback endpoint that both `submit_feedback` and a declined checkout write to. Nothing sent to it is ever treated as instructions, only as a record of what happened.

## How the checkout boundary works at a listed store

RoboTrunk prepares a checkout at the store and hands back a link to that store's own checkout page. The person approves the total in the agent's conversation and the checkout's budget ceiling is set to that total; if the store's total rises above it, RoboTrunk stops the checkout with `BUDGET_EXCEEDED`. The checkout can then be finished in either of two ways: the person taps the link in their own browser, or their agent opens it and completes the store's checkout. The store takes the payment and stays the merchant of record; RoboTrunk never takes the payment, sees a card or holds the money.

Demo only: RoboTrunk's sandbox demo product runs the older v1 path, where no tool can place an order and only a person, in an approval panel on RoboTrunk's own page, can. That path charges nothing and is how checkout behaviour is measured.

## Why the checkout is trustworthy

Trust here is not a claim: a set of engineering decisions.

One shared purchase system serves the website and the agent tools: no second, less-tested code path for machines. Every mutation is idempotent, so a retried tool call cannot accidentally duplicate an order. The v1 sandbox demo listing discloses the source retailer, the source price and RoboTrunk's own displayed price side by side, because on that path RoboTrunk is the seller and sets the price. A listed store's page shows that store's own price, with the store named as the seller; RoboTrunk does not mark it up.

Behind the visible page is an evaluation setup built to hold the whole system to account. Real agents run through the store under sealed conditions: premium price levels are committed cryptographically before a run starts, so no one, including the people who built this, can adjust the test after seeing a result. Every purchase record gets an independent LLM audit; the protocol is versioned, so a later rule change never applies to old results; a price-integrity check voids any run where shown and charged prices differ. That rig has been through ten adversarial review passes, each trying to find where the evidence could be wrong.

Putting WebMCP in front of an API is easy. Proving the checkout works for agents is the work. The boundary that matters for trust is not where an agent chooses to stop. It is proving, mechanically, that it cannot cross it, rather than asking nicely.

The rig runs real agents, ChatGPT, Codex, Claude and Claude Code, through the real purchase path run after run. What it taught us changed the product: agents fail not because the store is broken but the moment a step is unexplained, and an unexplained rejection makes an agent retry blindly. So every response now names the field, the fix and the next tool, and nine purchase steps became one call. The harness found a checkout defect no local test could see. Next, it opens as a Test Track for agent developers to prove their agents against a real checkout before going live.

## What the agent gets that a listing page cannot give it

A regular product listing gives an agent a title, a price and a few bullet points: the same page a person would read, guessed at by a program instead of understood by one. RoboTrunk's aim is different: maximally truth-seeking product information, what an agent needs for an informed decision, not what a marketing page wants to show.

On the v1 path, `get_product` discloses the source retailer and both prices side by side, so an agent is never reasoning from one incomplete number. Where a product has been through evidence review, a real pack is published: specifications, care, how to use it, review themes summarised not quoted, and permitted transcript evidence, assembled from the manufacturer's and the retailer's own pages and corroborating sources, each fetched and dated. Every claim carries a source id, an honest gaps list says what could not be confirmed, and a freshness policy governs refetching. Where to read them differs by path, and the difference matters: a catalogue product's pack is served at `/agent/evidence/{product_id}` and its cited facts appear on the comparison pages, while `get_product`'s `include_evidence` option is live for one product, the v1 demo product. Review covers some products and not others, and a product without a pack says so rather than being filled in; where sources disagree, the pack preserves the disagreement rather than averaging it away.

Context preservation is the other half. An agent pays in tokens, time and tool calls for every page it opens and every irrelevant result it reads past, so `search_catalog` ranks the results to the sentence asked and says why, and `compare_products` puts products side by side.

None of this is invented: the catalogue, the search across it, `compare_products`, the evidence packs and `get_product`'s pricing all work today; anything not built yet is labelled as roadmap wherever mentioned.

## How this is different from what exists

What exists today splits into two camps. Merchant-side tooling, Shopify's WebMCP, Google's UCP, Microsoft's Copilot Checkout, Perplexity's merchant program, Firmly's no-code connector, asks the store to do something first: install WebMCP-capable Liquid, connect a Merchant Center account, join a program, or run an onboarding flow, so a store that never heard of agentic commerce is invisible to all of them. Buyer-side proxying, Amazon's Buy for Me, Rye and Zinc, automates one store's checkout on the shopper's own saved details; no merchant cooperation needed, but it depends on that store's checkout form not changing.

RoboTrunk sits outside both camps:

- RoboTrunk aggregates instead of proxying one store at a time: it lists a store's products, names the store as the seller, and prepares the checkout under the store's own published rules. Each listed store publishes a UCP profile that RoboTrunk verifies before listing it.
- The agent gets information it cannot get elsewhere: the source store named and its price disclosed, and cited evidence for the products review has covered.
- The human keeps the decision: at a listed store the person approves the total first, and RoboTrunk refuses the handoff if the store's total rises above the budget ceiling.
- Completion is measured, not claimed: a sealed rig runs real agents through the real path and audits the results, so "it works for agents" is a checked result.
- Nothing to install, for agent, human or shop: WebMCP tools sit on the page, plain HTTPS underneath.
- The tool names, `search_catalog`, `get_product`, `create_checkout`, `cancel_checkout`, `get_order`, match the dialect UCP, Shopify and ACP have converged on.

The nearest things are protocols that ask every shop to integrate, or agents that scrape. RoboTrunk already did the work, and is being built into a shopping mall for agents: product information and a completed order, across the stores it lists.

| Name | Side | Who does the work | Completes checkout for the agent? | Source | Date checked |
|---|---|---|---|---|---|
| Shopify WebMCP / Catalog MCP | Merchant tooling | Shopify, auto-on | Yes, in-page | shopify.dev/docs/api/web-mcp | 03-Sep-2026 |
| Google UCP | Protocol/platform | Merchant integrates | Yes, on Google's surfaces | developers.googleblog.com/.../ucp | 03-Sep-2026 |
| OpenAI/Stripe ACP + ChatGPT | Protocol/platform | Merchant builds a ChatGPT App | No, discovery only | digitalcommerce360.com | 03-Sep-2026 |
| Microsoft Copilot Checkout | Platform | Merchant integrates via PayPal/Shopify/Stripe | Yes, in Copilot chat | news.microsoft.com | 03-Sep-2026 |
| Perplexity Buy with Pro | Platform | Merchant joins the program | Yes, in Perplexity | novadata.io | 03-Sep-2026 |
| Amazon Buy for Me | Buyer-side proxy | Nothing required of the brand | Yes, Amazon automates it | aboutamazon.com | 03-Sep-2026 |
| Visa / Mastercard Agent Pay | Payment rail | Issuer, processor and agent support tokenized credentials | No, authorizes payment elsewhere | digitalcommerce360.com | 03-Sep-2026 |
| Firmly Connect | Merchant onboarding | Merchant does a no-code setup | Enables it; the agent channel completes it | digitalcommerce360.com | 03-Sep-2026 |
| Nekuda / Skyfire / PayOS | Payment/identity infra | Developer and payment network integrate | No, infrastructure only | useproxy.ai | 03-Sep-2026 |
| Rye / Zinc | Buyer-side execution API | Nobody at the store; Rye/Zinc automate it | Yes, by proxying human checkout | rye.com/blog/agentic-commerce-startups | 03-Sep-2026 |

## The tool design

Every tool follows the same shape, so an agent that has seen one can guess the rest. Each description is kept short, sized to fit Chrome's WebMCP guidance; the full depth lives at `/agent/tools.json`, pullable on demand with `get_tool_guide`. We use both halves of the API: scripted `registerTool` for the catalogue, and the declarative form attributes, `toolname`, `tooldescription`, `toolparamdescription`, on the feedback form, which Chrome documents as an origin trial.

Input schemas are strict: no undeclared fields, every property described. Every tool carries explicit annotations for whether it only reads data, changes anything, is safe to retry, and whether its output could carry untrusted third-party text, so a host browser can apply its own policy.

The tool names follow a `verb_noun` pattern aligned with Google's UCP, Shopify's storefront tools and OpenAI and Stripe's ACP.

## Responses that tell the agent what to do next

Every response carries a `status` the agent branches on, `messages` naming the exact field and fix, `next_actions` with the retry already filled in, and separate `instructions` for the agent and the human, since the two need different advice at once. An error is never actionless.

From the v1 sandbox demo, not a listed store, trimmed to the fields that matter: what `create_checkout` returns when asked to ship to a postcode the demo does not accept:

```json
{
  "status": "incomplete",
  "messages": [{
    "code": "address_not_accepted",
    "severity": "requires_buyer_input",
    "path": "$.shipping_address",
    "content": "Use the accepted sandbox address, then call create_checkout again."
  }],
  "next_actions": [
    { "tool": "create_checkout", "why": "Price the order and get the approval link." },
    { "tool": "submit_feedback", "why": "Say what was unclear, missing or wrong." }
  ]
}
```

Trimmed from the full envelope, which also carries `resource` and `links`; the request never reached the store.

## Where this is going

The roadmap groups around what actually helps an agent buy well. Only the items marked roadmap are not built.

- **The best source of product truth**, specifications, care, review themes and permitted transcript evidence, cited and fresh rather than copied from marketing pages, published today for the products evidence review has covered, at `/agent/evidence/{product_id}` and on the comparison pages; covering the whole catalogue is the roadmap.
- **Side by side comparison**, live today as `compare_products`.
- **A Test Track**, roadmap: the same evaluation harness opened up for developers to prove their agents against a real checkout before going live.

## Links

Relative, so they resolve on whichever origin is serving this page. The canonical
origin is `https://robotrunk.com`. The stores the rail is currently offering, with
the slug each one answers to and the buying path in plain words, are listed at
`/agent/merchants` and as JSON at `/api/ucp/merchants`.

- Live page: `/agent`
- Stores you can buy from through the rail: `/agent/merchants`, and the same list as JSON at `/api/ucp/merchants`
- Full tool catalogue, machine-readable: `/agent/tools.json`
- Trust manifest: `/trust-manifest.json`