Scrapecheck

io.github.FieldmodeLLCPublished by GitHub account FieldmodeLLCv0.2.1Updated Nov 2, 2026

Verify before your agent acts on data it paid for. Signed verdicts, checkable offline, via x402.

VerifiedStreamable HTTPWeb executableWeb Search & ScrapingSecurity & Monitoring

Overview

AI-generated overview

Remote MCP server that re-fetches a source page and returns signed pass, fail or unverifiable verdicts on a value an assistant already holds.

What you can do
  • Verify a claimed field value against a live re-fetched page, with an independent judge confirming it answers the question asked
  • Check presence only, confirming a value appears on the page without judging whether it is the right answer
  • Retrieve the public signing key, engine version, benchmark summary and scope so verdicts can be checked offline
When to use it
Use it when an assistant is about to act on a value it fetched or paid for, such as a price or stock status, and you want an independently signed check that the value is really on the source page before relying on it.
Requirements
A remote streamable HTTP endpoint; no API key or signup. Paid calls use x402 in-band payment in USDC on Base through an x402 v2 client with an EVM signer, after a free allowance per client identity. The server re-fetches pages from its own infrastructure, so it needs the source URL to be publicly reachable.
Before you install
Paid tools cost money per call (about one cent for full verification, less for presence) settled on-chain in USDC; a refused or failed payment yields no verdict. Verdicts only reflect the page at fetch time, client-rendered pages return unverifiable, and presence checks never return pass. The README discloses a signing key exposure in August 2026 and a rotation, so older verdicts signed by the retired key need the issuance record checked.

Installation

In SourceWeft

  1. Open Scrapecheck in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.FieldmodeLLC%2Fscrapecheck/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "scrapecheck": {
      "type": "http",
      "url": "https://scrapecheck-mcp.fly.dev/mcp"
    }
  }
}

README

ScrapeCheck MCP: the verification beat for agents that spend

[scrapecheck-mcp MCP server] [scrapecheck-mcp MCP server]

Here for the offline verifier? It's in this repo: tools/verify-verdict.mjs — one file, no dependencies, verifies any ScrapeCheck verdict with no network access. How to use it →

Agents now find a provider, pay through x402, receive data, and act on it. Nothing in that flow asks whether the data is true. This server adds the missing beat. Before your agent acts on a value it fetched or paid for, it sends the source URL, the value, and what was asked; ScrapeCheck re-fetches the page from its own infrastructure and returns an ed25519-signed verdict: pass, fail, or unverifiable. Never a guess, and anything unconfirmed is unverifiable, never pass.

One line to install, and the agent pays per check through the same x402 rail it already spends on: no API key, no signup, a free allowance before payment is required, and every verdict verifiable offline against our published key.

Want to see a verdict before installing anything? One free check runs in the browser at scrapecheck.fly.dev.

All four integration lanes (MCP, x402-native, Apify, plain HTTP), each with a tested snippet: scrapecheck.fly.dev/integrations

Endpoint: https://scrapecheck-mcp.fly.dev/mcp (streamable HTTP) Payment: x402 in-band (USDC on Base) — no API key, no signup. A free allowance per client identity is served before payment is required.

Check us yourself — the three things you can attack: verify any verdict offline · live run stats, misses included · the benchmark and its limits

Tools

  • verify_web_field — $0.01 — Full verification: value present on the re-fetched live page, served live, and an independent LLM judge confirms it answers what was asked. Positive verdict: pass.
  • verify_presence — $0.002 — Presence only — does NOT confirm the value answers the question. Positive verdict: present, never pass.
  • get_verifier_info — free — The trust artifact: public key, benchmark summary, scope, endpoints.

Where this sits in an agent's spending loop

The payment rail answers who paid what, on whose authority. The receipt is perfect, and the receipt holds no evidence about the data. This tool is the step between receiving and acting: one call per value your agent is about to trust, priced in the same cents the data itself cost.

The trust guarantee is structural, not statistical

A claim is never certified unless ScrapeCheck independently re-fetches the page and finds the claimed value there itself — and the judge's vote is mechanically voided if its restatement of the claim doesn't match what was actually claimed. Absence cannot pass, and substitution cannot pass. Anything unconfirmed — a skipped check, a failed fetch, a judge that errors — returns unverifiable, never pass.

Corroborated by benchmark (full verification only): 0 false passes across 67 frozen labeled cases (26 held out from all calibration, including adversarial traps where the claimed value appears on the page as the wrong thing), and 0 false passes across 21 live-web cases including 9 adversarial traps. Small-N corroboration of the structural guards — not a population accuracy claim.

Why trust this server's own claims?

Because you don't have to. Every verdict is ed25519-signed over canonical sorted-key JSON of all fields except signature; the public key is served at /pubkey and in-band via get_verifier_info; and every verdict carries an engine digest identifying exactly which prompt+calibration produced it. Verify offline — no need to trust the transport, the storefront, or us.

Live, unfiltered run stats — misses included: scrapecheck.fly.dev/stats. A verifier that only shows its passes isn't showing anything.

Payment flow (x402 in-band)

Standard @x402/mcp v2 flow: an unpaid call past the free allowance returns a PaymentRequired challenge in the tool result; pay with any x402 v2 client (e.g. wrapMCPClientWithPaymentFromConfig from @x402/mcp with an EVM signer) and the retried call returns the verdict plus the on-chain settlement in _meta["x402/payment-response"]. A refused or failed payment never yields a verdict, and a verdict that fails to produce never settles — you are charged only for completed work.

Integrator notes

  • The full signed verdict object is in structuredContent on the wire (and byte-identical as JSON in content[0].text). Note: @x402/mcp's paying-client convenience result forwards content only — parse content[0].text there, or read structuredContent with a plain MCP client.
  • Input contract (frozen): { url, claim, asked } — claim is an object of field values, e.g. {"price": "£51.77", "in_stock": true}.
  • Scope (v1): server-rendered pages. Client-rendered (JS-only) content returns unverifiable — never a false fail, never a false pass.
  • Verification is of the moment: a pass means the claimed value was on the page when we fetched it, not that the page itself is current. A page carrying staleness signals can still pass when the claimed value is genuinely present.
  • The same engine is also sold as a raw x402 HTTP API (https://scrapecheck.fly.dev/verify) and as the Scrape QA Apify actor for batch dataset verification. One engine, one signing key, one durable log.

Verify a verdict yourself (offline)

This repo ships a zero-dependency verifier — check any ScrapeCheck verdict without trusting us, the transport, or this server:

console
$ node tools/verify-verdict.mjs examples/verdict.json(2 keys fetched from https://scrapecheck.fly.dev/pubkey — pass --pubkey to verify fully offline)VALID: signature verifies (signed by k2, active)  verdict:    pass (confidence 0.97)  verdict_id: 17aa1a39-0e3f-42a7-a3f4-3cbf664f9786  check_type: web_field_v1  engine:     web_field_v1/0.2.1+6739b7f9ebf8  key_id:     k2 (envelope claim matches the verifying key)  issuer:     https://scrapecheck.fly.dev (embedded pointer; keys were checked against the pinned origin, never the embedded URL)  source_hash: sha256:b2025003076927098d4aaeeb2d7f41554299a8d6d68f060745b18a0527749bf8 — fingerprint of the normalized page text this verdict judged. Comparable between verdicts with the same engine digest; not independently recomputable today.$ echo $?0
# flip a single field — "verdict": "pass" -> "fail" — and run it again$ node tools/verify-verdict.mjs tampered.json(2 keys fetched from https://scrapecheck.fly.dev/pubkey — pass --pubkey to verify fully offline)INVALID: signature does not verify against any of the 2 published keys — the verdict was altered, or was not signed by this service$ echo $?1

Omit --pubkey to fetch the current key from /pubkey; pass it (an ed25519:… string or a saved /pubkey response) to verify fully offline. examples/verdict.json is a real production verdict — alter any field and verification fails. A verdict is valid iff its ed25519 signature verifies over the canonical (recursively key-sorted) JSON of every field except signature. MIT licensed — vendor the ~40 relevant lines into your own pipeline freely.

Envelope fields added August 2026

New verdicts carry three additional signed fields. key_id names which key in the /pubkey archive signed the verdict; it is advisory — the signature either verifies against a published key or it doesn't — and a mismatch between the claim and the verifying key is surfaced as a warning. verifier_url is the canonical origin for /pubkey and /verdicts lookups; it is a pointer home, never a trust root — a verifier must not fetch keys from a URL the document itself supplies, so ours pins the known origin and uses the embedded value only for display and mismatch warnings. source_hash is the SHA-256 of the normalized page text the verdict actually judged, a fingerprint of the page state at refetched_at. Hash equality is meaningful between verdicts carrying the same engine digest; across digests it is best-effort only, and today it is comparable verdict-to-verdict rather than independently recomputable. Verdicts issued before these fields existed verify exactly as before.

Key rotation, August 2026

On 6 August 2026 the ed25519 signing key was treated as exposed: an operator error placed a credentials file into an external chat channel. Under our own doctrine — a key that has touched an untrusted channel is compromised whether or not anyone used it — the key was rotated the same day.

No verdict was affected. Signatures cover the verdict payload, so verdicts issued before the rotation are unchanged and still verify against the retired key, which is published permanently as k1 at /pubkey. Verdicts issued afterwards are signed with k2. The offline verifier tries every published key and reports which one matched.

If you hold a verdict signed by k1, confirm it. A valid signature from a retired key proves that key signed the verdict — not that we issued it, because anyone holding the exposed private key can sign anything, including a forgery that reuses a real verdict_id. So we publish an issuance record:

GET https://scrapecheck.fly.dev/verdicts/<verdict_id>

It returns whether we issued that id and, where available, signature_sha256 — the SHA-256 of the signature we issued under it. ed25519 is deterministic, so hashing the signature on your copy and comparing binds your verdict's exact content to ours. Match means it is the verdict we issued — the same signed content. Mismatch means forged content under a real id. The endpoint returns no verdict content, no client data, and nothing enumerable. Running the verifier without --pubkey performs this check for you automatically on any k1-signed verdict.

One honest limitation. Signature hashes were not logged before 6 August 2026, so for most pre-rotation verdicts we can confirm issuance but cannot bind content; those return content_binding: "unavailable_legacy", and the verifier reports PARTIAL rather than confirming. Where we can bind a pre-rotation verdict from an artifact published before the exposure — the example verdict in this repository, whose signature is fixed in public git history that no forger can rewrite — the record says so and labels the provenance. Bindings recovered from artifacts we merely retained privately are labeled available_backfilled, because a binding is only as good as the provenance of the artifact behind it. Every pre-rotation verdict was issued to ourselves; no external customer holds one.

A commitment that follows. Because the issuance record is public, a logged verdict can never be deleted. Reporting issued: false about a verdict we really signed would be a lie about our own history, so retention is now part of the trust contract rather than an operational preference.

What the exposure meant: a holder of the old private key could produce forged verdicts that verify against the old public key. They could not alter any verdict already issued, and the key gave no access to the service, its logs, or any funds. No forged verdict has been observed.

This is the procedure working as designed, and it is written down here because a verifier that hides its own incidents is not a verifier.

About this repository

This repo contains the thin MCP storefront only — transport, payment handling, and tool registration. The verification engine (the anchored re-fetch, the lenses, the judge, the signing key, and the benchmark fixtures) runs at the ScrapeCheck origin and is not part of this codebase.

Changelog

  • 2026-08-13 — The live stats page counted our own test traffic in its totals; it now separates self, crawler, and external. /stats gained a traffic section publishing both numbers — including external_paid, which reads zero at the time of this change and stays a permanently named line. Self traffic was always labeled in the durable log; the public surface now says so too.

Source: README.md at commit 903a257

Tools

3

verify_web_field

Verify scraped claim (full)

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.

Parametersurlrequiredaskedrequiredclaimrequired

verify_presence

Presence check (not an answer check)

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.

Parametersurlrequiredaskedrequiredclaimrequired

get_verifier_info

Verifier trust info (free)

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.

Takes no parameters.

Version history

1
  1. v0.2.1LatestSep 16, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts