ReturnCheck

io.github.mangelmartinezfer-hue由 GitHub 账号 mangelmartinezfer-hue 发布v1.1.0更新于 Oct 24, 2026

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

发布方自己的服务：check.tattoo: tattoo size and placement guide

已验证Streamable HTTP可网页运行网页搜索与抓取商业与电商

服务详情

标识符: io.github.mangelmartinezfer-hue/returncheck
传输: Streamable HTTP
运行时: Web executable
信任: Verified
发布于: Sep 16, 2026

安全提示

MCP 服务会接收对话中的工具调用请求，并可能执行外部操作。启用前请先了解该服务能做什么，并只授予它所需的权限。

注册中心已验证此条目所属的 GitHub 账号 mangelmartinezfer-hue。这并不表明该账号就是产品方。

SourceWeft 的检查只涵盖条目是否完整、端点是否响应；不审查服务器的代码，也不审查其工具的行为。

在 README 中添加徽章

向读者展示该 MCP 服务已收录于 SourceWeft，徽章链接到本页。

[![Listed on SourceWeft](https://sourceweft.com/badge/mcp/io.github.mangelmartinezfer-hue%2Freturncheck.svg)](https://sourceweft.com/mcp/io.github.mangelmartinezfer-hue%2Freturncheck?utm_source=readme&utm_medium=badge)

概览

AI 生成的概览

ReturnCheck 判断某件商品能否退货，给出结论并附上商家原始条款、来源网址与日期。

可以做什么: 核查退货政策：提交商品网址与买家所在国家，得到 YES、YES_WITH_CONDITIONS、NO 或 UNKNOWN 结论及置信度。
读取证据：返回从页面逐字引用的条款、来源网址、退货期限与核验日期。
提交已渲染的页面文本或 HTML，让服务直接据此核验而不自行抓取页面。
为单独的退货政策页提供其来源网址，使证据中保留调用方声明的来源。
适用场景: 适合购物类智能体或助手在下单前需要机器可核验的“能否退货”答案，并希望拿到原文条款而非猜测的场景。目前以美国数据为主，架构面向全球。
运行要求: 可作为远程服务通过 streamable HTTP 连接，也可通过 npm 包 returncheck-mcp 以 stdio 在本机运行。可选 API 密钥通过 RETURNCHECK_API_KEY 设置，不设置则使用免密钥免费试用。另有可选设置控制本地抓取（RETURNCHECK_FETCH_LOCALLY）、本地读取超时（RETURNCHECK_TIMEOUT_MS）与服务地址（RETURNCHECK_URL）。

安装前请注意

已核验的答案通过 Base 上的 x402 加密货币支付按每次 0.02 美元计费；UNKNOWN 免费，免密钥试用每天可调用数次。付费调用需用钱包签署支付授权，支付签名与 nonce 应视为敏感信息；结算结果处于待定或不明状态时不要创建第二个授权。除非使用本地抓取，商品网址及提交的页面内容会发送到托管服务。

安装

在 SourceWeft 中

打开控制台中的 ReturnCheck，将其添加到工作区。
为需要使用其工具的对话启用该服务。

Web executable，通过 Streamable HTTP。远程服务在工作区中配置后即可从网页运行时运行。

交给智能体安装

把这段提示词粘贴到 Claude Code、Codex、Cursor 等智能体，或 SourceWeft 对话中。智能体会读取该服务器的安装指南，先向你展示发布者、端点和登录方式，经你同意后再把它添加到你的客户端。密钥不会写进任何命令。

阅读 https://sourceweft.com/mcp/io.github.mangelmartinezfer-hue%2Freturncheck/install.md，并按其中说明把这个 MCP 服务器接入我的客户端。修改任何配置之前，先告诉我它的发布者、端点和登录方式，等我确认。不要把 API 密钥写进命令或我会提交的文件；问我密钥应从哪里获取。

查看智能体所依据的安装指南

其他 MCP 客户端

把它添加到你客户端的 mcpServers 配置中。

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

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"}'

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"      }    }  }}

{  "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"  }}

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

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

来源：README.md，提交 1458de0

工具

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.

输入参数reasonmerchantpage_htmlpage_textproduct_url必填seller_namebuyer_country必填delivery_datepurchase_dateitem_conditionpage_source_urlpayment_signature