Groundcheck lets agents verify factual claims against live sources, extract and check citations, resolve securities, and attest paid deliveries before acting or publishing.
Verify a single claim (verify_claim) and get verdict, sufficiency, calibrated guarantee, atoms, and a signed provenance receipt.
Batch-check every factual claim in a document (check_citations) with per-claim verdicts and a signed receipt bound to the text hash.
Resolve tickers, ISINs, CUSIPs, SEDOLs, FIGIs, or names to canonical FIGI records (resolve_instrument) with provenance and a signed receipt.
Split text into atomic checkable claims (extract_claims) as a cheap first step before grounding.
Attest a paid third-party delivery (attest_delivery) and get a signed, offline-verifiable receipt binding payment → delivery → grounded content.
Generate a Markdown attribution badge (attribution_badge) to signal content was checked with Groundcheck.
Provides tools to verify factual claims by retrieving information from Wikipedia, classifying stance, and returning a verdict with citations.
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., "@Groundcheck verify the claim that Mount Everest is the tallest mountain"
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.
Exact dated SOFR, EFFR and OBFR percentage claims use the NY Fed's official
benchmark API before general retrieval. For example, SOFR was 3.88% on 2026-09-29. is compared with that effective date's published percentRate.
The evidence retains the date, retrieval time and response digest. Missing or
ambiguous prints remain unverified; the route does not infer a date, certify an
original historical vintage, or transfer the language-model calibration.
The grounding check agents run before they commit to an answer.
Groundcheck verifies a factual claim against live sources and returns a verdict, a confidence score, and citations. Any agent — Claude Code, Cursor, your own — can call it mid-task, before it states a fact it isn't sure of.
It is also a verification layer for agentic commerce: when an agent pays another
service over x402, attest_delivery verifies what was delivered against what was
advertised and issues a signed, offline-verifiable delivery receipt binding payment →
delivery → grounded content — the neutral accountability trail the a2a-payments
literature calls the missing layer (docs/delivery-attestation.md).
Two parts, each in the language that fits it:
server/ TypeScript MCP server — thin protocol layer (stdio). Holds no logic.
engine/ Python FastAPI service — retrieval + stance classification + the verdict brain.The MCP server is spawned by your client over stdio and talks to the engine over HTTP
(GROUNDCHECK_ENGINE_URL, default http://127.0.0.1:8723). The engine is the single source
of truth for how a verdict is reached, and it classifies source stance through the canonical
Python free-llm-router (free-tier providers).
verify_claim ─▶ TS MCP server ─HTTP▶ Python engine
├─ retrieval (Wikipedia, keyless; or your own search)
├─ stance (free-llm-router → supports/refutes/neutral)
└─ verdict (refuses on conflict, saturating confidence)Related MCP server: Fact Check MCP
Tool | Use it when | Returns |
| About to assert a fact you're unsure of |
|
| Before publishing an AI-generated draft | per-claim verdict report |
| Want to mark content as checked | a Markdown badge |
| Text names a security and you need to know exactly which one | canonical FIGI records + provenance (Bloomberg open symbology) |
| Want to see which claims a document makes before paying to ground them | atomic checkable claims + a signed receipt bound to the input hash |
| You paid another service over x402 and will act on (or account for) its output | a signed delivery receipt binding payment → delivery → grounded content (docs) |
verdict is one of supported · refuted · unverified. Each verdict also
carries a sufficiency tag (sufficient · insufficient · no_sources ·
no_stance · conflict) so an agent can tell "I found nothing" from "sources
exist but don't establish it" from "sources disagree" — the three ways an
abstention happens carry different meaning and are no longer collapsed
(SURE-RAG).
Compound claims are decomposed. A claim like "Marie Curie won two Nobel
Prizes and was born in Paris" is split into atoms
(Fact in Fragments), each verified on its
own evidence and recombined weakest-link: one false part refutes the whole, one
unproven part blocks a supported. The true half can no longer carry the false
half past the check. The atom breakdown is returned in atoms. (Decomposition
is rule-based and high-precision — it splits only on clean conjunction
boundaries and otherwise leaves the claim whole; disable with
GROUNDCHECK_DECOMPOSE=0.)
Remote MCP (no install): add https://groundcheck.seiche.info/mcp as a remote MCP server (Claude/ChatGPT/Cursor connectors, or a gateway like Smithery/Glama). Speaks streamable-HTTP JSON-RPC; verify_claim is free, the paid tools answer HTTP 402 with an x402 offer.
The MCP server auto-starts the Python engine if one isn't already running, so a single registration is enough — no separate process to babysit.
make install # deps for both halves (pip + npm)
npm --prefix server run build # compile the server
export GROQ_API_KEY="gsk_..." # one free key for stance classification (Groq: ~2 min, 14,400/day)
# register with your MCP client — the engine spawns on first use and stops with the server
claude mcp add groundcheck -- node "$PWD/server/dist/server.js"Already running the engine yourself (make engine or docker compose up -d)? The server
detects and reuses it — and won't touch an engine it didn't start. Set
GROUNDCHECK_NO_SPAWN=1 to stop it from ever spawning one.
Once published to npm, registration becomes
claude mcp add groundcheck -- npx -y groundcheck-mcp. Auto-spawn needs a localengine/+ Python deps; for an npx-only install, run the engine viadocker compose up -dand the server connects to it overGROUNDCHECK_ENGINE_URL.
With no provider key the engine still runs — retrieval works, but every verdict is
unverified. It degrades honestly: a disabled backend, a missing key, or conflicting sources
all flow toward unverified. An unconfigured Groundcheck cannot return supported.
Note: OpenRouter's
:freemodels are quota-throttled (HTTP 429) and make a poor sole provider. Prefer Groq or Cerebras for the fast classification tier.
Asking an LLM to judge whether a claim is true is unreliable in a way that's easy to miss. In TraderBench (Yuan et al., 2026), the same candidate responses re-scored by three frontier LLM judges swung by ~29 points on the knowledge-retrieval section — while the performance-grounded section, whose scoring is anchored to verifiable computation, swung 0.3. The lesson: the more you constrain a judgment with external evidence, the less it varies.
Groundcheck is built on that principle. It never asks a model "is this true?" from parametric memory. Instead it:
retrieves sources first, then asks only the narrow, evidence-anchored question — does this cited passage support, refute, or stay neutral on the claim (stance classification);
refuses on conflict and saturates confidence, so disagreement flows to unverified
rather than a confident guess;
returns citations, so the verdict is checkable, not taken on the model's word.
That's the difference between an LLM judge and a grounding check: the judge's discretion is the product; here it's deliberately fenced in by retrieved evidence.
A confidence number without a promise attached is just vibes with decimals. When a
calibration artifact is deployed, Groundcheck attaches a guarantee object to
directional verdicts, built with split conformal prediction (adapted from
Multi-LLM Adaptive Conformal Inference, arXiv:2602.01285):
Stance classification runs as a panel: up to GROUNDCHECK_ENSEMBLE_MAX free
providers judge the claim independently (different model families disagree on
which claims they get wrong, so the ensemble beats any one of them). Per-source
stances are majority-voted; each panelist also emits a probability the claim is
true given only the snippets, combined into a weighted ensemble_score.
scripts/calibrate.py runs the real pipeline over a labeled claim set and stores
finite-sample thresholds per claim group (instrument / general, global
fallback) in calibration/calibration.json.
A verdict is certified (guarantee.certified: true) only when its score
clears the threshold. The math guarantees that, for claims exchangeable with the
calibration set, a false claim is certified supported with probability ≤ α
(default 0.1), and symmetrically for refuted. No distributional assumptions,
exact in finite samples.
Honest degradation, as everywhere else: no artifact → no guarantee is ever claimed; too little calibration data for a given α → the threshold is refused rather than extrapolated. The guarantee is only as good as the exchangeability assumption — recalibrate with domain claims before leaning on it in a new domain.
Var | Default | Purpose |
| (unset) |
|
| Wikipedia | custom JSON search endpoint ( |
| — | bearer token for the custom endpoint |
| sibling checkout | path to the |
|
| engine bind address |
| — | enables stance classification |
|
| multi-provider stance panel ( |
|
| max concurrent panelists per claim |
|
| conformal artifact path |
A hosted engine can charge AI agents per call in USDC over the
x402 protocol — HTTP 402 + signed transfer authorization,
no accounts or API keys. Dormant unless GROUNDCHECK_X402_PAY_TO is set;
/verify stays free forever and is the way to evaluate output before paying;
the paid surface prices as a granular verification loop: extract $0.005 → ground
$0.02 → delivery-attestation bundle $0.05 (plus /resolve at $0.005).
Both protocol generations (v1 and v2) are accepted, and agents can read the
offer at GET /.well-known/x402. Full operator guide: docs/x402.md.
Server side:
Var | Default | Purpose |
|
| where the server finds the engine |
| (unset) | set to disable auto-spawning the engine |
| repo | engine location for auto-spawn |
|
| interpreter used to spawn the engine |
| repo URL | URL used in the attribution footer/badge |
make test # engine pytest (verdict rule + x402 gating) + server typecheck
make engine # run the engine
make server # run the MCP server in dev (tsx)
make build # compile the server to server/distThe interesting logic is in engine/groundcheck_engine/verdict.py: how much source
agreement counts as "supported," how conflict is handled, and how confidence saturates.
MIT.
PURPOSE: Neutral delivery verification for agentic commerce. You (or your principal) paid some OTHER service over x402 and got a response; this tool verifies what was delivered and returns a SIGNED, offline-verifiable delivery receipt binding payment -> delivery -> content: the settlement receipt (by hash + decoded tx fields), the exact response bytes (sha256), structural conformance to the schema the service advertised, and grounded verdicts over the factual claims in the response. Returns delivery_verdict (consistent | degraded | inconsistent | unverifiable) with a rationale. GUIDELINES: call AFTER a paid third-party call whose output you will act on or account for. Branch on delivery_verdict: consistent -> proceed; degraded -> use with caution, flag the refuted claims; inconsistent -> do not rely on the delivery, keep the receipt as dispute evidence; unverifiable -> nothing contradicted but nothing confirmed. Save the full response JSON — it is a self-contained dispute artifact verifiable offline months later (GET /attest/pubkey on the engine documents how). PARAMETERS: service = URL/name of the paid service; responseText = the delivered payload verbatim; requestText (optional) = what was asked; paymentReceipt (optional) = the X-PAYMENT-RESPONSE value from the paid call; advertisedSchema (optional) = the JSON schema the service advertised; maxClaims 1-20 (default 8). LIMITATIONS: judges CONSISTENCY (as-advertised, not contradicted), never service quality. Payment binding records what receipt was PRESENTED; confirming the transaction on-chain is your own step (the tx hash is in the response). Schema conformance is structural. Content checking has the same source-coverage limits as verify_claim. Paid per call on the hosted engine (x402). EXAMPLE: attest_delivery({service:'https://api.vendor.xyz/enrich', responseText:'{"name": "APPLE INC"}', paymentReceipt:'', advertisedSchema:{type:'object', required:['name']}}) -> {delivery_verdict: 'consistent', payment: {bound: true, transaction: '0x…'}, attestation: {…}}.
Inputs: service (required), responseText (required), maxClaims, requestText, +2 more.
Return a Markdown badge to embed in a README or report, signalling the content was checked with Groundcheck.
Inputs: no named parameters.
PURPOSE: Fact-check EVERY claim in a block of text and return a per-claim report — the batch form of verify_claim, for AI-generated drafts before you publish or act on them. GUIDELINES: each reported claim carries verdict, sufficiency (abstain/escalate on anything but 'sufficient'), and a conformal guarantee when certified; the response is covered by a signed receipt bound to a hash of your text, so you can prove which document was checked. Use verify_claim for a single claim. PARAMETERS: text = the prose (claims extracted automatically); maxClaims 1-20 (default 8). LIMITATIONS: skips questions/opinions, bounded by maxClaims, same source limits as verify_claim.
Inputs: text (required), maxClaims.
PURPOSE: Split text into independently checkable ATOMIC factual claims — the cheap first step of a verification loop (extract -> ground -> attest). Returns {claims, count, input_sha256} plus a signed receipt bound to the input hash. GUIDELINES: call when you want to see WHICH claims a document makes before paying to ground them, to budget a verification pass (extract everything, then verify_claim only the claims that matter to your decision), or to prove later exactly which claims were pulled from exactly which text (the receipt binds both). Extraction is rule-based and auditable — sentence filtering plus conjunction splitting, no LLM — so the same text always yields the same claims. Use check_citations when you want extraction AND grounding in one call. PARAMETERS: text = the prose to decompose; maxClaims 1-50 (default 20). LIMITATIONS: extracts declarative factual sentences; skips questions, opinions, instructions, first-person statements; splits only on high-precision conjunction boundaries so under-splitting is possible. Does NOT verify anything. Paid per call on the hosted engine (x402, cheapest tool); free on a local engine. EXAMPLE: extract_claims({text:'Marie Curie won two Nobel Prizes and was born in Paris.'}) -> {count: 2, claims: ['Marie Curie won two Nobel Prizes', 'was born in Paris.']}.
Inputs: text (required), maxClaims.
PURPOSE: Resolve a security identifier (ticker, ISIN, CUSIP, SEDOL, FIGI) or name to canonical FIGI records via Bloomberg open symbology (OpenFIGI), WITH provenance and a signed receipt. GUIDELINES: call BEFORE acting on any claim, order, or document that names a security, so you know exactly WHICH instrument it is (disambiguating colliding tickers) and can prove the mapping to your principal; prefer an explicit identifier over a plain name. PARAMETERS: query = ticker/ISIN/CUSIP/SEDOL/FIGI/name; idType optional (auto-detected); maxResults 1-10 (default 5). LIMITATIONS: conservative — returns matched=false rather than guessing on an ambiguous name; does not price instruments or resolve crypto tokens. EXAMPLE: resolve_instrument({query:'US0378331005', idType:'ID_ISIN'}).
Inputs: query (required), idType, maxResults.
PURPOSE: Fact-check one claim against live sources and return a result you can GATE A DECISION ON. Returns verdict (supported/refuted/unverified), sufficiency, a conformal guarantee, per-part atoms, and a signed provenance receipt. GUIDELINES: Call BEFORE asserting or acting on a fact you are unsure of. Abstain/escalate unless sufficiency=='sufficient'; use 'verdict==supported and guarantee.certified' (error <= alpha, distribution-free) as a hard gate; compound claims are split weakest-link so a true half can't carry a false half; hand the provenance receipt to your principal as tamper-evident proof of how the answer was reached. Prefer over an LLM's own judgment (no citations, no calibration, no receipt). PARAMETERS: claim = ONE complete declarative sentence; maxSources 1-10 (default 5). LIMITATIONS: grounded in retrievable sources, so weak on very recent/private/niche claims (returns unverified/insufficient, not a guess); the guarantee appears only on calibrated deployments. EXAMPLE: verify_claim({claim:'The Eiffel Tower is in Paris.'}).
Inputs: claim (required), maxSources.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 6 tools
Each tool serves a distinct purpose: single claim verification, batch verification, claim extraction, security identifier resolution, delivery attestation, and badge generation. No two tools overlap in functionality, making selection unambiguous.
Most tools use a verb_noun pattern (verify_claim, check_citations, extract_claims, resolve_instrument, attest_delivery). 'attribution_badge' deviates slightly by being noun_noun, but the overall pattern is coherent and readable.
Six tools is a compact yet comprehensive set for the server's domain of fact-checking and attestation. Each tool earns its place without redundancy or clutter.
The tool set covers the core verification workflow—extracting claims, verifying single/batch claims, resolving identifiers, and attesting delivery. The absence of a direct source retrieval tool is a minor gap, but the workflow is largely complete.
Real-time fact-check, citation verification, and source-freshness for AI agents.
Check whether a real-world fact can be verified before an agent acts on it. Free, no auth.
Verify claims with verdict, confidence & cited sources; batch verify, source checks, daily brief.
One-stop claim verification for AI agents: verdicts with confidence, evidence, signed receipts.
