Provides tools to check marketplace-evidence scores for Amazon product listings and compare multiple Amazon listings by evidence score.
Provides tools to check marketplace-evidence scores for Target product listings and compare multiple Target listings by evidence score.
Provides tools to check marketplace-evidence scores for Walmart product listings and compare multiple Walmart listings by evidence score.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GoBuy Product Trust MCP Server Compare trust scores for Amazon B0BXYCS74H and Walmart 123456789."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A public, read-only MCP server that gives AI agents GoBuy marketplace-evidence scores — and the reference evaluator for the GPV-1 Pre-Purchase Verification Specification.
Public endpoint: https://mcp.gobuy.ai/mcp — keyless, no authentication, read-only. Service statistics: https://mcp.gobuy.ai/stats.
check_product_trust {retailer, product_id} — inspect one Amazon, Walmart, Target, or Best Buy listing: Evidence Score (0-100), verdict, observed/missing signals, freshness. This is the GPV-1 gate evaluator (score >= 55 PASS - 35-54 FLAG - < 35 or not-indexed BLOCK).
compare_products {products: [...]} — inspect and rank 2-20 listings by Evidence Score.
analyze_reviews — per-review forensics: review integrity score, adjusted rating, suspicious-review flags, Verified Purchase checks.
check_store_score {domain} — GoBuy Store Score for any storefront (Shopify and others): agent-readiness plus trust signals, tiers A-D.
scan_store {domain} — on-demand deep storefront scan.
Example:
{ "retailer": "amazon", "product_id": "B0BXYCS74H" }Related MCP server: BopMarket MCP Server
This server's check_product_trust is the reference evaluator for GPV-1, the open pre-purchase verification specification: eight rules (R1-R8) that must all be true before an agent proceeds to checkout. Machine-readable ruleset: docs.gobuy.ai/standard/v1.json. Reference integration: verify-then-checkout (Next.js boilerplate - a secured shopping agent in 5 minutes).
Evidence Scores describe available marketplace records, not product quality, safety, value, suitability, seller legitimacy, or a purchase recommendation. Retailers do not endorse GoBuy.
{ "mcpServers": { "gobuy-product-trust": { "url": "https://mcp.gobuy.ai/mcp" } } }{ "mcpServers": { "gobuy-product-trust": { "command": "npx", "args": ["-y", "mcp-remote", "https://mcp.gobuy.ai/mcp"] } } }npx @modelcontextprotocol/inspector -> Streamable HTTP -> https://mcp.gobuy.ai/mcp -> list tools -> call check_product_trust.
stdio (for mcp-proxy bridges, e.g. Glama deploys): set MCP_TRANSPORT=stdio. The server speaks MCP over stdin/stdout; stdout carries only JSON-RPC, all logs go to stderr.
HTTP (default): listens on PORT (default 3000), endpoint /mcp, health at GET /mcp, stats at GET /stats.
No client authentication required. Rate limited per IP: 60/minute, 1,000/day (429 + Retry-After). Everything is free within rate limits; an optional free API key raises them.
MIT
2026-10-14: stdio transport (MCP_TRANSPORT=stdio) for mcp-proxy deployments; stdout reserved for JSON-RPC, logs to stderr.
Return the indexed 0–100 marketplace-evidence score and complete available signal breakdown for one retailer listing.
| Name | Required | Description | Default |
|---|---|---|---|
| retailer | Yes | Marketplace containing the listing. | |
| product_id | Yes | Native retailer product ID, such as an Amazon ASIN. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and non-determinism are covered. The description adds that it returns an indexed score and a breakdown, but does not detail what signals are included or how results might vary—which is partially mitigated by openWorldHint. It provides marginal extra context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly-phrased sentence that front-loads the core output (score and signal breakdown) and the scope (single listing). No filler or redundant phrasing; every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description sufficiently outlines what is returned (score range and a signal breakdown) and the input scope. It could mention that the breakdown is structured per signal, but for a simple two-parameter read-only tool with annotations, this is nearly complete. Slight gap on output structure prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'retailer' (enum) and 'product_id' (with format example) documented. The description adds no extra meaning about parameters—it doesn't explain what 'product_id' refers to beyond the schema mention of 'Native retailer product ID.' Baseline of 3 is appropriate since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and a clearly defined resource: a 0–100 marketplace-evidence score plus the signal breakdown for a single retailer listing. It is unambiguous and distinguishes from the sibling 'compare_products' by explicitly scoping to one listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description correctly implies this is for a single listing's trust evaluation, but it never states when an agent should use it versus the sibling 'compare_products' (e.g., for comparison tasks). No explicit exclusions or alternative routing are provided, so usage context is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2–20 retailer listings and rank them by marketplace-evidence score. This is not purchase advice.
| Name | Required | Description | Default |
|---|---|---|---|
| products | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint=true and openWorldHint=true, and the description adds that the tool produces a ranking and is not purchase advice. That is helpful but does not go deeper into what the marketplace-evidence score means, what the returned ranking contains, or any caveats about ranking quality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The primary behavior is front-loaded, and the 'not purchase advice' sentence is a concise and relevant clarification that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read-only comparison tool, but since there is no output schema, it should say more about the expected result shape and interpretation of the evidence score. The ranking behavior is mentioned, but a calling agent is left guessing about formatting and scoring details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only gestures at 'retailer listings' and the 2–20 range, with no direct explanation that each entry needs a retailer choice and a product_id, even though those are meaningful for correcting invocation. The schema's nested properties are helpful, but with schema description coverage reported at 0%, the description should compensate more than it does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Compare'), a bounded resource ('2–20 retailer listings'), and the distinguishing outcome ('rank them by marketplace-evidence score'). This makes it clear this is a multi-listing comparison rather than single-item trust checking, so it is easily separated from the sibling check_product_trust.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use it when comparing several retailer listings and ranking them by evidence score. The 'not purchase advice' disclaimer is a useful exclusion, but the description never names when to prefer check_product_trust or gives explicit when-not guidance beyond the disclaimer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1check_product_trustcompare_productsScored across 2 tools
The two tools have clearly distinct purposes: check_product_trust scores a single retailer listing, while compare_products ranks 2-20 listings against each other. The descriptions make the singular-vs-multi scope explicit, so an agent cannot reasonably confuse them.
Both names follow the same predictable verb_noun snake_case pattern (check_product_trust, compare_products). The leading verbs (check, compare) also accurately signal the differing action.
Two tools is on the thin side, but the domain (scoring and comparing retailer listings) is narrow enough that each tool earns its place. A slightly broader surface (e.g. batch or signal-discovery) would round it out.
The core workflow of inspecting one listing and comparing several is covered, which matches the stated purpose. Minor gaps exist: no batch check for a list of single products, no operation to discover or list available signals/retailers independently.
Live prices, stock & price history across 100+ U.S. retailers for any AI agent.
AI-agent product catalog: search, lookup & purchase routing over verified merchant data.
Marketplace-evidence trust scores for AI agents: a 0-100 Evidence Score with signal breakdown.
Real-time Amazon product, seller, and search data for AI agents across 21 marketplaces.
