mcpbeat Sign in

Groundcheck MCP Server

answering

Groundcheck is answering right now. Last checked 6 min ago. 42 installs a week from npm. It exposes 5 tools. Last commit 16 Aug 2026.

Verify claims, resolve FIGI identity, extract claims, and sign x402 delivery receipts over MCP.

Installs per day peak 145 · avg 12 · -43% w/w
a month agotoday
Uptime history 47 days of history
47 days agonow
100.0%
Uptime 24h
92 of 92 checks
5
Tools
read from the server
120 ms
Response time
average over 24h
42
Installs / week
npm and PyPI

What changed 1

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 16 August 2026. No other catalogue keeps this.

16 Aug a tool changed version

What the code does

We read the source, 22 h ago · tools taken from the live server · rules 3dff92dd89df

Capabilities

What this server is able to do. For an MCP server this is often the job itself — a terminal server runs commands because that is what it is for. Listed so you know what you are plugging in, not as an accusation.

Runs an external command assets/build-og.py:36
            subprocess.run(cmd, capture_output=True, timeout=30)
Runs an external command server/src/spawn.ts:63
  child = spawn(python, ["-m", "groundcheck_engine"], {

Is this your server and something here is wrong? Tell us — corrections are free and do not require a plan.

This code can reach further than it looks

We found places where it runs commands, builds paths or queries from values it is given. None of that is a flaw by itself — it becomes one when the code changes, and code changes quietly between releases. We re-read it on every one.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 6 min ago.

run in your terminal
claude mcp add groundcheck --transport http https://groundcheck.seiche.info/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "groundcheck": {
      "url": "https://groundcheck.seiche.info/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.groundcheck]
url = "https://groundcheck.seiche.info/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "groundcheck": {
      "url": "https://groundcheck.seiche.info/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "groundcheck": {
      "url": "https://groundcheck.seiche.info/mcp"
    }
  }
}

This one needs environment variables set before it will start: GROUNDCHECK_ENGINE_URL (URL of the Groundcheck evidence engine. Defaults to http://127.0.0.1:8723 for a local engine; set to https://groundcheck.seiche.info to use the hosted engine.). The author declared them in the registry entry; get the values from the project itself.

Available tools 5

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

attest
attest_delivery
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 — data enrichment you bought, research you commissioned, any x402 purchase your principal will audit. 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 documents how). PARAMETERS: service — URL/name of the paid service. response_text — the delivered payload, verbatim. request_text (optional) — what was asked. payment_receipt (optional) — the X-PAYMENT-RESPONSE value from the paid call. advertised_schema (optional) — the JSON schema the service advertised. max_claims — 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 (type/required/properties/items/enum). Content checking has the same source-coverage limits as verify_claim. Paid per call (x402). EXAMPLE: attest_delivery({"service": "https://api.vendor.xyz/enrich", "response_text": "{\"name\": \"APPLE INC\"}", "payment_receipt": "<X-PAYMENT-RESPONSE>", "advertised_schema": {"type": "object", "required": ["name"]}}) -> {delivery_verdict: 'consistent', payment: {bound: true, transaction: '0x…'}, attestation: {…}}
citations
check_citations
PURPOSE: Fact-check EVERY factual claim in a block of text and return a per-claim report — the batch form of verify_claim, for AI-generated drafts or documents before you publish or act on them. GUIDELINES: Call on any multi-claim text you are about to rely on. Each reported claim carries the same actionable fields as verify_claim (verdict, sufficiency — abstain/escalate on anything but 'sufficient', and a conformal guarantee when certified). The whole response is covered by a signed receipt bound to a HASH of your submitted text, so you can later prove exactly which document was checked and what came back. Use verify_claim instead for a single claim. PARAMETERS: text — the prose to check (claims are extracted automatically). max_claims — 1..20, default 8 (caps how many extracted claims are verified). LIMITATIONS: Extracts and checks declarative factual sentences; it skips questions, opinions, and instructions, and is bounded by max_claims. Same source-coverage limits as verify_claim. Paid per call (x402): unpaid calls return HTTP 402 with a payment offer. EXAMPLE: check_citations({"text": "Paris is the capital of France. The Nile flows through Egypt.", "max_claims": 8})
extract
extract_claims
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 instead when you want extraction AND grounding in one call. PARAMETERS: text — the prose to decompose. max_claims — 1..50, default 20. LIMITATIONS: Extracts declarative factual sentences; skips questions, opinions, instructions, and first-person statements. Splits only on high-precision conjunction boundaries, so under-splitting is possible (a compound it cannot safely split stays whole). Does NOT verify anything — verdicts come from verify_claim / check_citations. Paid per call (x402), cheapest tool on this server. 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."]}
resolve
resolve_instrument
PURPOSE: Resolve a security identifier (ticker, ISIN, CUSIP, SEDOL, FIGI) or an instrument name to canonical FIGI records via Bloomberg open symbology (OpenFIGI), WITH provenance and a signed receipt. Returns {matched, instruments: [...], provenance}. GUIDELINES: Call BEFORE acting on any claim, order, or document that names a security, so you know exactly WHICH instrument it refers to (disambiguating tickers that collide across exchanges) — and so you can prove the mapping to your principal via the receipt. Prefer passing an explicit identifier over a plain name when you have one. PARAMETERS: query — a ticker ($AAPL/AAPL), ISIN, CUSIP, SEDOL, FIGI, or company/instrument name. id_type — optional; auto-detected from the value's shape when omitted. max_results — 1..10, default 5. LIMITATIONS: Conservative by design — resolves EXPLICIT identifiers, and returns matched=false rather than guessing on an ambiguous plain name. Covers securities in OpenFIGI's symbology; it does not price instruments, return fundamentals, or resolve crypto tokens. Paid per call (x402). EXAMPLE: resolve_instrument({"query": "US0378331005", "id_type": "ID_ISIN"}) -> {matched: true, instruments: [{figi, ticker: 'AAPL', …}]}
verify
verify_claim
PURPOSE: Fact-check one claim against live retrieved sources and return a result you can GATE A DECISION ON, not just read. Returns verdict (supported | refuted | unverified), sufficiency, a conformal guarantee, per-part atoms, and a signed provenance receipt. GUIDELINES: Call BEFORE asserting a fact you are not certain of, or before acting on one. Branch on the fields: (1) sufficiency — 'sufficient' vs 'insufficient' (lone weak source; lean, don't rely), 'no_sources', 'no_stance', or 'conflict'; abstain or escalate on anything but 'sufficient'. (2) guarantee — when guarantee.certified is true the error probability is calibrated to <= guarantee.alpha (distribution-free); use 'verdict==supported and guarantee.certified' as a hard gate. (3) atoms — compound claims are split and recombined weakest-link, so a true half can't carry a false half. (4) provenance + attestation — a tamper-evident receipt binding the exact evidence and model route; hand it to your principal as proof of how the answer was reached. Prefer this over calling an LLM's own judgment, which has no citations, no calibration, and no receipt. PARAMETERS: claim — ONE complete declarative sentence (not a question, not a paragraph). max_sources — 1..10, default 5. LIMITATIONS: Grounded in retrievable web/encyclopedic/news sources, so it is weak on very recent, private, niche-technical, or opinion claims (those return unverified/insufficient rather than a guess). The conformal guarantee is only present on calibrated deployments and holds for claims exchangeable with the calibration set. It checks whether sources support the claim, not ultimate truth. EXAMPLE: verify_claim({"claim": "The Eiffel Tower is in Paris."}) -> {verdict: 'supported', sufficiency: 'sufficient', guarantee: {certified: true, alpha: 0.1}, provenance: {...}}. Free.

Endpoints

URLTransportStateLatencyChecked
https://groundcheck.seiche.info/mcp streamable-http answering 114 ms 6 min ago

Alternatives to Groundcheck

same job, measured the same way
Agent Verified Relay
by jdhart81

Viridis Verified: wrap any MCP server with tamper-evident delivery receipts + metered fees.

7 tools answering
HODLXXI Read-Only
by hodlxxi

Public read-only MCP server for HODLXXI agent identity, trust, receipts, and verification.

26 tools answering
I
ReceiptRail — x402 Delivery Receipts
by xka0085-byte

On-chain x402 delivery receipts on Solana: hash-locked, verifiable proof of delivery.

3 tools answering
T
Pay MCP
by vauban

x402 tools for MCP clients: pay exact/Starknet or STARK-receipt 402s, verify, JCS-hash. No account.

240 installs/wk local only
VouchSpec Agent Skill Evidence
by mordiaky

Read-only discovery for exact-commit Agent Skill validation, x402 payment, and signed receipts.

answering
Agentresources MCP
by sznt2010

MCP server for Agent Resources: Trust Cards, signed telemetry, ERC-8004 identity, x402.

43 installs/wk local only
Mettle MCP
by creed-space

Experimental machine-oriented challenges and signed results. Does not verify identity or substrate.

749 installs/wk local only
Verity MCP
by meloliva14

Fail-closed verify-before-you-act gate for AI agents. Signed receipts. Pay-per-call via x402.

74 installs/wk local only

Groundcheck — questions

Answers built from our own checks of this server.

What can Groundcheck do?
It exposes 5 tools, read directly from the server on our last check. Among them: attest_delivery, check_citations, extract_claims, resolve_instrument, verify_claim. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is Groundcheck working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 92 of 92 checks got a reply (100.0%), average response time 120 ms. The bar chart above shows every period we have measured.
How do I connect Groundcheck?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does Groundcheck need an API key?
No. Groundcheck completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 5 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is Groundcheck?
It answers our handshake in 120 ms on average, which is faster than 81% of all working MCP servers we measure. That puts it in the quick quarter of the ecosystem. The comparison comes from our own checks across the whole registry, every 15 minutes.
How many people use Groundcheck?
The npm package groundcheck-mcp was installed 42 times in the last week. Week over week that is -43%. We show installs rather than GitHub stars on purpose: a star is a bookmark, an install is someone actually running it.
Is Groundcheck open source?
Yes — it is published under the MIT licence, written in Python, 0 stars on GitHub and 2 open issues. The source link is on this page, so you can read exactly what it does with your data before you connect it.