evidence-ledger-mcp

Overview Schema Source Related Servers Discussions Admin

check_ledger

Validate a JSON Lines evidence ledger without modifying it, returning record and claim IDs, keys, counts, gaps, and optional checks for anchors, revisions, sources, source URLs, and bibliography.

Instructions

Check a ledger without changing anything; the result holds record and claim ids, keys and counts, never quote or source text. gaps is always returned: contestable records lacking a locator, quote or justification, claims whose records are all withdrawn, and, when a bibliography is known, record keys missing from it. Optional checks, each returned only when its input is given: work reports anchors not found in it, or with only a marker, under anchors (HTML is matched on its visible text; other files on their source text, so markup inside an anchor reports not found: prefer the rendered HTML); revision lists records assessed against another or an unknown provenance.manuscript_rev; sources maps a record key to the source's full text and re-checks each quote against it (matched, not_found, no_source); source_urls maps a record key to a public http(s) URL whose text (HTML, plain text or a PDF with a text layer, up to 10 MB; hyphenation across PDF lines can make a quote not_found) the server fetches itself and adds to sources (a key in both is an error). Hosts that are not public, including via redirects, are refused; fetches that fail are listed with a short reason under quotes.fetch_failed, and their records count as no_source. bibliography is a .bib or CSL JSON file; for an HTML work without one, its ref-<key> entries serve. Withdrawn records are skipped unless include_withdrawn.

Input Schema

Name	Required	Description	Default
`path`	Yes
`work`	No
`sources`	No
`revision`	No
`source_urls`	No
`bibliography`	No
`include_withdrawn`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 31, 2026

TDQS

A4/5.0

Behavior5/5

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 so thoroughly: it states the tool is read-only, describes what the result never includes, explains always-returned gaps, optional check outputs, URL-fetching constraints, PDF limitations, and withdrawn-record handling. This gives an agent unusually rich context for invoking the tool safely and correctly.

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 and dense, but it is front-loaded with the core read-only purpose and return content before detailing optional checks. Given the tool's complexity, most sentences earn their place, though the single-paragraph format could be more scannable.

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

Completeness4/5

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

The tool has seven parameters, no annotations, and an output schema, so the description needs to cover input behavior and return semantics. It does that extensively for optional checks and constraints, with the main remaining gap being the required path argument.

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

Parameters4/5

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 for all seven parameters. It explains the semantics of work, revision, sources, source_urls, bibliography, and include_withdrawn in useful detail, though it does not explain the required path parameter.

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

Purpose4/5

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

The description gives a specific verb and resource: it checks a ledger without changing anything and states what the result contains. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as validate_ledger or summarize_ledger.

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

Usage Guidelines3/5

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

The description implies usage through 'check a ledger without changing anything' and explains when optional checks are returned based on which inputs are supplied. However, it gives no explicit when-to-use guidance versus validate_ledger, summarize_ledger, or other siblings.

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

Deploy Server