A
licenseNot graded
qualityB
maintenanceProvides read-only tools for US return policies, price-match rules, discounts, deals, credit-card terms, and Amazon buy-or-wait verdicts, with every answer linked to its thrifle.com source.
MIT
ReturnCheck
Server Details
Can this product actually be returned? The merchant's exact clause, its URL and the date.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- mangelmartinezfer-hue/returncheck
- GitHub Stars
- 0
- Server Listing
- ReturnCheck
TDQS
A4.7/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of confusing it with others. The tool's singular purpose is clearly defined and unambiguous.
Naming Consistency5/5
The single tool name 'check_return' follows a clean verb_noun pattern. Consistency is inherently maintained when there is only one tool.
Tool Count4/5
A single tool is minimal but perfectly suited to the server's narrow scope of answering one question. The count feels appropriate rather than insufficient because the tool fully covers that single task.
Completeness5/5
The tool covers the entire return-checking workflow: it returns a verdict, quotes the exact policy, provides source URL, return window, fees, and confidence score, and explicitly handles unknown cases without guessing. There are no obvious dead ends or missing features for the stated purpose.
Available Tools
1 toolcheck_returnAInspect
Answer one question: can this specific product actually be returned? 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| merchant | No | ||
| page_html | 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 | 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 | Yes | The product page URL (http/https). | |
| seller_name | No | ||
| buyer_country | Yes | ISO 3166-1 alpha-2, e.g. 'US'. | |
| delivery_date | No | YYYY-MM-DD (optional; preferred for the deadline). | |
| purchase_date | No | YYYY-MM-DD (optional). | |
| item_condition | No | ||
| payment_signature | 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. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so impressively. It explains the browser-rendering advantage, the fallback fetch success rate, the blocking behavior of large retailers, the policy-quoting behavior, the confidence score, and the rule 'never invents: returns UNKNOWN instead of guessing.' It also discloses that UNKNOWN is free and clarifies payment authorization behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but front-loaded with the core purpose and best-results workflow. Each sentence contributes useful operational information, though a few phrases ('your browser renders JavaScript and is not blocked by retailers') could be trimmed without losing meaning. Overall it earns its length but is slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is remarkably complete. It explains the verdict vocabulary, the exact policy clause quote, source URL, return window, fees, confidence score, fallback behavior, and the payment flow. An agent has enough context to invoke the tool correctly and interpret its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 64%, so the description does not need to compensate for every parameter, but it still adds real meaning. It clarifies the relationship between page_text and page_html, explains why page_text is RECOMMENDED, and gives detailed operational context for payment_signature. However, some parameters like item_condition, reason, merchant, and seller_name receive no additional semantic guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise question the tool answers: 'can this specific product actually be returned?' This states the verb, resource, and expected outcome unambiguously. It also names the concrete verdict values it produces, making the tool's function unmistakable even without siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: send page_text or page_html along with product_url for best results, and explains what happens when you don't ('Without it we fetch the page ourselves'). It does not compare against alternative tools, but no sibling tools exist, so the practical conditional guidance is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
check_return1 field changed- added
Input schema / properties / payment_signatureAdded value: +{ + "description": "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.", + "type": "string" +}
1 tool update
- Changed
check_return2 fields changed- changed
Input schema / properties / page_html / descriptionPrevious value: -"Optional: raw HTML of the page you already have. If provided, ReturnCheck verifies against it instead of fetching — best coverage, bypasses sites that block server-side reads. Still never invents: no verifiable clause -> UNKNOWN."New value: +"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." - changed
Input schema / properties / page_text / descriptionPrevious value: -"Optional: plain text of the page (alternative to page_html)."New value: +"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)."
1 tool update
- Changed
check_return2 fields changed- added
Input schema / properties / page_htmlAdded value: +{ + "description": "Optional: raw HTML of the page you already have. If provided, ReturnCheck verifies against it instead of fetching — best coverage, bypasses sites that block server-side reads. Still never invents: no verifiable clause -> UNKNOWN.", + "type": "string" +} - added
Input schema / properties / page_textAdded value: +{ + "description": "Optional: plain text of the page (alternative to page_html).", + "type": "string" +}
1 tool update
- First observed
check_return
Related MCP Connectors
Verify live product price, currency, stock, variants and published shipping evidence for AI agents.
US return policies, price-match rules, discounts, deals and Amazon price verdicts. Read-only.
Food verification for people and AI agents: evidence-backed verdicts, with sources and dates.
Delivered-price deals, cancel/refund paths, used-value comparisons, and compatibility checks.
Related MCP Servers
- FlicenseNot gradedqualityAmaintenanceSourced product prices, dated price history, specs and independent-test coverage across 4,764 hardware products and 2,064 software vendors — every figure returned with its source URL and the date it was captured. Unknown values come back as null rather than a guess, so an agent can cite what it surfaces.-
- AlicenseAqualityCmaintenanceSearch URDB's product integrity database — integrity scores, enshittification events, warranty cuts, and material downgrades across consumer products. Sourced and evidence-backed.444 npm2MIT
- FlicenseNot gradedqualityBmaintenanceEnables e-commerce customer service agents to retrieve product catalog and return/delivery policy documents through multi-source RAG with RRF fusion, exposing product_search and policy_qa tools for grounded, cited responses.-
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.