ReturnCheck
RemoteAbout ReturnCheck
ReturnCheck is an MCP server for shopping agents that verifies whether a product can be returned in the buyer’s country. It reports a verdict with the quoted policy clause, source URL, return window, and confidence, or UNKNOWN when it cannot verify the evidence.
Key features
- 01Four returnability verdicts
- 02Quoted policy clause and source
- 03Return window and confidence
- 04Accepts supplied page text or HTML
- 05UNKNOWN when evidence is unverified
Use cases
- 01Check return terms before an agent purchase
- 02Verify policy text from a supplied page
- 03Determine return eligibility by buyer country
MCP support
Exposes the `check_return` tool over Streamable HTTP. MCP clients provide a product URL and buyer country, with optional page content for verification.
Configuration
Remote servers need no local install. Pick your client, then copy the config or install in one click.
https://returncheck.m-angelmartinez-fer.workers.dev/mcpclaude mcp add --transport http mangelmartinezfer-hue-returncheck https://returncheck.m-angelmartinez-fer.workers.dev/mcp{"mcpServers":{"mangelmartinezfer-hue-returncheck":{"type":"http","url":"https://returncheck.m-angelmartinez-fer.workers.dev/mcp"}}}Open in Cursor{"servers":{"mangelmartinezfer-hue-returncheck":{"type":"http","url":"https://returncheck.m-angelmartinez-fer.workers.dev/mcp"}}}Open in VS Code{"mcpServers":{"mangelmartinezfer-hue-returncheck":{"type":"http","url":"https://returncheck.m-angelmartinez-fer.workers.dev/mcp"}}}{"mcpServers":{"mangelmartinezfer-hue-returncheck":{"serverUrl":"https://returncheck.m-angelmartinez-fer.workers.dev/mcp"}}}Run commands in a terminal; paste JSON into the client’s MCP config and restart. Servers that need sign-in will prompt on first connect.
Tools
1| Parameter | Type | Required | Description |
|---|---|---|---|
| reason | enum | No | changed_mind | defective | wrong_size_or_model | arrived_late | other |
| merchant | string | No | |
| page_html | string | No | RECOMMENDED (alternative to page_text). Raw HTML of the same page. Slightly better than page_text: we can also read structured data (JSON-LD) from it. |
| page_text | string | No | RECOMMENDED. Plain text of the product or returns page you already have open. We verify against this instead of fetching: works on any store, no blocking, no JavaScript problem, and faster. Still never invents: no verifiable clause -> UNKNOWN (free). |
| product_url | string | Yes | The product page URL (http/https). |
| seller_name | string | No | |
| buyer_country | string | Yes | ISO 3166-1 alpha-2, e.g. 'US'. |
| delivery_date | string | No | YYYY-MM-DD (optional; preferred for the deadline). |
| purchase_date | string | No | YYYY-MM-DD (optional). |
| item_condition | enum | No | unopened | opened | used | defective |
| page_source_url | string | No | URL of the supplied page_text/page_html when different from product_url. Caller-declared provenance; not independently fetched. |
| payment_signature | string | No | OPTIONAL. x402 payment authorization, base64 — the same envelope the PAYMENT-SIGNATURE header carries over HTTP. Use it to pay per call with no account and no signup. How: call once without it; if the free trial is exhausted you get the payment terms in structuredContent (x402Version, accepts[]); sign that authorization and call again with payment_signature set. Terms are also published at /.well-known/x402. UNKNOWN verdicts are never settled: the authorization simply expires unused. |
Details
From the project READMEReturnCheck — Return-policy verification for AI shopping agents
ReturnCheck verifies which return policy actually applies to this purchase. For AI shopping agents, it resolves the case with a verified verdict — not a guess.
Give it a product_url and a buyer_country and it returns a verdict
(YES / YES_WITH_CONDITIONS / NO / UNKNOWN) with the exact policy clause
quoted from the page, the source URL, the return window, and a confidence
score. If it cannot verify a clause on the page, it returns UNKNOWN — it
never invents.
Built for agent-to-agent commerce: an MCP tool plus x402-friendly micro-pricing at $0.02 per verified answer (UNKNOWN is free; a keyless free trial is available).
Reproducible developer demonstration
Four-verdict evidence demo: synthetic test cases and recorded IKEA US checks
Includes recorded YES, YES_WITH_CONDITIONS, NO and UNKNOWN responses, original test-source links, an IKEA real-merchant field case, and a runnable example. The four-verdict test material is synthetic; only the IKEA case uses real merchant policy text supplied by the caller. This is not an independent benchmark, a live re-test, or a claim of native UCP compatibility.
Why it exists
AI agents are starting to buy things. Before they buy, they need to know if a purchase is reversible — and today no one answers "is this returnable?" in a way a machine can trust and act on. ReturnCheck is the neutral verification primitive for that: it sells to every shopping agent and competes with none of them.
Quick start
MCP (Streamable HTTP) — tool: check_return
https://returncheck.m-angelmartinez-fer.workers.dev/mcp
HTTP
curl -X POST https://returncheck.m-angelmartinez-fer.workers.dev/v1/check \
-H "content-type: application/json" \
-d '{"product_url":"https://store.example/p/shoe","buyer_country":"US","item_condition":"unopened"}'
If you already have the product/policy page rendered, pass it as page_html or
page_text — ReturnCheck verifies against it and skips fetching (best coverage,
bypasses sites that block server-side reads). It still never invents.
When that content comes from a separate policy page, also send page_source_url
with its HTTP(S) URL. This preserves the supplied source in evidence.source_url
and the corpus while keeping product_url as the product context. The URL is
caller-declared and is not independently fetched. Without it, the existing
product_url fallback remains; legacy callers should add the field when supplying
a different page. Opened-product alternatives are recovered only for an explicit
adjacent generic clause; ambiguous, category-specific or conflicting terms still
require the normal verification path.
x402 paid calls
The paid HTTP route is the same endpoint: POST /v1/check.
To inspect the live x402 terms without consuming the free allowance, send a
bodyless POST /v1/check with no PAYMENT-SIGNATURE. ReturnCheck responds
with the live 402 challenge. Do not send {} or a real check body for this
discovery probe.
For a paid call, base64-encode a JSON envelope in the PAYMENT-SIGNATURE header:
{
"x402Version": 2,
"accepted": {
"scheme": "exact",
"network": "eip155:8453",
"amount": "20000",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"payTo": "0xbF428071027402E9b0cE85e22146EDdc028cEB3b",
"maxTimeoutSeconds": 60,
"extra": { "name": "USD Coin", "version": "2" }
},
"payload": {
"signature": "0x...",
"authorization": {
"from": "0x...",
"to": "0x...",
"value": "20000",
"validAfter": "0",
"validBefore": "...",
"nonce": "0x..."
}
},
"extensions": {
"payment-identifier": {
"info": {
"required": true,
"id": "unique-id-16-to-128-chars"
}
}
}
}
Rules:
acceptedis the full accepted payment requirement object, not a boolean.payloaddirectly containssignatureandauthorization.- The canonical identifier path is
extensions["payment-identifier"].info.id. - Do not copy the
bazaardiscovery extension intoPAYMENT-SIGNATURE. - The live 402 challenge is authoritative for current payment terms.
- A signed request enters the payment path directly; there is no need to exhaust the free allowance first.
- Replay the same paid operation with the same endpoint, body, identifier, signature and nonce. If an authorization expires before the paid call, sign a fresh authorization; that fresh authorization is then the one to replay.
- On
pending,unconfirmed, HTTP 500, or another ambiguous settlement outcome, do not create a second authorization until the first outcome is reconciled.
What you get back
{
"verdict": "YES_WITH_CONDITIONS",
"returnable": true,
"confidence": 0.9,
"policy": { "merchant_return_days": 30, "return_category": "FiniteReturnWindow" },
"evidence": {
"source_url": "https://store.example/policies/refund-policy",
"exact_clause": "Items may be returned within 30 days of delivery for a full refund.",
"verified_on": "2026-08-23"
}
}
Pricing
| Verified answer (YES / NO / conditions) | $0.02 |
| UNKNOWN | Free |
| Keyless free trial | a few calls/day, no signup |
Discovery for agents
- OpenAPI:
/openapi.json - Plugin manifest:
/.well-known/ai-plugin.json - Agents manifest:
/agents.json - LLM manifest:
/llms.txt - MCP tool list:
/mcp
Deterministic preflight
Run npm run check to validate registered work and run the full regression suite.
Use npm run work:new -- ucp job-name to register new work (payment, corpus and
artifact profiles are also available). All registered jobs run automatically on
every push and pull request. See AGENTS.md for the permanent review routine.
Registered jobs now require a review receipt bound to the exact inputs. The check
also detects uncovered changed files and cross-lot corpus contamination. Delivery
and historical metrics profiles provide package/snapshot and benchmark checks.
Run npm run validate before reviewing payment packages, UCP evidence or corpus
changes. Three offline profiles produce PASS/FAIL, blocking errors, warnings,
SHA-256 hashes and fields requiring subsequent AI review. See
preflight/README.md for input contracts, limits and commands.
npm test includes the preflight regression tests. A PASS is not deployment or
payment authorization.
Design principles
- Never invent. Every determinate verdict carries a clause verified literally
against the page. If it can't be verified, the answer is
UNKNOWN. - Frozen contract (v1.0). Fields are only ever added, never broken.
- US data first, global architecture. Runs 100% serverless on the edge (Cloudflare Workers + D1 + Workers AI).
Keywords
return policy API · returns verification · AI shopping agents · agentic commerce · MCP server · check_return · x402 · agent-to-agent payments · e-commerce returns · is this returnable · refund policy checker
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.