Skip to main content
Glama
matthiaskloft

evidence-ledger-mcp

resolve_links

Matches cited sources in an evidence ledger against local PDFs, verifies quoted passages, and writes page links to a private link file.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
pathYes
folderNo
link_mapNo
link_fileYes
bibliographyNo
include_withdrawnNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.8/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 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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.