Provides tools to verify factual claims by retrieving information from Wikipedia, classifying stance, and returning a verdict with citations.
Click on "Install 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.
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: {…}}.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | URL (or name) of the paid service whose delivery is being verified. | |
| maxClaims | No | Max claims in the delivered content to ground (1-20). | |
| requestText | No | What was asked of the service (optional; bound by hash when given). | |
| responseText | Yes | The delivered payload, verbatim (JSON or prose). | |
| paymentReceipt | No | x402 settlement receipt from the paid call (X-PAYMENT-RESPONSE / PAYMENT-RESPONSE value, base64 or raw JSON). | |
| advertisedSchema | No | JSON schema the service advertised for its output (from its 402 offer or Bazaar listing). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it judges only consistency (not service quality), records payment receipt but requires separate on-chain confirmation, and notes that schema conformance is structural. It also mentions the paid nature of the hosted engine and links to documentation for verification.
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?
The description is well-structured with labeled sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE) and front-loaded key points. Though slightly long, every sentence adds value and there is no redundancy.
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?
Despite lacking an output schema, the description thoroughly explains the return types (delivery_verdict, payment binding, attestation) and notes that the full response is a self-contained dispute artifact. It also provides example output and mentions the need to save it, ensuring completeness for an agent.
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%, but the description goes beyond by explaining each parameter's role in context (e.g., responseText is 'the delivered payload verbatim', paymentReceipt is 'X-PAYMENT-RESPONSE value'). An example call further clarifies how to use the parameters together.
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 clearly states the tool's purpose as 'Neutral delivery verification for agentic commerce.' It specifies that it verifies delivered content and returns a signed receipt binding payment to delivery to content. This distinguishes it from siblings like verify_claim, as it focuses on delivery integrity rather than fact-checking.
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 gives explicit usage instructions: 'call AFTER a paid third-party call whose output you will act on or account for.' It provides branching logic based on delivery_verdict (consistent -> proceed, degraded -> caution, inconsistent -> do not rely, unverifiable -> no contradiction). It also advises saving the receipt for dispute evidence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a Markdown badge to embed in a README or report, signalling the content was checked with Groundcheck.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description is brief and does not disclose any side effects, permissions, or limitations, but simple badge generation likely non-destructive.
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?
Single sentence with no unnecessary words, front-loading the action and purpose.
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?
For a zero-parameter, no-output-schema tool, the description covers purpose and embedding context, though exact Markdown format is unspecified.
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?
Input schema has zero parameters with 100% coverage; description adds no param info, baseline per rules is 4.
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 clearly states the tool returns a Markdown badge for embedding, signaling content checked with Groundcheck, distinguishing it from sibling tools.
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 mentions embedding in README/report, providing usage context, though no explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text whose factual claims should be checked. | |
| maxClaims | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries full burden. It discloses that the tool returns a per-claim report with verdict, sufficiency, and a conformal guarantee, plus a signed receipt. It also mentions limitations. However, it does not explicitly state if the tool is read-only or destructive, though the nature of fact-checking implies read-only.
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?
The description is well-structured with labeled sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS) and is concise, packing essential information into a short paragraph without redundancy.
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?
Given no output schema and no annotations, the description covers purpose, usage, parameters, limitations, and distinguishes from siblings. It includes details about the return format and receipt, which is sufficient for most use cases. The only minor gap is not specifying the exact structure of the claim report beyond verdict and sufficiency.
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 adds context to the schema: 'text = the prose (claims extracted automatically)' and reiterates the range for maxClaims. Since schema coverage is 50%, the description compensates by clarifying the meaning of 'text' and that claims are extracted automatically.
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 clearly states the verb (fact-check), resource (claims in a block of text), and explicitly distinguishes from the sibling verify_claim by noting it is the batch form. It also specifies the use case: AI-generated drafts before publishing.
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 provides explicit guidance on when to use the tool ('before you publish or act'), when not to ('Use verify_claim for a single claim'), and details limitations such as skipping questions/opinions and maxClaims bounds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.']}.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to split into independently checkable atomic factual claims. | |
| maxClaims | No | Max claims to return (1-50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses rule-based, deterministic extraction, limitations (skips non-factual statements, under-splitting), and payment model. No contradictions with 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?
Well-structured with clear sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). Every sentence adds value, front-loaded with purpose and usage.
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?
Complete for a 2-parameter tool without output schema. Explains return format, limitations, example, and payment context. No gaps.
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 coverage is 100% and description adds usage context (maxClaims range, default, example). Minimal extra semantics beyond schema, so slight deduction from perfect.
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 explicitly states the purpose as splitting text into atomic factual claims for verification loops. It uses specific verbs and resources and distinguishes from sibling tool check_citations.
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?
Provides clear guidance on when to use (e.g., before grounding, for budgeting, proving claims) and explicitly names check_citations as an alternative for combined extraction and grounding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'}).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Ticker, ISIN, CUSIP, SEDOL, FIGI, or instrument name. | |
| idType | No | Identifier type; auto-detected from the value's shape when omitted. | |
| maxResults | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully compensates: discloses conservative matching ('matched=false' rather than guessing), states it does not price instruments or resolve crypto, and mentions return includes 'provenance and a signed receipt'. Very transparent.
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?
Highly structured with clear sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). Each sentence adds value, no fluff. Efficient and well-organized.
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?
Comprehensive for a resolution tool with no output schema: describes what is returned (FIGI records, provenance, receipt) and limitations (no pricing, no crypto). Covers all essential aspects for correct invocation.
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 has 67% coverage; description adds meaningful context for all 3 parameters: explains `query` purpose, notes `idType` auto-detection, and specifies range and default for `maxResults`. Goes beyond schema info.
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?
Clearly states the verb 'resolve' and resource 'security identifier to canonical FIGI records via OpenFIGI'. Distinguishes from sibling tools by focusing on instrument resolution and disambiguation.
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?
Explicitly advises to call 'BEFORE acting on any claim, order, or document', explains why (disambiguation, provenance), and suggests preferring explicit identifiers. Provides clear context for when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.'}).
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The factual claim to verify, written as one complete sentence. | |
| maxSources | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns verdict, sufficiency, guarantee, per-part atoms, and receipt. Explains weakest-link splitting, limitations on recent/private claims, and guarantee only on calibrated deployments.
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?
Well-structured with labeled sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). Every sentence adds value, no redundancy.
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?
Despite no output schema, description details all return fields and how to use results (e.g., gate on sufficiency and verdict). Limitations and example make it complete for agent use.
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 coverage is only 50% (maxSources missing description). Description adds critical detail: claim must be 'ONE complete declarative sentence' and maxSources range 1-10 with default 5, exceeding schema info.
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?
Description starts with 'PURPOSE: Fact-check one claim against live sources' and lists specific outputs. Clearly distinguishes from sibling tools like check_citations and extract_claims by focusing on verification with a gate-ready result.
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?
Explicit guidelines: 'Call BEFORE asserting or acting on a fact you are unsure of' and 'Prefer over an LLM's own judgment'. Also provides conditions for abstaining and gating decisions.
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. Dates show when Glama detected each change.
v0.1.0attest_deliveryattribution_badgecheck_citationsextract_claimsresolve_instrumentverify_claimEach 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.
Cross-check a factual claim against a verified knowledge graph before you assert it. Never guesses.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/beepboop2025/groundcheck'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
