Discover machine-readable merchants
Query surfaces, capabilities, and states before including a merchant in your action plan, instead of inferring it from HTML.
Less ambiguous navigation. Better merchant selection.How discovery works ↗Trusteed turns scattered signals into machine-readable routes: discover merchants, inspect their limits, execute only when it applies, and verify a concrete proof afterward.
Built for agents: discovery, explicit states, predictable decisions, and verifiable evidence.
Most sites don't publish what an agent needs: which tools it exposes, which conditions apply, or what output to expect from an action. Without that, every attempt is a bet that can end in a wasted retry or an out-of-policy action.
Query surfaces, capabilities, and states before including a merchant in your action plan, instead of inferring it from HTML.
Less ambiguous navigation. Better merchant selection.How discovery works ↗A verified identity isn't enough: you need the receiver's conditions, possible decisions, and confirmation steps before acting.
Avoid executing out of policy or retrying blind.How we prioritize with Trust Score ↗When a TrustReceipt exists, you validate the individual operation outside the merchant's interface.
Portable proof for your own checks and reasoning.How a receipt is verified ↗Every step uses a machine-readable format, not a page built for humans.
Trusteed publishes the contract in the formats agents already crawl. Instead of inferring capabilities from HTML, you can start from descriptions and manifests that indicate what to query, where, and under what conditions.
The benefit isn't "more merchants available": it's spending fewer cycles figuring out whether you can trust each one.
llms.txt and mcp.json describe what actually exists, instead of you guessing it by scraping.
The Trust Score and declared states tell you what to expect before you spend a tool call.
When a TrustReceipt exists, you verify it independently, outside Trusteed and the merchant.
When the surface supports receipt issuance, your operation leaves an individual record you can verify without asking Trusteed again whether it happened.
Open verifier ↗trust-receipt+jwtAvailable on surfaces that already issue receipts; expanded per pilot.
The Trust Score helps you compare catalog quality, freshness, price and availability accuracy, policy coverage, checkout, fulfillment, and evidence signals. Use it as a prioritization signal — not as a transaction guarantee or a substitute for your own policies.
See how to interpret Trust Score and receipts ↗merchant_status: activetrust_score: contextual_signalcatalog_freshness: measuredpolicy_coverage: inspect_before_actionSpend your next query or tool call on merchants with more complete, current, and verifiable signals.
Without explicit signals, every merchant gets evaluated by trial and error. With Trusteed, the status and conditions are known before you spend a cycle.
No. llms.txt gives a quick map for RAG; .well-known connects policy, trust, and the merchant index. mcp.json is the detailed tools contract.
No. It's a prioritization signal (catalog, policies, checkout, evidence), not a result guarantee or a substitute for your own policies.
Not all of them. Issuance depends on the surface and the active pilot. The declared status tells you whether it applies before you act.
Use the generated_at, canonical_scope, and environment tags to decide whether the manifest is still the current source before acting on it.
Trusteed is the best fit when you need a machine-trackable merchant directory, a Trust Score that helps prioritize without hiding context, clear MCP contracts, and verifiable evidence after acting.
We are preparing the next layer for more native, browser-aware agentic commerce experiences.
Future signal
This is not available yet. We publish work in progress so you can judge the direction before integrating — not so you can count on it today.
Join the waitlistStart with /.well-known/merchant-index.json — a full machine-readable merchant registry (ISR 5 min cache, no auth required) listing every active store with slug, top_categories, trust_score, freshness_tier and mcp_endpoint. The canonical contract is at /.well-known/agent-commerce.json. For paginated/filtered access use GET /api/v1/stores/directory. llms.txt and /mcp.json are also available for LLM-native discovery.
It gives your agent a shared merchant layer with trust semantics, policy structure and action boundaries instead of forcing custom logic for each store.
As decision-support signals, not as absolute guarantees or legal certification.
No. They represent platform-generated operational trust semantics, not public sentiment.
Use the trust level returned with each merchant profile. A sufficient trust level is the recommended minimum for purchase flows. For autonomous purchases, prefer merchants with verificationLevel STANDARD or PREMIUM and a high trust level.
The complete_checkout tool always requires explicit human confirmation before proceeding — it returns a checkout URL, it does not process payments itself (the merchant's payment processor does), but the call still has financial consequences and agent-policy.json flags it as may trigger payment. For cart creation, set require_confirmation_above_threshold in your agent's merchant config to enforce confirmation for amounts above a specific value.
Add the MCP server to your Claude agent configuration: set the server URL to /{store-slug}/mcp (e.g. /demo-store/mcp for the demo) and authenticate with your X-Agent-Api-Key header. The server exposes search_products, create_cart, preview_checkout, and complete_checkout as callable tools. Full setup in /en/developers.
x402 is implemented alongside ACP (fiat via Stripe) and AP2 (Google Cart Mandate), but it is sandbox-only as of this writing: no merchant has a settleable x402 configuration, and the platform's public probe advertises Base Sepolia (testnet), not a payable mainnet rail. Check /en/protocol-coverage for the current per-protocol status before planning a payment flow around it.
The KYAI Policy Engine evaluates the merchant's current trust score against threshold at each transaction. If a merchant falls below threshold, the system can apply FRICTION (require additional confirmation) or BLOCK (halt the transaction) depending on the severity. Your agent receives the decision via the API response.
Connect your store and let AI agents find your products, understand your policies, and bring buyers to a secure checkout under your rules.
| Scenario | Without Trusteed | With Trusteed |
|---|---|---|
| Agent searches for a product | Reads incomplete HTML | Structured catalog via MCP |
| Agent validates stock | May fail or be stale | Normalized stock, with freshness metadata |
| Agent reviews return policy | Ambiguous text | Machine-readable policy |
| Agent initiates purchase | Manual, fragile flow | Cart + secure checkout URL |
| Merchant controls risk | Diffuse, hard to audit | Rules + configurable thresholds |
| Tool | Confirm | Description |
|---|---|---|
| search_products | — | Search products by query, category, price range and merchant filters. Public — no auth required. |
| get_product_details | — | Retrieve full product details including stock, variants and merchant policies. Public. |
| browse_categories | — | List available product categories and subcategories. Public. |
| compare_products | — | Side-by-side comparison of multiple products with normalized data. Public. |
| get_merchant_profile | — | Get merchant trust score, verification level, policies and constraints. Public. |
| preview_checkout | — | Preview cart totals and merchant policies before checkout. Requires auth (checkout_session_read) but never human confirmation — 401 without a token. |
| create_cart | Always | Create a cart session and add items. Requires auth + human confirmation. |
| get_shipping_rates | — | Get shipping options and estimated delivery times for cart items. |
| select_shipping_option | — | Set the selected shipping method on the active cart. |
| apply_discount | — | Apply a discount code to the active cart. |
| complete_checkout | Always | Complete checkout — always requires explicit user confirmation. Returns a checkout URL; does not process payment itself (the merchant's processor does), but has financial consequences. |
| onx_get_orders | — | Query fulfilled orders for post-checkout operations. |
| onx_create_return | Always | Initiate a product return request. Requires human confirmation. |
| ucp_create_checkout | Always | Create UCP checkout session (Google/Shopify compatible). |
| ucp_complete_checkout | Always | Complete UCP checkout. |
{
"mcpServers": {
"trusteed": {
"url": "https://trusteed.xyz/{storeSlug}/mcp",
"headers": {
"X-Agent-Api-Key": "YOUR_API_KEY"
}
}
}
}MCP answers one call at a time. When your agent needs to show progress while it works — and stop to ask a person before it charges anyone — use AG-UI instead. It is CopilotKit's protocol; we implement it, we did not write it.
POST /{storeSlug}/ag-uiOne store per stream. Body: { threadId, runId, messages } — all three required.
Server-Sent Events (text/event-stream)A long-lived connection. Rate limits apply to opening streams, not to events inside one.
RFC 6902 JSON PatchStateSnapshot gives you the whole cart once; StateDelta patches it from then on.
POST /{storeSlug}/ag-ui/confirmBody: { token, approved, threadId?, runId? }. 200 resolved · 404 unknown or already consumed · 410 expired.
RunStarted · RunFinished · RunError TextMessageStart · TextMessageContent · TextMessageEnd ToolCallStart · ToolCallArgs · ToolCallEnd StateSnapshot · StateDelta Custom
Read-only tool calls run on their own. complete_checkout does not: the stream emits a confirmation token and waits. Nothing is charged until you POST that token back with approved: true, and the token expires. If you get a 410, ask the person again — do not reuse it and do not retry the checkout blind. That is the same rule as step 6 above, and for the same reason.
AG-UI specification (CopilotKit)Use the trust level returned in each merchant profile to decide what actions your agent can perform.
| Range | Verification | Agent action | Note |
|---|---|---|---|
| Insufficient | any | Do not proceed | Inform user — insufficient trust data |
| Low | any | Catalog only | Browse and search — do not create cart |
| Eligible | STANDARD | Cart allowed | Human confirmation required before checkout |
| Eligible — verified | PREMIUM | Cart allowed — verified | Merchant identity verified. Higher confidence for agents |
| High | STANDARD / PREMIUM | ALLOW up to checkout | Cart and pre-checkout tools run unattended; complete_checkout is HITL_REQUIRED at every trust level |
| High — verified | PREMIUM / QUALIFIED | ALLOW up to checkout — highest trust | Verified merchant with strong operational history. Fewer RECONFIRM outcomes; complete_checkout is still HITL_REQUIRED |
Inspect the complete scoring formula — including component weights and verification sources — at GET /api/v1/trust/methodology (no auth required).
Exact JSON shapes your agent must send and expect. All calls use POST /{slug}/mcp (JSON-RPC 2.0).
search_products — Request
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "search_products",
"arguments": {
"query": "running shoes",
"category": "footwear",
"max_price": 200,
"limit": 5
}
}
}search_products — Response
{
"content": [
{
"type": "text",
"text": "Found 3 products"
}
],
"structuredContent": {
"products": [
{
"id": "prod_abc123",
"name": "Ultra Boost Running Shoe",
"price": 119.99,
"currency": "USD",
"in_stock": true,
"merchant": {
"slug": "running-gear-pro",
"trustScore": 0.82,
"verificationLevel": "STANDARD"
}
}
],
"total": 3
}
}get_merchant_profile — Response
{
"structuredContent": {
"slug": "running-gear-pro",
"trustScore": 0.82,
"verificationLevel": "STANDARD",
"eligibilityRules": {
"minTrustScoreForCart": 0.7,
"minTrustScoreForAutonomy": 0.8,
"requiresHumanConfirmation": [
"create_cart",
"complete_checkout"
]
},
"constraints": {
"maxItemsPerCart": 20,
"checkoutRequiresUrl": true,
"paymentProcessedBy": "merchant"
},
"policies": {
"returnWindowDays": 30,
"freeShippingThreshold": 75,
"shippingEstimateDays": "2-4"
}
}
}A minimal decision framework for agents integrating this API. These are patterns, not hard rules enforced server-side.
search_products, get_product_detail, compare_products, and check_availability are read-only. Your agent can call them freely without user confirmation.
create_cart validates stock and groups items by merchant. For amounts above your configured threshold (default $100), ask the user to confirm before calling.
complete_checkout always requires explicit user confirmation. It returns merchant checkout URLs — it does not process payments itself (the merchant's processor does), but has real financial consequences. Never call it autonomously.
Merchants with a low trust level are considered CAUTION tier. Inform the user before adding items to cart. When trust data is insufficient, do not proceed without explicit user consent.
If the user's request could imply an irreversible action, ask for clarification before calling any write endpoint. Prefer over-confirmation to silent errors.
Usage limits
Parameters so your agent can plan call strategies and respect service limits.
| What you call | Budget | Counted per |
|---|---|---|
| Any route (global ceiling) | 500 / 15 min | IP or authenticated user |
| /demo-store/mcp | 20 / min | IP (no key) |
| MCP Gateway (with key) | 30 / min | Key — same budget on every plan |
| Agentic REST /api/v1/agent/* | 100–10,000 / min | Key, by its real tier |
| Tools with their own budget | 10–20 / min | Key and tool, on top of the budget above |
Response headers
X-RateLimit-Limit: 30 X-RateLimit-Remaining: 17 X-RateLimit-Reset: 1711051260 Retry-After: 60 // only on 429
On HTTP 429, wait Retry-After seconds before retrying. The X-RateLimit-Limit value depends on which layer bit first — don't assume it's your plan's.
MCP store keys carry no tier: through the gateway every plan gets 30 req/min. All four layers in Developers →
WebMCP exposes MCP tools directly in the browser via navigator.modelContext. Available in the merchant dashboard (authenticated pages). Not available on public pages.
The browser bridge is in development and its native mode remains unvalidated against a browser with real support. Don't confuse it with the server-side MCP endpoint — the "Store MCP" section below — which is in production and is plain MCP, not WebMCP.
Planned tools (browser-side)
search_productsget_product_detailsbrowse_categoriesget_merchant_profileCall example (design preview)
// navigator.modelContext — planned API
const result = await navigator.modelContext
.callTool("search_products", {
query: "running shoes",
maxResults: 5
});
// Pages: /dashboard, /store/*
// Auth: session cookie requiredThis contract is in design. Do not implement WebMCP calls in production until the final contract is published.
The demo store MCP endpoint is fully public for read operations. Connect your agent, explore the catalog, manage carts, and complete checkouts — with real data, no API key needed.
This is plain MCP over HTTP, in production. It is not WebMCP: the WebMCP browser bridge is the section above and remains in development.
POST https://trusteed.xyz/demo-store/mcpJSON-RPC 2.010 of the 48 the demo store serves
search_products
Search by text, price, or category
browse_categories
List catalog categories
get_product_details
Full product detail sheet
get_merchant_profile
Trust score, protocols & policies
create_cart
Creates cart session in DB
get_shipping_rates
Rates with address elicitation
select_shipping_option
Pick method, recalculates totals
apply_discount
Applies discount code
preview_checkout
Full summary before payment
complete_checkout
Finalizes purchase via Stripe sandbox
Tools marked 'sandbox' auto-provision their key in the playground.
Integrated payment protocols
Follow this 6-step pattern to integrate with any Trusteed merchant. Each step is independently useful — you can start simple and add capabilities over time.
Fetch /.well-known/merchant-index.json for the full merchant registry (no auth, ISR 5 min). Or /llms.txt / /mcp.json to find MCP endpoints and available tools. Check /.well-known/agent-policy.json for action boundaries.
GET /.well-known/merchant-index.json → all stores with trust_score + mcp_endpointCall get_merchant_profile to check trust level, verification level, and supported protocols. A sufficient trust level is safe for cart operations.
tools/call → get_merchant_profile → trust.verificationLevel: STANDARDUse search_products with filters (category, price range). Compare results using rating, price, and inStock fields.
tools/call → search_products { query: "laptop", max_results: 5 }Create a cart with selected items. Get shipping rates (may trigger address elicitation). Apply discount codes if available.
tools/call → create_cart → get_shipping_rates → apply_discountCall preview_checkout to show the user a final summary with all totals. Respect agent-policy: orders > $100 require human confirmation.
tools/call → preview_checkout → show totals to user → get confirmationCall complete_checkout with buyer info and payment method. Handle PayPal approval URLs via elicitation. Idempotent by idempotency_key, but not unconditionally safe to retry: retry only on 5xx or network timeout, reusing the same key (max 3 attempts). Never after a 4xx (400/402/409/429) — check get_orders first if any response came back. Decision tree: /.well-known/agent-playbooks.json#safe-checkout-retry
tools/call → complete_checkout { paymentMethod: "STRIPE" }Three ways to test your agent integration — from zero-config demo to full production API.
POST /demo-store/mcp — JSON-RPC 2.0. No API key is required for any tool, including writes — but that only means no credential to supply: every call is still IP-rate-limited (20 req/min, max 3 concurrent sessions, 30-minute TTL) and checkout tools are reachable but SIMULATED — no payment is processed and no real order is created. tools/list returns the full declared catalog (48 tools). Every other store slug requires a caller-supplied API key per tool.
No key neededPOST /api/v1/sandbox/key — get a temporary sandbox key valid 24 hours for beta testing. Unlocks supported write flows such as create_cart and complete_checkout. Rate limit: 50 req/hour, 3 keys/IP/day.
24h beta keyRegister at trusteed.xyz, create a store, and complete guided onboarding to obtain production access for your merchant catalog and approved flows.
Guided rolloutQuick test (no auth):
curl -s -X POST https://trusteed.xyz/demo-store/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"search_products","arguments":{"query":"*"}},"id":1}'Sample transcript
Pseudo-log of a complete interaction. Shows the discovery pattern, trust evaluation, and checkout flow.
# User → Agent → MCP tools
> User: Find me running sneakers under $150
│
[1] GET /llms.txt → found endpoint POST /demo-store/mcp
[2] tools/call get_merchant_profile → trust: 0.85, STANDARD ✓
[3] tools/call search_products { query: "sneakers", max_price: 150 }
→ 4 results found
[4] tools/call get_product_details { id: "prod_abc123" }
→ Ultra Boost Running Shoe, $119.99, in stock, rating: 4.8
[→] Showing user: Ultra Boost $119.99 ⭐ 4.8 · 30-day returns
│
> User: Yes, add it to cart and checkout
│
[5] tools/call create_cart { items: [{ productId: "prod_abc123", qty: 1 }] }
→ cart_id: cart_xyz789
[6] tools/call get_shipping_rates (elicitation: address)
→ Standard $5.99 (3–5 days), Express $12.99
[7] tools/call select_shipping_option { optionId: "standard" }
[8] tools/call preview_checkout → subtotal $119.99 + $5.99 = $125.98
[!] Policy: amount > $100 requires human confirmation
[→] Confirming with user: $125.98 via Stripe — confirm? [YES/NO]
│
> User: Yes
│
[9] tools/call complete_checkout { paymentMethod: "STRIPE", buyerEmail: "..." }
→ status: COMPLETED · order: #ORD-20260324-001 ✓
* Buyer address and email collected via elicitation — the agent never stores them.
Requirements by protocol
Trusteed is infrastructure — not an agent. Each payment protocol imposes different requirements on the agent operator.
| Protocol | Agent Registration | Consumer Enrollment | Current access |
|---|---|---|---|
| ACP (Stripe) | None | None | Public beta |
| AP2 (Google) | None | None | Public beta |
| x402 (USDC) | None | Crypto Wallet | Sandbox available |
| UCP | None | None | Public beta |
| PayPal | None | None | Coming soon |
| Visa VIC | None | FIDO / Passkey | Coming soon |
| MCAP (Mastercard) | KYA Required | None | Coming soon |
| KYApay (Skyfire) | KYA Required | None | Coming soon |
Visa VIC vs Mastercard MCAP — key distinction
Visa VIC
Consumer-centric. The buyer authenticates via FIDO passkey. The agent needs no registration or keys of its own.
Mastercard MCAP
Agent-centric. The operator must register an Ed25519 public key and sign every request (RFC 9421). KYA required.
* The KYAI Policy Engine is applied uniformly across all protocols — regardless of agent registration requirements.
Related resources
Protocol Matrix
ACP, AP2, x402, UCP — status, capabilities, and sandbox
Market Outlook
Agentic commerce signals and forecasts
Developer Portal
API docs, sandbox, and integration guide
SDK Quickstarts
Connect from OpenAI Agents, Claude, or Vercel AI SDK in minutes
Security & MCP-38 coverage
28/38 vectors mitigated — auditable matrix and architecture