Skip to main content
Glama
matthiaskloft

evidence-ledger-mcp

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
schema_infoA

Report the server version and the evidence ledger schema version it supports.

validate_recordA

Validate one ledger record against the schema; returns the violations, empty if valid.

create_ledgerB

Create a ledger file (JSON Lines) with a header; work needs title and type.

add_recordA

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.

get_recordC

Return one record by its id.

find_recordsA

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.

validate_ledgerB

Validate a whole ledger; returns the problems found, empty if valid.

withdraw_recordB

Mark a record withdrawn with a reason instead of deleting it.

export_ledgerB

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.

summarize_ledgerA

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.

embed_ledgerB

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.

check_ledgerA

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.

resolve_linksA

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.

relink_htmlA

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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 14 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessResponsive