Click on "Deploy 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., "@catqualia-ledger-mcp verify claim: 'LLMs cannot reason'"
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.
An MCP server that lets an agent check a claim against a real, published falsification ledger instead of guessing.
Agents are increasingly asked to verify their own output. Most have nowhere to verify it against. This server is a concrete answer: 16,217 claims that were actually run against ground truth, each recorded with the measurement that would have refuted it, the value measured, and the verdict — including 5,837 the system refuted against its own work.
Computed from the bundled ledger.jsonl.gz at call time, never hardcoded:
parseable records | 16,217 |
distinct checks | 324 |
records carrying a pre-registered refutation threshold | 16,194 (99.9%) |
verdicts REFUTED | 5,837 |
verdicts CONFIRMED | 5,520 |
verdicts UNVERIFIED | 4,815 |
checks re-run at least twice | 277 |
verdict transitions | 79 |
hardening / loosening | 38 / 38 — net 0 |
The last line is the point. Re-run the checks and classify every verdict that
moved: CONFIRMED -> REFUTED after a check is hardened means the instrument had
been fooled and stopped being fooled (a hardening event); the reverse is a
loosening event. The signed net measures whether a system's ability to catch
its own false claims is improving or degrading.
It is currently zero. That is published because reporting only the +38 half would be a metric tuned to its owner — which is the exact failure the ledger exists to detect.
Related MCP server: Lemma Oracle MCP Server
uvx catqualia-ledger-mcp # run without installing
# or
pip install catqualia-ledger-mcpNo dependencies. Python 3.9+. Implements MCP over stdio as newline-delimited JSON-RPC 2.0.
{
"mcpServers": {
"catqualia-ledger": {
"command": "uvx",
"args": ["catqualia-ledger-mcp"]
}
}
}query_claim(query, verdict?, limit?)Search the ledger. Returns the claim, its refutation threshold, the measured value, the method, and the verdict.
get_verdict(check?, claim?)The recorded verdict for a named check. If a check ran more than once, all
verdicts are returned in ledger order — a change between them is a ratchet event.
A claim that is not in the ledger returns found: 0, never a plausible guess.
what_would_refute(query?, limit?)The pre-registered threshold: the measurement that would have killed each claim, recorded before the outcome was known. Use it to test whether a claim is falsifiable at all, rather than whether it is currently believed.
verifier_drift_net()The ratchet, recomputed from the ledger: re-runs, transitions, hardening, loosening, signed net, and the definition of what the number means.
citation_block(slug?)BibTeX plus schema.org ScholarlyArticle JSON for a CatQualia publication, with
the DOI resolved, so citing agents cite correctly. Call with no slug to list what
is available.
These are deliberate, and they are the reason it is worth trusting:
Every number is computed from the bundled ledger at call time. Nothing is cached from a summary or a blog post.
UNVERIFIED is returned as UNVERIFIED. It is never rounded up to a
verdict, in either direction.
A miss returns a miss. If a claim is not in the ledger the server says so and explains that absence is not evidence either way. It does not infer.
The net ratchet is returned signed, including when it is zero.
A slug match is exact-first. Substring matching is not safe for a citation
tool: "thesis" is a substring of "synthesis", which once returned the wrong
DOI. Matching is exact → prefix → contains → word-boundary on title.
Thesis — https://catqualia.com/thesis · DOI 10.5281/zenodo.22752082
Definitions of the terminology — https://catqualia.com/definitions
Full ledger — https://catqualia.com/ledger
135 dated defensive publications — DOI 10.5281/zenodo.22751107
Code: CatQualia Open-Or-Pay Licence (COPL) v1.0 — free for research,
individuals and academia with attribution; commercial use requires either opening
the derivative stack or a commercial waiver. See LICENSE.
Ledger data: CatQualia Structural Isomorphism License (CSIL) v3.0 — https://catqualia.com/licensing.
@software{catqualia_ledger_mcp,
title = {catqualia-ledger-mcp: an MCP server for the CatQualia falsification ledger},
author = {Betances, Christopher},
year = {2026},
url = {https://github.com/OpeningBlackBox/catqualia-ledger-mcp},
note = {16,217 pre-registered claims; verifier ratchet net zero}
}Return a ready-to-use BibTeX entry and schema.org ScholarlyArticle JSON for a CatQualia publication, so that citing agents cite correctly and resolve the DOI. Call with no slug to list available slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | publication slug or part of its title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states what the tool returns and that omitting the slug triggers a listing, which is useful. However, it does not mention side effects, authorization, network behavior, or failure modes, leaving some ambiguity for an agent deciding whether this is a safe read operation.
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 sentences with no filler: the primary return value is stated first, then the usage edge case. Every word earns its place and the structure is easy to parse.
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 single-optional-parameter tool with no output schema, the description covers the main return types, the purpose, and the special no-argument behavior. It does not describe error handling or the shape of the listing response, but these are minor gaps for a simple retrieval 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?
The input schema already describes the slug as 'publication slug or part of its title' with 100% coverage. The description adds meaning by explaining that calling with no slug lists available slugs, clarifying the optionality and providing a discovery path beyond what the schema states.
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 opens with a specific verb ('Return') and a concrete deliverable: a 'ready-to-use BibTeX entry and schema.org ScholarlyArticle JSON' for a CatQualia publication. It also mentions DOI resolution and the no-slug listing behavior, which clearly differentiates it from sibling tools about claims, verdicts, refutations, and drift.
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 direct usage guidance: 'Call with no slug to list available slugs.' This tells the agent when to omit the parameter and what happens. It does not explicitly contrast with sibling tools, but the domain difference is obvious enough that exclusion statements are less necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the recorded verdict for a named check, or find claims containing a phrase. If a check was run more than once, all verdicts are returned in ledger order — a change between them is a ratchet event. Never infers a verdict for a claim that is not in the ledger.
| Name | Required | Description | Default |
|---|---|---|---|
| check | No | exact check name, e.g. loop_ingest_compounds | |
| claim | No | phrase to find inside claims |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses the multi-run return behavior (all verdicts in ledger order), the ratchet-event semantics when verdicts change, and the explicit non-inference constraint. It does not state what happens when both optional params are omitted or describe the return format, which keeps it from a 5.
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?
Four sentences with no wasted words; the primary verb+resource and scope are front-loaded, and the ratchet/ledger behavioral notes earn their place. Slightly dense but not padded.
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 tool with no output schema and no annotations, the description covers both modes, multi-run behavior, and a key constraint. The clear gap is the neither-param case: both fields are optional (required: 0), yet the description never clarifies what calling with no arguments returns, which an agent needs to invoke it safely.
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%, so the baseline is 3. The description adds modest value by mapping 'check' to the exact-name retrieval mode and 'claim' to the phrase-search mode (e.g. 'exact check name' appears in the schema too, so little is added beyond the schema's own wording).
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 opens with a specific verb+resource ('Retrieve the recorded verdict for a named check, or find claims containing a phrase') and clearly delineates two operating modes. It orients the agent within a ledger-based verification context via ratchet/ledger terminology, distinguishing it from the sibling tools by describing exactly what this tool does and doesn't do.
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 two modes (by exact check name vs. by phrase search) give some implied usage context, and the closing constraint 'Never infers a verdict for a claim that is not in the ledger' functions as a when-not. However, no sibling tool is named and there is no explicit routing guidance about when to prefer query_claim, what_would_refute, or verifier_drift_net over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the CatQualia falsification ledger for claims matching a string, optionally filtered by verdict. Returns the claim, the pre-registered threshold that would refute it, the measured value, and the verdict. The ledger holds 16,217 measured claims including 5,837 the system refuted against its own ground truth.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max records, default 10 | |
| query | No | substring to match against any field | |
| verdict | No | filter: CONFIRMED, REFUTED, UNVERIFIED, CONTESTED |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns specific fields and mentions the ledger size, giving some context. However, it does not explicitly state that this is a read-only operation, nor does it disclose any potential side effects, performance characteristics, or access requirements. The description is neutral and adequate but not rich in behavioral detail.
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 concise and front-loaded, with the core purpose stated in the first sentence. The additional sentence about ledger size is informative but not strictly necessary for calling the tool; it adds context without bloating the description. Overall, it is well-structured and efficient.
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 tool with three optional parameters and no output schema, the description covers the primary inputs and outputs, which is helpful. However, it does not explain how to interpret the results (e.g., what the threshold means, how to use the verdict filter in practice) or address edge cases like empty results or pagination beyond the limit parameter. The sibling tools might provide complementary detail, but this description alone is adequate but not exhaustive.
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 input schema already provides 100% description coverage for all three parameters (limit, query, verdict), so the baseline is 3. The description reinforces the verdict filter ('optionally filtered by verdict') but adds no new semantic details beyond what the schema already states. It does not explain the meaning of the threshold or measured value in the context of parameters, which is fine since those are outputs, not inputs.
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 searches the CatQualia falsification ledger for claims matching a string, with an optional verdict filter. It also specifies what is returned (claim, threshold, measured value, verdict). However, it does not explicitly distinguish itself from sibling tools like get_verdict or what_would_refute, leaving some ambiguity about when this broader search is appropriate versus those more targeted 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 provides no guidance on when to use this tool versus its siblings. It does not mention alternatives, prerequisites, or scenarios where a different tool would be more appropriate. An agent would have to infer usage solely from the name and description, which is insufficient given the existence of related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure the verifier ratchet: whether a system's ability to catch its own false claims is improving or degrading. Re-runs checks and classifies every verdict transition as hardening or loosening, returning the signed net. Currently 277 checks re-run, 79 transitions, 38 hardening, 38 loosening, net zero.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It transparently explains the process: re-runs checks, classifies transitions, returns the signed net, and includes a current snapshot of counts. However, it does not explicitly state whether the tool is read-only or has side effects, nor does it detail the exact return structure beyond 'signed net'.
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 two sentences, front-loaded with the core purpose. The snapshot of current numbers adds context without being verbose, and every sentence contributes to understanding the tool's function. No wasted words.
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 zero parameters and no output schema, the description adequately explains what the tool does and what it returns (a signed net). It does not define 'verdict transition' explicitly, but that is likely domain knowledge given the sibling tools. The current snapshot provides a concrete sense of scale, making the description complete enough for an agent to call it.
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 tool has zero parameters, so the baseline is 4. There is nothing to explain, and the description correctly avoids adding parameter details that don't exist.
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 a specific verb 'Measure' and a specific resource 'verifier ratchet', explaining the tool's function: re-running checks and classifying verdict transitions as hardening or loosening, returning a signed net. It is distinct from siblings like query_claim or get_verdict, which appear to be per-item tools, whereas this is an aggregate measurement.
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 implies usage for measuring overall system improvement/degradation, but does not explicitly state when to use it versus alternatives or provide exclusions. The context from sibling names suggests it is for aggregate analysis, but the guidance is left to inference rather than being explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the pre-registered refutation threshold for matching claims: the measurement that would have killed each claim, recorded before the outcome was known. 16,194 of 16,218 ledger records carry one. Use this to test whether a claim is falsifiable at all.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max records, default 5 | |
| query | No | substring to match |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses partial data coverage ('16,194 of 16,218 ledger records carry one') and the pre-registration property, which is useful. However, it does not explicitly state read-only behavior, auth requirements, or return format, so it adds only moderate behavioral context.
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, with the core definition front-loaded in the first sentence. The coverage statistic and usage guidance each earn their place; there is no redundant or filler content.
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?
The concept of a refutation threshold is well explained, and the usage instruction is clear. However, there is no output schema and the description does not describe the return value shape or behavior when no records match (e.g., empty array, null). For a simple query tool this is a moderate gap, not a severe one.
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%, so the parameters are already fully documented by the schema. The description's 'matching claims' phrase aligns with the query parameter but adds no new semantic detail beyond what the schema provides. Baseline 3 is appropriate.
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 ('Return') and a distinctive resource ('pre-registered refutation threshold for matching claims'). This resource is unique enough that an agent can distinguish this tool from siblings like get_verdict or query_claim without needing an explicit comparison.
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 an explicit use case: 'Use this to test whether a claim is falsifiable at all.' This provides clear context for when to invoke the tool. It does not mention alternatives or exclusions, so it falls 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0citation_blockget_verdictquery_claimverifier_drift_netwhat_would_refuteScored across 5 tools
The tools are mostly distinct: query_claim returns full claim records, get_verdict focuses on verdict retrieval, what_would_refute provides thresholds, verifier_drift_net measures transitions, and citation_block handles citations. There is some overlap between query_claim and get_verdict in searching by phrase, but the purposes are clearly different enough to avoid significant confusion.
Naming conventions are inconsistent. query_claim and get_verdict follow a verb_noun pattern, but what_would_refute is a question phrase, verifier_drift_net is a noun compound, and citation_block is also noun_noun. This mixed style makes it harder to predict tool names and reduces coherence.
With only 5 tools, the server is tightly scoped to its ledger domain. Each tool covers a distinct need—searching, verdicts, thresholds, drift analysis, and citations—without redundancy or bloat.
The tool surface covers the core operations for querying and analyzing the ledger: search, verdict retrieval, threshold lookup, drift measurement, and citation generation. Minor gaps exist, such as no explicit tool to list all claims or add new ones, but the apparent read-only purpose is well-served.
Verify before your agent acts on data it paid for. Signed verdicts, checkable offline, via x402.
Verified external-state intelligence for agents with corroborated evidence and ANSWER or WAIT.
Trust registry for agents: check_trust verdict A0-A4, signed fact passports, honest refusals.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
