Skip to main content
Glama

groundcheck

by io.github.beepboop2025

Verify one claim (free)

verify_claim
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
claimYesThe factual claim as ONE complete declarative sentence (not a question or a paragraph).
max_sourcesNoHow many sources to retrieve and weigh (1-10).

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses significant behavioral traits: compound claims are split and recombined weakest-link, the conformal guarantee only exists on calibrated deployments, and the tool checks source support rather than ultimate truth. This provides context that annotations alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear labeled sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). Each section adds unique value, though it could be tightened. The structure aids scanning and comprehension, earning a 4 rather than 3.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description fully explains the return fields (verdict, sufficiency, guarantee, atoms, provenance) and provides a concrete example. It also covers limitations and usage guidance, making it complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes both parameters (claim as a single declarative sentence, max_sources 1-10 default 5). The description's PARAMETERS section restates these constraints but does not add new semantics beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Fact-check one claim against live retrieved sources and return a result you can GATE A DECISION ON'. It specifies the verb (fact-check), resource (one claim), and outcome (verdict with guarantee and provenance). It also distinguishes itself from an LLM's own judgment, making its unique value explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The GUIDELINES section provides explicit when-to-use: 'Call BEFORE asserting a fact you are not certain of, or before acting on one.' It also explains how to interpret the result via sufficiency and guarantee, and offers an alternative by recommending 'Prefer this over calling an LLM's own judgment'. Limitations further clarify when not to use it, such as for very recent or private claims.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All groundcheck toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: claim verification (single vs batch), claim extraction, identifier resolution, and delivery attestation. The batch vs single claim tools are distinguished by input granularity, resolving any potential confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (attest_delivery, check_citations, extract_claims, resolve_instrument, verify_claim). This predictable convention makes the tool set easy to navigate.

Tool Count5/5

Five tools is well-scoped for a verification/attestation service. Each tool covers a distinct stage (extract, verify, attest, resolve) without redundancy or bloat.

Completeness5/5

The tool set provides complete coverage of the verification workflow: extraction (extract_claims), single and batch verification (verify_claim, check_citations), identifier resolution (resolve_instrument), and delivery attestation (attest_delivery). Signed receipts enable offline verification, leaving no obvious gaps.

Resources