This MCP server lets agents build, validate, search, export, and audit an evidence ledger that links claims in a work to source passages.
Create JSON Lines ledgers with schema-versioned headers.
Add records that link claims to citations, locators, quotes, relations, justifications, and provenance; the server assigns IDs, hashes quotes, dates provenance, and validates before writing.
Retrieve, search, and filter records by claim, source key, claim ID, missing evidence, or withdrawn status.
Validate individual records or whole ledgers against the bundled schema.
Withdraw records with a reason instead of deleting them, preserving history.
Export ledgers or generate standalone HTML summaries at full, masked, or locator levels, with publication checks and overwrite protection.
Embed claim anchors in rendered HTML and link them to evidence cards, as endnotes or a side panel.
Check ledgers for evidence gaps, missing anchors, revision mismatches, bibliography key mismatches, and quotes that do not match supplied or fetched source text.
Resolve source records to local PDFs, verify quoted passages by hash, and write private link files for opening PDFs at the relevant page.
Relink shared summary or embedded HTML to a reader’s own local PDFs, producing a private copy that must not be shared.
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., "@evidence-ledger-mcp Create an evidence ledger and add a citation for my first claim."
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.
Under active development. Both the schema and the server may change in breaking ways between versions until v1.0. Pin the version you use.
An MCP server through which agents keep an evidence ledger for the citations in a work: for each claim, the source that backs it, where in the source, a short quote and why the citation is needed. Co-authors, scripts or a second model can then check every citation against its source.
It is built for academics: authors and co-authors who write with LLMs and want every citation to stay checkable. The ledger format is an open schema, so a graduate school could require it for theses, and a journal could adopt it for submissions or build its own standard on it.
Supported schema: v0.4.0 · standalone schema repository (how schema versions are pinned).
The MCP server and its associated documentation use the MIT licence. The bundled schema uses CC BY 4.0, with attribution to Matthias Kloft. These licences do not cover ledger contents or third-party source material.
Every ledger this server writes follows the evidence ledger schema (JSON Schema, draft 2020-12), currently v0.4.0. The schema is the contract: any tool, script or person can read, validate and check a ledger with it, with or without this server. Its README documents the purpose, the file shapes, every record field, quote hashing, a minimal example and the sources the fields draw on. The server bundles a pinned copy in schema/ and reports the supported version through schema_info.
A ledger is a header (schema_version, work and optional notes) followed by records. Each record links one claim in the work to one source passage:
Field | Required | Content |
| yes | Record and claim IDs; the server assigns them. Records about the same claim share a |
| yes | The claim, its type ( |
| yes | Where the claim sits in the work: its |
| yes | The source's citation key, with |
| Where in the source: | |
| A short quote from the source, and the phrase within it that carries the claim; | |
|
| How the source bears on the claim ( |
| yes | How the passage was found, and who assessed it (person or agent and model), when, and against which revision of the work. |
| The reason a citation was withdrawn; records are never deleted. |
A minimal record, as passed to add_record (the server adds the IDs, hash and date):
{
"claim": "Retrieval practice improves long-term retention.",
"claim_type": "empirical",
"contestable": true,
"anchor": {"exact": "testing improves later recall"},
"key": "example2020",
"doi": "10.1234/example",
"locator": {"page": 12},
"quote": "participants who were tested recalled more after one week",
"relation": "supports",
"justification": "Direct experimental evidence for the claim.",
"retrieved_via": "pdf"
}with provenance such as {"by_type": "agent", "by": "Claude Code", "model": "claude-opus-5-5"}. Ledgers are stored as JSON Lines; see docs/schema.md.
Related MCP server: Witness
Write ledgers safely. Records are validated against the schema before they are appended. The server assigns record and claim IDs, computes quote hashes and dates the provenance instead of leaving them to the agent.
Keep the history. The server never deletes records; a withdrawn record keeps its reason.
Find gaps. Search by claim, source key or text, and list contestable claims still missing evidence.
Share without leaking sources. Exports and summaries come at three levels: full (private), masked (short excerpts) and locator (no quoted text). A publication check refuses to write a file that carries more source text than its level allows.
Read it as a report. A standalone HTML summary, grouped by claim, prints to PDF from a browser.
See the evidence in the work. The claims are marked in the work's own HTML and linked to their evidence, as end notes or in a side panel.
Check it against the work and its sources. Find anchors that no longer appear in the work, records assessed against another revision, quotes that the source text no longer holds, and citation keys missing from the bibliography. Source text can be passed in, or the server fetches it from public URLs (web pages, plain text and PDFs with a text layer).
Requires Python 3.11 or newer. The server speaks MCP over stdio. With uv, run the released version from PyPI:
uvx --from evidence-ledger-mcp==0.4.0 evidence-ledger-mcpFor example, to add it to Claude Code:
claude mcp add evidence-ledger -- uvx --from evidence-ledger-mcp==0.4.0 evidence-ledger-mcpOther MCP clients take the same command and arguments. To run a source checkout instead, use uv sync, then configure the client to run uv with arguments run, --directory, the absolute path to the checkout, and evidence-ledger-mcp.
Pass absolute ledger paths to tools; relative paths resolve against the server's working directory.
Tool | What it does |
| Reports the server version and the supported schema version. |
| Creates a JSON Lines ledger with a header; |
| Validates and appends a record; takes the record and a separate |
| Returns one record by its ID. |
| Finds records by |
| Checks one record against the schema without writing it. |
| Checks a whole ledger and lists the problems found. |
| Marks a record withdrawn, with a reason, instead of deleting it. |
| Writes the ledger as JSON or JSON Lines at a chosen level to a new file. |
| Writes a standalone HTML summary grouped by claim to a new file. |
| Marks each claim in the work's rendered HTML and links it to its evidence, as end notes or in a side panel, in a new file. |
| Reads the ledger and reports gaps, anchors missing from the work, records from another revision and quotes not found in source text you pass in or the server fetches from public URLs. Writes nothing. |
| Matches each source to a PDF in a |
| Turns a summary or embedded HTML you received into a private copy ( |
create_ledger once per work, next to the manuscript or code.
add_record whenever a source is cited, with the claim, its anchor, the source key, locator, quote, relation and justification. The server fills in IDs, the quote hash and the provenance date.
find_records with missing_evidence and validate_ledger before submission, to find claims still lacking evidence.
check_ledger with the rendered work, its bibliography and the sources (as text or public URLs), to catch anchors, keys and quotes that no longer match.
export_ledger, summarize_ledger or embed_ledger at masked or locator level to share the ledger with co-authors, reviewers or a journal.
The tool reference covers export levels, masking, embedding and every check in detail.
Append a record. The server assigns id, claim_id (unless given), quote_hash and the
provenance date, validates the result and returns the stored record. Mark the phrase
carrying the claim (a number, term or short statement) with optional quote_focus. Source
text belongs only in quote, quote_prefix, quote_suffix and quote_focus: write
justification, locator (including a section heading) and note in your own words, since
they are exported with masked and locator ledgers; a record that repeats 24 or more letters
and digits of its own quote in another field is refused, naming the field.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| record | Yes | ||
| provenance | Yes |
| Name | Required | Description |
|---|---|---|
| result | 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 server-assigned fields, validation behavior, return behavior, and a specific refusal condition when quoted text is repeated in other fields. It does not mention permissions or broader side effects, but the core mutation behavior is well explained.
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 front-loaded with the core action and then adds necessary field-level constraints. It is dense but mostly earns its length, though some long clauses could be split for easier parsing.
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 three required parameters, nested objects, no annotations, and no schema descriptions, the description supplies substantial operational and field-level guidance. The main gap is the unexplained `path` parameter and lack of complete nested-object mapping; return-value details are covered by the output schema and need not be repeated.
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 for opaque object parameters. It significantly clarifies record and provenance fields, including quote-related fields, allowed source-text placement, and which fields must be written in the agent's own words; however, it does not explain the `path` parameter or fully map the nested object structure.
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 specific operation: appending a record, with server-side assignment of IDs and validation. It is distinguishable from read-oriented siblings like get_record and find_records, but it does not explicitly contrast with validate_record or other mutation siblings.
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 is implied by 'Append a record', and the description gives important in-record constraints. However, it does not explicitly say when to use this instead of validate_record, create_ledger, or other siblings, nor does it state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| work | No | ||
| sources | No | ||
| revision | No | ||
| source_urls | No | ||
| bibliography | No | ||
| include_withdrawn | No |
| Name | Required | Description |
|---|---|---|
| result | 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 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.
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.
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.
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.
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.
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.
Create a ledger file (JSON Lines) with a header; work needs title and type.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| work | Yes | ||
| notes | No | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the file format and a header, which is useful, but says nothing about overwrite behavior, file existence handling, permissions, or failure modes for a mutation 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?
The description is a single, front-loaded sentence with no wasted words. The semicolon cleanly separates the core action from the nested requirement, making it 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?
The tool has a nested object, an output schema, and no annotations, so the description should do more to explain creation semantics. It covers the file format and the required nested fields, which are key, but leaves out overwrite behavior, path interpretation, and usage context.
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%, and the nested 'work' object has additionalProperties with no property definitions, so the description's note that 'work' needs 'title' and 'type' adds critical meaning beyond the schema. However, the 'path', 'notes', and 'description' parameters remain unexplained.
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 and resource: creating a ledger file in JSON Lines format with a header. It does not explicitly differentiate itself from siblings like validate_ledger or export_ledger, but the creation action is distinct enough to be identifiable.
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 alternatives such as validate_ledger or export_ledger. There is no mention of prerequisites, conditions, or exclusions, leaving the agent to infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a copy of the work's HTML (work, rendered by Quarto, Pandoc or any tool) with each
claim's anchor marked and linked to its evidence, to a new file. Both layouts end with an
"Evidence" section holding one card per claim; a button switches the reader between that
section and a side panel that opens the clicked claim's card (a bottom sheet on narrow
screens), and layout picks the view shown first; if no anchor is located, panel falls
back to endnotes and the result's layout says so.
Anchors that are only a marker, not found in the text or overlapping another claim's marked
text are listed under "Not located in the work" and returned in not_located (overlapping
maps a claim to the one it overlaps); a record key links to #ref-<key> when the work has
that bibliography entry. Levels and the publication check work as in summarize_ledger, and
out is never overwritten and must be in the work's folder. A full result holds whole
quotes: keep it private.
| Name | Required | Description | Default |
|---|---|---|---|
| out | Yes | ||
| path | Yes | ||
| work | Yes | ||
| level | No | full | |
| layout | No | endnotes | |
| include_withdrawn | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden well: it discloses layout switching, fallback from `panel` to `endnotes`, handling of unlocated or overlapping anchors, bibliography linking, and the fact that `out` is never overwritten. It also warns that `full` results contain whole quotes and should be kept private, though it does not cover all possible failure or permission conditions.
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 dense but front-loads the main action and then adds relevant behavioral details. It is long because the tool is complex and the schema lacks parameter descriptions, though some sentences are packed with multiple clauses that reduce readability.
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 tool is complex, has no annotations, and has 0% schema description coverage, so the description needs to do substantial work. It covers much of the behavior and output-related edge cases, but leaves key input parameters (`path`, `include_withdrawn`) and usage alternatives undocumented.
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 document all six parameters, but it only partially covers `work`, `out`, `layout`, and indirectly `level`. It does not describe `path` or `include_withdrawn`, and it does not define the enum values for `level` beyond a reference to `summarize_ledger`.
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: write a copy of the work's HTML with each claim's anchor marked and linked to evidence. It is clear what the tool does, but it does not explicitly differentiate this tool from related siblings such as relink_html or export_ledger.
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 explains behavior but gives no explicit guidance on when to choose embed_ledger over alternatives like relink_html, export_ledger, or summarize_ledger. Constraints such as `out` never being overwritten are useful but do not tell the agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the ledger to a new file. masked keeps the first and last words of each quote,
locator no quoted text; a publication check runs before writing, and out is never
overwritten. max_words is allowed only for masked, from 1 to 25; None keeps the
default masking. With a budget, quote_focus centres the excerpt. A full export
holds whole quotes: keep it private.
| Name | Required | Description | Default |
|---|---|---|---|
| out | Yes | ||
| path | Yes | ||
| level | No | full | |
| format | No | jsonl | |
| max_words | No | ||
| include_withdrawn | No |
| Name | Required | Description |
|---|---|---|
| result | 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 a good job disclosing key behaviors: a publication check runs before writing, `out` is never overwritten, and `full` exports contain sensitive whole quotes that should be kept private. It does not cover permissions, error handling, or exactly what the publication check validates, keeping 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?
The description is dense but front-loaded: the core action and key constraints appear immediately, and each sentence adds behavioral detail. The sentence about `quote_focus` does not earn its place because that parameter is absent from the schema, but overall structure is 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?
The tool has six parameters with zero schema descriptions and no annotations, so the description must do substantial work. It adequately covers the core output-level semantics and write-protection behavior, and an output schema exists to explain return values. Still, it omits meaning for `path`, `format`, and `include_withdrawn` and introduces a nonexistent parameter, leaving the definition only partially complete.
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 description adds useful semantics for `level` (masked, locator, full), `max_words` (only for masked, range 1–25), and `out` (never overwritten). However, with 0% schema description coverage, it leaves `path`, `format`, and `include_withdrawn` completely undocumented. Worse, it references a `quote_focus` parameter that does not exist in the schema, which is misleading.
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 and resource: 'Export the ledger to a new file.' This clearly distinguishes it from siblings like summarize_ledger, validate_ledger, and create_ledger. It does not explicitly name any sibling as an alternative, but the purpose is unambiguous.
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 implied through behavioral constraints: a `full` export 'holds whole quotes: keep it private,' and a publication check runs before writing. However, there is no explicit when-to-use guidance relative to alternatives such as summarize_ledger, nor are prerequisites or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find records by claim_id, source key, text in the claim, or contestable records lacking evidence (all filters combine); withdrawn records are left out unless requested.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ||
| path | Yes | ||
| text | No | ||
| claim_id | No | ||
| missing_evidence | No | ||
| include_withdrawn | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does disclose two real behavioral traits: filters are AND-combined, and withdrawn records are excluded by default unless include_withdrawn is set. That default-exclusion semantics cannot be inferred from the schema alone. It stops short of stating that the call is read-only or whether result sets are bounded, but the core filtering behavior is well surfaced.
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?
A single front-loaded sentence that covers filter axes first and behavioral caveats second, with no filler. Minor ambiguity in the 'or' phrasing for what are actually AND-combined filters, though the parenthetical immediately corrects it.
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 presence of an output schema relieves the description of explaining return values, and the filtering semantics are covered. Still, with no annotations and a required, undocumented 'path' argument, the definition does not give an agent everything needed to invoke 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 description coverage is 0%, so the description must compensate, and it does explain five of six parameters in domain terms: claim_id, key ('source key'), text ('text in the claim'), missing_evidence ('contestable records lacking evidence'), and include_withdrawn. The required parameter 'path' is never explained, which is a notable gap because it is the only mandatory argument.
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?
Names a specific verb and resource (find records) and enumerates the four filter axes: claim_id, source key, claim text, and missing-evidence records. It is clearly a filtered list operation, distinguishing it implicitly from get_record (single fetch) and add_record/withdraw_record (mutations), but it never names a sibling to route against 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?
The parenthetical '(all filters combine)' tells the agent that filters are conjunctive rather than exclusive, which is genuinely useful selection guidance, and the withdrawn-records clause sets a default. However, there is no explicit statement of when to prefer this over get_record or summarize_ledger, and no prerequisites are given, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one record by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only states that a record is returned. It does not disclose what happens if the record is missing, whether permissions are required, or any side effects, though 'Return' implies a 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?
The description is a single front-loaded sentence with no wasted boilerplate. It is structurally clean, though extremely terse.
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 output schema covers return values, so the description need not explain them. But with two required parameters at 0% schema coverage and no annotations, the description is incomplete: it omits the meaning of 'path' and gives no guidance on selecting this tool over find_records.
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%, and there are two required parameters. The description explains the 'id' parameter as the record identifier, but it leaves the required 'path' parameter completely undocumented.
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 gives a specific verb and resource: 'Return one record by its id.' This clearly identifies a single-record lookup and implicitly distinguishes it from the plural search sibling find_records, though it does not name that sibling 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?
Usage is implied by 'by its id' — an agent can infer this is for direct lookup when an id is known. However, it does not explicitly compare this tool with find_records or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Give a reader links from a summary or embedded HTML file (from summarize_ledger or
embed_ledger, e.g. one a co-author sent) to their own PDFs in folder (best: a sources/
folder of only the cited PDFs named <citation key>.pdf, kept out of version control;
never a whole library) or in a link_map (a .private.json file as for resolve_links).
Records are read
from the data the file carries, sources matched as in resolve_links, and each evidence card
gets a "Your copy" line with an "Open PDF" button opening the PDF at the passage's page, or else
at the cited page, and, where the map gives an open link, an "Open in library" button
with the page appended (?page=N).
Writes <name>.private.html next to the original (a rerun replaces a copy it wrote, no
other file) and never changes
the original. The copy is marked private in its name, title and a banner, and is not indexed:
tell the user it links to files on this computer and must not be shared or published; they
share the original instead. Links are relative when the PDFs are inside the copy's folder
(so a team sharing that folder can open them), absolute file:// links otherwise; they work
when the copy is opened from disk, not from a website. Returns record ids by status.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | ||
| folder | No | ||
| link_map | No | ||
| bibliography | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it states what file is written, that a rerun replaces only a copy it wrote, that the original is never changed, and that the output is marked private and not indexed. It also discloses link behavior, relative versus absolute paths, and the limitation that links work from disk rather than a website.
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 front-loaded with the purpose and the key usage constraints. It is dense and could be easier to scan with paragraphs or bullets, but most sentences add necessary operational or privacy context rather than repeating structured fields.
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 complex file-mutating tool with no annotations and an output schema, the description supplies strong operational context: input sources, matching behavior, output naming, privacy warnings, and link path rules. The main completeness gap is the unexplained `bibliography` parameter, but the required `html` path and the core file/link behavior are sufficiently covered.
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 explain all four parameters. It gives useful semantics for `html`, `folder`, and `link_map`, including expected file types and constraints, but it never mentions the `bibliography` parameter, leaving one optional parameter undocumented in both schema and description.
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 transformation: it gives readers links from a `summarize_ledger`/`embed_ledger` HTML file to their own PDFs and writes a marked-private `<name>.private.html` copy. It also distinguishes the tool from its source siblings by naming `summarize_ledger`, `embed_ledger`, and `resolve_links`.
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: the input should come from `summarize_ledger` or `embed_ledger`, the `folder` should ideally be a `sources/` folder of cited PDFs, and it warns against pointing at a whole library. It does not explicitly compare when to choose `relink_html` instead of a sibling such as `resolve_links`, but the practical constraints and alternatives for PDF lookup are well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the ledger's sources against the reader's own PDFs and write the result to
link_file, which must end in .private.json (a rerun replaces one this tool wrote, no
other file): it holds paths on this computer, so do not share it.
Give folder, link_map or both. Best layout: a sources/ folder holding only the cited
PDFs, each named <citation key>.pdf, kept out of version control (copyrighted). A file
named exactly after the key is tried first; other names work through the matching below.
Do not pass a whole reference library as folder: thousands of PDFs are slow and the call
stops at the time limit with every source source_not_found. For a library, pass
link_map instead: the path of a .private.json file (JSON Schema link-map.schema.json)
with {"link_map_version": "0.1.0", "sources": {"<key>": {"file": "<pdf path>", "open": "<optional library link>"}}}. A mapped key searches only its PDF; a key missing from the
map is not_in_map, unless folder is also given, which is then searched for it. With
Zotero and Better BibTeX, build the map from JSON-RPC item.attachments(citekey) at
http://localhost:23119/better-bibtex/json-rpc, which returns {open, path} per attachment.
folder is searched recursively.
Where no passage is found, the link file still gives the PDF page of the record's
locator.page, read through the PDF's printed page labels or, without labels, taken as the
PDF page number (page_from says which). In a folder a source matches by the first
of: a file named <key>.pdf, its DOI on a PDF's first two pages, its ISBN on the first ten,
its title on the first two
(from bibliography, a .bib or CSL JSON file, which can also supply DOI and ISBN; titles
under 20 letters and digits count only with the first author's family name), each only if
exactly one PDF matches, so that a PDF citing the source does not; last, a file named after
the first author and year (e.g. Ioannidis 2005.pdf).
Each record is then
found (its passage is in the PDF, at the page given in the link file; this confirms the
record independently), passage_not_found, source_not_found, not_in_map or
not_searchable: finding a
passage needs its quote, whole or masked to its first and last words as in masked exports;
a locator export holds only the hash. The passage must hash to quote_hash, so
whitespace, punctuation, case and line-end hyphens may differ; a whole quote split by a
page break (with or without running heads or captions between its parts) is found and
marked across_pages in the link file. PDFs that cannot be read are listed with a short
reason under unreadable_files, and time_limit when reading PDFs stopped after 300 seconds.
The result holds record ids and file paths, never source text.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| folder | No | ||
| link_map | No | ||
| link_file | Yes | ||
| bibliography | No | ||
| include_withdrawn | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds: it discloses the overwrite behavior ('rerun replaces one this tool wrote, no other file'), the privacy risk (paths on this computer, do not share), the 300-second `time_limit`, `unreadable_files` handling, and the full status vocabulary (`found`, `passage_not_found`, `source_not_found`, `not_in_map`, `not_searchable`). These are material behaviors an agent could not infer elsewhere.
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?
Front-loaded with purpose, privacy warning, and the folder-vs-map decision, which is the right ordering. It is dense and a few clauses are hard to parse (the matching-precedence sentence in particular), but nearly every sentence adds operational detail rather than filler.
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 complex tool with an output schema, the description supplies everything an agent needs to invoke it correctly: input construction, matching rules, status meanings, and failure modes. Nothing essential is left for the agent to guess.
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 for most: `folder`, `link_map`, `link_file`, and `bibliography` are all richly explained, including matching precedence and file-name conventions. `include_withdrawn` is never mentioned at all and `path` is only implied as the ledger, leaving a real gap.
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 and resource (resolve the ledger's sources against the reader's PDFs) and names the exact output (a `.private.json` link file). It is clearly distinct from siblings like `relink_html` and `find_records`, and the first sentence alone lets an agent decide this is the linking tool.
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?
Gives explicit routing: use `folder` for a small `sources/` directory, use `link_map` for a whole library, and warns that passing a reference library as `folder` will time out. It also names prerequisites (Zotero + Better BibTeX JSON-RPC) and the exact construction of a link map, covering when and how to use each alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the server version and the evidence ledger schema version it supports.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and 'Report' plus a zero-parameter schema reasonably conveys a side-effect-free informational read. It names exactly what is disclosed (server version, supported ledger schema version); finer points like caching or auth requirements are absent but low-risk for a version probe.
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?
A single front-loaded sentence with zero filler, stating verb and both returned facts immediately.
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 no-arg informational tool with an output schema, the description supplies everything an agent needs: what it reports, with no hidden parameters or side effects to worry about. Return-value structure is covered by the output schema.
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?
Zero parameters, so the baseline applies; nothing in the schema needs compensating for. The description correctly adds no parameter detail because there is none to add.
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 ('Report') plus two concrete resources: server version and supported evidence-ledger schema version. It is clearly distinguishable from every sibling (add_record, validate_ledger, etc.), though it does not name or contrast with any of 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?
No explicit when/when-not statements or alternatives. Usage is only implied — an agent infers this is the compatibility/version probe to call before or alongside ledger operations. No exclusions or ordering guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a standalone HTML summary of the records, grouped by claim, to a new file. Levels
and the publication check work as in export_ledger, and out is never overwritten. A
full summary holds whole quotes: keep it private. For a PDF, print the HTML from a
browser; its print style shows link targets and avoids splitting records where possible.
| Name | Required | Description | Default |
|---|---|---|---|
| out | Yes | ||
| path | Yes | ||
| level | No | full | |
| include_withdrawn | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses that output goes to a new file and is never overwritten, that `full` summaries contain whole quotes and should be kept private, and how the HTML's print style behaves (link targets shown, records not split where possible). The gap is that "levels" and "the publication check" are deferred to a sibling's description, so the agent may not see those semantics here.
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, each carrying distinct information: the action, level/publication semantics, the overwrite guarantee, the privacy warning, and the PDF workflow. The core action is front-loaded and nothing is 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?
An output schema exists, so return values need not be explained, and the file-write behavior is well covered. But for a tool whose levels drive privacy and content differences, leaving `masked`, `locator`, `include_withdrawn`, and the "publication check" undefined here (relying on export_ledger's description) leaves an agent unable to choose a level 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% — all four parameters have only bare titles — so the description must compensate and largely does not. It clarifies `out`'s non-overwrite behavior and names `full` as a level value, but never explains `masked` or `locator`, never mentions `include_withdrawn`, and never says what `path` points to (source ledger).
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 and artifact: "Write a standalone HTML summary of the records, grouped by claim, to a new file." That is clearly distinct from add_record/get_record and even hints at grouping semantics. However, differentiation from the closest sibling (export_ledger) is only implicit via the cross-reference for levels and the publication check, rather than an explicit statement of which tool to pick.
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?
Gives real usage context: levels and the publication check behave as in `export_ledger`, `out` is never overwritten, and PDF output should be produced by printing the HTML from a browser. It also adds a handling caveat for `full` summaries. It stops short of an explicit "use this instead of export_ledger when you need a human-readable HTML artifact" routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a whole ledger; returns the problems found, empty if valid.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully states that validation returns problems and is empty when valid, but it does not explicitly confirm read-only behavior, permissions, or whether any side effects occur.
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 a single front-loaded sentence with no wasted words. It communicates the core action and return behavior efficiently.
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?
An output schema exists, so the description need not explain return structure in detail. However, for a no-annotation tool with zero schema description coverage on its only parameter, the definition leaves important calling details about 'path' and read-only behavior unspecified.
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% for the single required 'path' parameter. The description says 'whole ledger' but does not clarify whether 'path' is a file path, directory, ledger identifier, or expected format, so it does not compensate for the schema gap.
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: validating a whole ledger. The word 'whole' helps distinguish it from validate_record, but it does not explicitly name that sibling or clarify the difference in scope.
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 is implied: call this to validate an entire ledger. However, the description gives no explicit when-to-use guidance, no exclusions, and no comparison to validate_record or schema_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate one ledger record against the schema; returns the violations, empty if valid.
| Name | Required | Description | Default |
|---|---|---|---|
| record | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the return shape: violations, or empty if valid. That is genuinely useful, but it omits whether the call mutates anything, what schema is consulted, and how deep the validation goes given the record object allows additionalProperties.
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?
One sentence, front-loaded with the action and scope, with the return behavior appended. Nothing wasted and nothing buried.
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 output schema exists, so return values needn't be explained, yet the description still leaves the open-ended record parameter and the source of the validation schema unexplained. For a tool with no annotations and an unconstrained nested object, that leaves a real 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 coverage is 0% for a single free-form nested object, so the description must compensate. It only establishes that 'record' is a ledger record checked against 'the schema' – it doesn't say which schema is used or what shape the record must take, which matters since the object is open-ended.
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 and resource ('validate one ledger record') plus the cardinality ('one'), which implicitly separates it from the ledger-wide sibling validate_ledger. It never names that sibling, so the differentiation requires inference rather than being spelled out.
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 is only implied – validating a single record ahead of or after a write. There is no explicit statement of when to call this versus validate_ledger or schema_info, and no mention of prerequisites or ordering relative to add_record/create_ledger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a record withdrawn with a reason instead of deleting it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| path | Yes | ||
| reason | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the record is marked withdrawn rather than deleted, implying retention and an audit reason. It does not explain permissions, reversibility, idempotency, or what happens to the record's visibility, which are important for a mutation 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?
The definition is a single front-loaded sentence with no wasted words. It efficiently conveys the action, resource, and key contrast with deletion.
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 output schema covers return values, but the description is too thin for a mutation tool with three required, undocumented parameters and no annotations. It should explain path/id semantics and behavioral details like permissions or reversibility to be complete enough for reliable invocation.
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. It only clarifies the 'reason' parameter by saying the record is withdrawn 'with a reason'; it adds no meaning for 'path' or 'id', leaving two of three required parameters undocumented.
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: mark a record withdrawn. It also distinguishes the operation conceptually from deletion by saying 'instead of deleting it.' It does not explicitly differentiate itself from sibling tools like add_record or get_record, but the core purpose is clear.
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 phrase 'instead of deleting it' gives a clear use context: prefer withdrawal over deletion when a reason should be preserved. However, it does not state when not to use this tool, nor does it name or compare against sibling tools such as add_record or get_record.
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.4.0check_ledgerembed_ledgerrelink_htmlresolve_linksv0.1.0add_recordcreate_ledgerexport_ledgerfind_recordsget_recordschema_infosummarize_ledgervalidate_ledgervalidate_recordwithdraw_recordScored across 14 tools
Most tools target distinct lifecycle stages: record operations, ledger creation/validation, export/summary/embedding, and PDF linking. The main potential confusion is between check_ledger and validate_ledger, and between resolve_links and relink_html, but their descriptions clarify different inputs and outputs. An agent can generally select correctly, though a few boundaries require careful reading.
Nearly all tools use a consistent snake_case verb_noun pattern: add_record, find_records, get_record, validate_record, export_ledger, and so on. The only clear deviation is schema_info, which is noun-based rather than verb_noun, but the naming remains predictable overall.
Fourteen tools is well within the expected 3-15 range and fits a complex evidence-ledger workflow that includes record management, validation, export, embedding, and PDF linking. Each tool appears to earn its place without obvious duplicates.
The surface covers ledger creation, record addition, lookup, withdrawal, validation, export, summarizing, embedding, and source linking. The main gap is a direct record update/edit operation, though the append-plus-withdraw model may make this intentional. Overall the lifecycle is substantially covered with minor workarounds.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
Host any HTTP API as MCP tools with a tamper-evident cross-agent settlement ledger.
Evidence-graded agent-work lanes, bid advice, live agent jobs and a hash-chained evidence ledger.
