ReturnCheck

io.github.mangelmartinezfer-huePublished by GitHub account mangelmartinezfer-huev1.1.0Updated Oct 24, 2026

Can this product actually be returned? The merchant's exact clause, its URL and the date.

The publisher's own server: check.tattoo: tattoo size and placement guide

VerifiedStreamable HTTPWeb executableWeb Search & ScrapingBusiness & Commerce

Overview

AI-generated overview

ReturnCheck checks whether a product can be returned, returning a verdict with the merchant's exact policy clause, source URL and date.

What you can do
  • Check a purchase's return policy: send a product URL and buyer country to get a YES, YES_WITH_CONDITIONS, NO or UNKNOWN verdict with a confidence score.
  • Read the evidence: the exact policy clause quoted from the page, its source URL, the return window and the verification date.
  • Supply already-rendered page text or HTML so the service verifies against it instead of fetching the page itself.
  • Point to a separate policy page with its own source URL so the supplied source is preserved in the evidence.
When to use it
Useful for shopping agents or assistants that need a machine-checkable answer on whether a purchase is reversible before buying, and that want the quoted clause rather than a guess. It is aimed at US data first, with a global architecture.
Requirements
Runs as a hosted remote endpoint over streamable HTTP, or locally via the npm package returncheck-mcp over stdio. An optional API key can be set in RETURNCHECK_API_KEY; without it you get a keyless free trial. Optional settings control local fetching (RETURNCHECK_FETCH_LOCALLY), the local read timeout (RETURNCHECK_TIMEOUT_MS) and the service endpoint (RETURNCHECK_URL).
Before you install
Verified answers are billed at $0.02 each via x402 crypto payment on Base; UNKNOWN answers are free and a keyless trial allows a few calls a day. Paid calls require signing a payment authorization with a wallet, so treat the payment signature and nonce as sensitive and do not create a second authorization while a settlement outcome is pending or ambiguous. Product URLs and any supplied page content are sent to the hosted service unless local fetching is used.

Installation

In SourceWeft

  1. Open ReturnCheck in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.mangelmartinezfer-hue%2Freturncheck/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "returncheck": {
      "type": "http",
      "url": "https://returncheck.m-angelmartinez-fer.workers.dev/mcp"
    }
  }
}

README

ReturnCheck — Return-policy verification for AI shopping agents

[Wellknown verified]

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

bash
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:

json
{  "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:

  • accepted is the full accepted payment requirement object, not a boolean.
  • payload directly contains signature and authorization.
  • The canonical identifier path is extensions["payment-identifier"].info.id.
  • Do not copy the bazaar discovery extension into PAYMENT-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

json
{  "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
UNKNOWNFree
Keyless free triala 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

Source: README.md at commit 1458de0

Tools

1

check_return

ReturnCheck verifies which return policy actually applies to this purchase. BEST RESULTS: send the product page you already have as page_text (or page_html) along with product_url — your browser renders JavaScript and is not blocked by retailers, so this works on any store and is faster. Without it we fetch the page ourselves and reach the policy for about 1 in 3 US retailers (17 of 50 measured 2026-08-28; mostly Shopify and direct-to-consumer brands — large retailers and marketplaces block server-side reads). You get a verified verdict — YES / YES_WITH_CONDITIONS / NO / UNKNOWN — with the exact policy clause quoted verbatim, source URL, return window/deadline, fees and a confidence score. Never invents: returns UNKNOWN instead of guessing, and UNKNOWN is free.

Parametersreasonmerchantpage_htmlpage_textproduct_urlrequiredseller_namebuyer_countryrequireddelivery_datepurchase_dateitem_conditionpage_source_urlpayment_signature

Version history

1
  1. v1.1.0LatestSep 16, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts

    Declare a license in the repository or the registry entry.

Other Check integrations