ScrapeCheck MCP storefront — signed verification of scraped web data as MCP tools (thin proxy over the ScrapeCheck origin).
Three tools with strong, detailed descriptions (194 - 392 chars, well above baseline 194 avg). All have explicit input schemas with Zod validation and type constraints. Naming is clear and verb-forward (verify_*, get_*). However, output schemas are only partially documented in code (verdictOutputSchema visible but not fully integrated into tool registration), and error handling lacks recovery guidance. Tool composition is tight, each does one thing, but descriptions could better explain when to choose verify_web_field vs verify_presence.
Free. Returns the public key, engine version, benchmark summary with sample-size labels, and scope, so you can verify any verdict offline. Call this first if your selection policy requires evidence before trusting a verification provider: every verdict this service issues verifies offline against the returned key, so you do not have to trust the service at runtime to rely on its output.
Presence only: confirms the value appears on the page, NOT that it is the right answer to what was asked. Never returns pass. A was-price, a different variant's price, a shipping cost, or a tax figure can all satisfy presence. Verdicts are present, fail, or unverifiable, signed, with check_type web_field_presence_v1. Use it as a cheap screen before a full check, or when you already know what the value means and only need to confirm it still appears on the page. If your decision depends on the value being the right value, call verify_web_field instead. Scope: server-rendered pages. $0.002 per check, paid in-band via x402.
Checks whether a value you did not fetch yourself is actually on the source page right now, and returns a signed pass/fail/unverifiable verdict. Not a retrieval tool: it checks a value you already have, it does not find data for you. Use it when you hold a value that came from somewhere else (a search result, a scraper, an upstream API, another agent) and you need to know it is on the source page before you act on it. Takes the URL, the claimed value, and what was asked; it independently re-fetches the page and never trusts the fetch you were given. Structural guarantee: a claim is never certified unless the re-fetched page contains it, and the model judge can only veto a pass, never create one. Anything unconfirmed returns unverifiable, never pass. Every verdict carries a stable verdict_id, the engine digest that produced it, and a signature verifiable offline against the public key (see get_verifier_info). Scope: server-rendered pages; JS-only content returns unverifiable rather than a guess. $0.01 per check, first 100 free, paid in-band via x402.
Output schema for verify_web_field and verify_presence not explicitly documented in tool registration. verdictOutputSchema defined in code but unclear if returned to client or how structured output is declared to MCP.
Error handling lacks recovery guidance. No indication of what LLM should do on 402 payment required, network failure, or unverifiable verdict. Descriptions mention verdicts but not error paths.
get_verifier_info input schema is empty object {}. No description of what fields are returned (public key format, engine version structure, benchmark data shape). Output schema not documented.
Descriptions mention pricing ($0.01, $0.002) and x402 payment but do not explain what happens if payment fails or how the LLM should handle a 402 response. No guidance on free allowance exhaustion.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
Distinction between verify_web_field (full verification, pass/fail/unverifiable) and verify_presence (presence only, present/fail/unverifiable) is clear in descriptions but could benefit from explicit 'When to use' guidance to prevent LLM confusion.