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