Un conector MCP que comprueba si la fundamentación de una afirmación es real — que la cita está de verdad en la página, que el id de arXiv se resuelve, que el código imprime lo que se dice que imprime, que el número es correcto — sin ningún modelo de lenguaje en ninguna parte de la ruta de verificación. Funciona en cualquier host de MCP: Claude, Gemini, u otro.
Todo «fact-check» integrado hoy en un asistente acaba pidiéndole a un segundo modelo si el primero tenía razón. Eso no verifica nada — reubica el error, porque el verificador también alucina. Lo verdaderamente difícil y poco intentado es la verificación fundamentada en la realidad y no en la opinión de otro modelo. Eso es todo lo que hace, y solo hace eso.
Alcance, declarado con honestidad, porque exagerar iría en contra del propósito. Groundcheck confirma que la evidencia en la que se apoya una afirmación es real y que dice aquello que se le atribuye. No juzga si una afirmación es semánticamente verdadera — «esta cita está en la página citada» es comprobable; «el argumento de la página es correcto» no lo es, y ningún fingimiento lo convertirá en comprobable. Cada herramienta devuelve uno de tres veredictos, y dice unverifiable en lugar de adivinar:
veredicto | significado |
| la fundamentación se confirmó contra una fuente real |
| la fuente existe y contradice la afirmación (número incorrecto, cita ausente, id muerto, código que falla) |
| no hay fuente, o requiere un juicio que esta herramienta se niega a falsear |
Related MCP server: math-logic-mcp
herramienta | verifica | cómo (sin LLM) |
| que una cita exacta está en una página | obtener la página, comparar el texto |
| que un id de arXiv o un DOI se resuelve | consultar arXiv / Crossref, devolver el título real |
| que el código imprime lo que se afirma | ejecutarlo en un subproceso, comparar stdout |
| que una cadena/regex está en una base de código | hacer grep en los archivos, devolver las líneas reales que coinciden |
| que la aritmética es correcta | evaluar un AST (sin |
Cada resultado es {status, method, evidence, detail} — evidence es el elemento concreto encontrado (la cita, el stdout, la línea coincidente, el valor calculado), de modo que un veredicto es auditable, no una caja negra.
check_citation existe porque ids de arXiv falsos pero verosímiles seguían colándose en los artículos de investigación: un id que parece correcto y que no se resuelve a nada.
check_math existe porque 3.7 × 1400 se escribió como 8880 en una presentación de hardware (es 5180).
check_repo es la generalización de un verificador de afirmaciones de README de perfil que comprueba cada número citado contra su repositorio de origen. Cada herramienta es un fallo que ocurrió de verdad, convertido en una comprobación.
Hay un detalle honesto que merece la pena contar: mientras probaba, supuse que el arXiv 2606.01992 era inventado y esperaba refuted — la herramienta devolvió checked. La herramienta tenía razón y yo estaba equivocado: es un artículo real de junio de 2026. El verificador hizo su trabajo contra mi propia suposición errónea, que es precisamente la razón de fundamentar la verificación en una fuente y no en una corazonada.
pip install -e . # or: pip install -r requirements.txt
python -m pytest tests/ # 18 tests, no network needed (mocked transport)Claude / Claude Code — añádelo a tu configuración de MCP:
{
"mcpServers": {
"groundcheck": { "command": "python", "args": ["-m", "src.groundcheck.server"] }
}
}Gemini CLI / cualquier host de MCP — el mismo servidor stdio; apunta la configuración de MCP de tu host a python -m src.groundcheck.server. MCP es la razón por la que un solo conector sirve para ambos.
check_code ejecuta el código que le des en un subproceso. Usa subprocess en forma de lista (sin shell, así que no hay nada que inyectar) y lo mata al agotarse el tiempo de espera, pero no está aislado de la red ni del sistema de archivos. Pásale solo código que ejecutarías tú mismo. Las otras cuatro herramientas son de solo lectura (HTTP GET, lectura de archivos, aritmética).
Fundamentación, no verdad. Por diseño — ver el Alcance más arriba.
La coincidencia de citas es exacta (normalizada por espacios en blanco). Una paráfrasis que signifique lo mismo devuelve refuted, porque «significar lo mismo» necesita un juez, y un juez es justo lo que esta herramienta se niega a ser. Haz que coincida el texto literal.
Páginas renderizadas con JS. check_quote lee el HTML servido; una cita inyectada por JavaScript del lado del cliente no se encontrará. Falla de forma segura (refuted), nunca un checked falso.
Solo arXiv/Crossref para citas. Otros registros aún no están conectados.
MIT — consulta LICENSE.
Verify that an arXiv id or DOI actually resolves, and return its real title.
Pass an arXiv id (e.g. '2412.18004' or 'arXiv:2412.18004') or a DOI. A 'checked' verdict includes the genuine title, so a plausible-looking but fabricated identifier is caught as 'refuted'.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose meaningful output semantics: a 'checked' verdict returns the genuine title, while a fabricated identifier yields 'refuted'. That verdict vocabulary is genuinely useful, but failure modes (network errors, malformed input handling, latency) are not mentioned.
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?
Three sentences, front-loaded with the core action; the second covers input format and the third covers the verdict semantics. No filler, and each sentence adds information an agent needs.
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?
No output schema and no annotations means the description must cover both input and response semantics, which it largely does via the checked/refuted verdict explanation. It is nearly complete for a one-parameter tool, though it omits what happens on unresolvable-but-valid-looking edge cases or errors.
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 schema has 0% description coverage for its single parameter, so the description must compensate, and it does: it names the parameter concept (arXiv id or DOI) and supplies two concrete arXiv formats plus DOI acceptance. This covers the practically important format ambiguity even though it doesn't specify a DOI example.
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?
States a specific verb (verify) and resource (arXiv id or DOI), plus a secondary outcome (return its real title). The verification framing clearly distinguishes it from siblings like check_quote, check_code, check_repo and check_math, which each target a different artifact type.
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 establishes the trigger condition (you have an identifier that may be fabricated) and the motivation for using it. It gives concrete accepted input formats, but never names an alternative tool or states when NOT to use this one, so it falls short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a self-contained Python snippet and confirm its stdout contains
expected_output.
WARNING: this executes the code. Only pass code you would run yourself; it is not sandboxed from the network or filesystem. Returns refuted if the snippet errors or prints something other than claimed.
| Name | Required | Description | Default |
|---|---|---|---|
| snippet | Yes | ||
| expected_output | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it warns that the code is actually executed, that it is not sandboxed from the network or filesystem, and it defines the failure semantics ('returns refuted if the snippet errors or prints something other than claimed'). These are the exact behavioral traits an agent needs before invoking an execution tool.
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?
Three tight sentences, front-loaded with the primary action, then the safety warning, then the return contract. No filler; each sentence adds information an agent would otherwise have to guess.
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?
No output schema exists, and the description covers the most important return case (refuted on error or mismatched output), which is enough to call the tool correctly. It does not state what a successful result looks like or whether it echoes the actual stdout, a small gap for a verification tool.
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 0% (no parameter descriptions at all), so the description must compensate, and it largely does: 'self-contained Python snippet' scopes the snippet, and 'confirm its stdout contains expected_output' establishes that expected_output is a substring-containment match rather than an exact-match string. A few details (encoding, trailing newline handling) remain unspecified.
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?
States a specific operation (run a self-contained Python snippet), the verification contract (confirm stdout contains expected_output), and does so in terms that clearly separate it from check_quote, check_citation, check_repo, and check_math. An agent can select it without opening the schema.
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?
Usage guidance is implicit: 'self-contained Python snippet' and 'Only pass code you would run yourself' define the context of appropriate use, but there is no explicit statement of when to prefer this over a sibling (e.g. check_math for pure arithmetic) or when not to use it. Adequate but leaves selection against alternatives to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm an arithmetic expression equals a claimed result.
Evaluates expression (numeric literals and + - * / // % ** only) and
compares to claimed_result. Catches arithmetic a model asserted without
computing.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | ||
| claimed_result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full disclosure burden. It usefully constrains the accepted input domain to numeric literals and the operators + - * / // % **, which tells the agent what will fail, but it never states the return shape, error behavior for malformed expressions, or numeric precision handling.
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?
Two short sentences, purpose front-loaded, with the operator whitelist as precise supporting detail. Every clause earns its place; nothing is padded or redundant.
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 two-parameter verification tool with no output schema, the description conveys purpose, input constraints, and the intent of the check (catching uncomputed claims), which is enough to call it correctly. The exact response format is only implied rather than stated, which is the one remaining gap.
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 0%, so the description must compensate, and it does: it names both parameters and defines what `expression` may contain (numeric literals and a specific operator set) and what `claimed_result` is compared against. It could go further on numeric formats or edge cases, but it adds real meaning over the bare schema titles.
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?
States a specific verb ('confirm') and resource ('arithmetic expression equals a claimed result'), and the math domain cleanly separates it from the check_quote/check_citation/check_code/check_repo siblings. An agent can route to it without inspecting the schema.
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?
'Catches arithmetic a model asserted without computing' gives a clear triggering context — verifying a numeric claim rather than trusting it. It stops short of explicit when-not-to-use guidance or naming alternatives (e.g. using a real computation tool for symbolic math), so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that an exact quote appears on a web page.
Fetches url and confirms quote is present in its visible text. Use before
attributing a statement to a source. Returns refuted if the page loads but
the quote is absent -- i.e. the attribution is fabricated.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| quote | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the tool performs a network fetch, that matching is against visible text rather than raw HTML, and that a loaded page without the quote yields a "refuted" verdict meaning the attribution is fabricated. It omits failure-mode behavior (page fails to load), auth, and rate limits.
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?
Three short sentences, front-loaded with the core action, then the mechanism, then the usage trigger, then the failure semantics. No wasted wording.
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?
No output schema exists, so the description appropriately explains the return verdict, including what "refuted" means. It leaves the success verdict and load-failure behavior implicit, which is a small but real gap for an agent interpreting results.
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 0%, so the description must compensate, and it does: `url` is defined as the fetched target and `quote` as the exact string matched against the page's visible text. It still leaves ambiguity about matching strictness (case, whitespace, normalization) and accepted URL forms.
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?
Specific verb+resource: verifies that an exact quote appears on a fetched web page. This clearly distinguishes it from siblings like check_code, check_repo, and check_math, which all verify different artifact types.
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?
"Use before attributing a statement to a source" gives a clear situation for invocation, and the resource-based framing naturally separates it from the other check_* tools. No explicit alternative is named, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm that a string (or regex) actually occurs in files under a local path.
Use to verify a claim about what a codebase or document contains -- 'the README reports 0.9086', 'the function is defined in src/' -- rather than trusting the assertion. Returns the real matching lines.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| regex | No | ||
| pattern | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses that the tool returns the real matching lines and that it is a verification/read operation, but it omits operational traits such as permission needs, path recursion behavior, or what happens on no match.
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?
Two tight paragraphs, front-loaded with the core action and followed by the use case and return behavior. No filler sentences, though the examples could be trimmed slightly.
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 three-parameter tool with no annotations and no output schema, the description covers purpose, use case, and return content. It still leaves path semantics and no-match/error behavior unspecified, which an agent would need to call it confidently.
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 0%, so the description must compensate. It partially does: 'a string (or regex)' maps to pattern plus the regex flag, and 'under a local path' maps to path. However, it never explains path format (absolute vs relative, file vs directory) or that regex defaults to false.
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 states a specific verb and resource: confirm that a string or regex occurs in files under a local path. The scope (local filesystem content) implicitly separates it from siblings like check_citation, check_math, and check_quote, though it never names them explicitly.
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?
It gives clear usage context — verify a claim about what a codebase or document contains rather than trusting an assertion — and supplies concrete examples ('the README reports 0.9086'). No explicit when-not conditions or named alternative tools are provided.
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.
v0.1.0check_citationcheck_codecheck_mathcheck_quotecheck_repoScored across 5 tools
Each tool verifies a distinct artifact type: web-page quote, arXiv/DOI identifier, Python snippet output, local repo content, and arithmetic. The input types and returned verdicts differ clearly, so an agent can pick the right tool without overlap.
All five tools follow an identical check_<noun> pattern (check_quote, check_citation, check_code, check_repo, check_math). This is a fully predictable, uniform convention.
Five tools is well-scoped for a claim-verification server, with each tool earning its place by covering a different source of unverified assertions. No redundancy or filler.
The surface covers the main verification targets (quotes, citations, code, repo contents, math) and returns actionable verdicts. Minor gaps exist, such as no standalone URL-liveness check or batch/multi-source verification, but core workflows are covered.
Experimental MCP server for current empirical verification of explicit public HTTPS endpoint claims.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Unified 15-tool SEO, SERP, clean Markdown & GEO (LLM citation Share-of-Voice) MCP server.
