一个 MCP 连接器，用于检查某个主张的依据是否真实——引文确实在页面上、arXiv id 能解析、代码确实打印了声称的内容、数字是正确的——在验证路径中没有任何语言模型。适用于任何 MCP 宿主：Claude、Gemini 或其他。
如今内置在助手里的每一次"事实核查"最终都是问第二个模型第一个模型是否正确。这并没有验证任何东西——它只是转移了错误，因为检查者也会产生幻觉。真正困难且少有人尝试的是基于现实而非另一个模型意见的验证。这个工具做的就是这件事，而且只做这件事。
诚实地说明范围，因为过度声称会违背初衷。 Groundcheck 确认主张所依赖的证据是真实的，并且确实如引述所说。它不判断主张在语义上是否真实——"这段引文在引用的页面上"是可检查的；"该页面的论证是正确的"则不可检查，再多的假装也无济于事。每个工具返回三种判定之一，并且宁可返回 unverifiable 也不猜测：
verdict | meaning |
| 依据已对照真实来源确认 |
| 来源存在且与主张矛盾（数字错误、引文缺失、id 失效、代码失败） |
| 没有来源，或需要本工具拒绝伪造的判断 |
Related MCP server: math-logic-mcp
tool | verifies | how (no LLM) |
| 精确引文在页面上 | 获取页面，匹配文本 |
| arXiv id 或 DOI 可解析 | 查询 arXiv / Crossref，返回真实标题 |
| 代码打印了声称的内容 | 在子进程中运行，比较 stdout |
| 字符串/正则表达式在代码库中 | grep 文件，返回真实匹配行 |
| 算术正确 | 求值 AST（不用 |
每个结果都是 {status, method, evidence, detail}——evidence 是找到的具体事物（引文、stdout、匹配行、计算值），因此判定是可审计的，而不是黑盒。
check_citation 的存在是因为看似合理但伪造的 arXiv id 不断溜进研究文稿——一个看起来正确却解析不到任何东西的 id。check_math 的存在是因为硬件演示文稿中把 3.7 × 1400 写成了 8880（实际是 5180）。check_repo 是个人资料 README 主张检查器的泛化，该检查器对照来源仓库验证每一个引用的数字。每个工具都是一次真实发生的失败，被转化成了检查。
有一个值得报告的诚实小插曲：在测试时，我假设 arXiv 2606.01992 是伪造的，预期返回 refuted——工具返回了 checked。工具是对的，我错了：这是一篇真实的 2026 年 6 月论文。验证器在我自己的错误假设面前完成了它的工作，这正是将验证基于来源而非直觉的全部意义。
pip install -e . # or: pip install -r requirements.txt
python -m pytest tests/ # 18 tests, no network needed (mocked transport)Claude / Claude Code — 添加到你的 MCP 配置：
{
"mcpServers": {
"groundcheck": { "command": "python", "args": ["-m", "src.groundcheck.server"] }
}
}Gemini CLI / 任何 MCP 宿主 — 相同的 stdio 服务器；将宿主的 MCP 配置指向 python -m src.groundcheck.server。MCP 正是让一个连接器同时服务两者的原因。
check_code 会执行你给它的代码，在子进程中。它使用列表形式的 subprocess（无 shell，因此没有可注入的内容）并在超时时终止，但不与网络或文件系统隔离。只传入你自己会运行的代码。其他四个工具是只读的（HTTP GET、文件读取、算术）。
依据，而非真相。 有意为之——见上文"范围"。
引文匹配是精确的（空白规范化后）。 意思相同的转述会返回 refuted，因为"意思相同"需要判断者，而判断者正是本工具拒绝充当的角色。匹配字面文本。
JS 渲染的页面。 check_quote 读取服务器提供的 HTML；由客户端 JavaScript 注入的引文不会被找到。它会安全失败（refuted），绝不会误报 checked。
仅支持 arXiv/Crossref 的引文。其他注册表尚未接入。
MIT — 见 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.
