Loading ToolBench
MCP server for managing pandoc/CSL-YAML bibliographies and citation verification
Doc Tools MCP demonstrates strong definition quality with 14 well-named tools, comprehensive parameter schemas, and detailed descriptions. All tools start with action verbs (get, search, list, add, update, delete, validate, extract). Schema definitions are complete with proper JSON Schema types. However, output schemas are not explicitly documented in the visible source, and error handling guidance could be more actionable. Tool composition is excellent, each tool has a single clear responsibility, and parameters are well-described with constraints like enums and required fields. The bib provider shows particularly strong design (5 read tools, 4 write tools with backup semantics), while ctverify tools are well-structured for citation verification workflows.
Add a new bibliography entry. Validates required fields per CSL type, checks for duplicate IDs, and creates a .bak backup before writing. Returns the created YAML block for confirmation.
Remove a bibliography entry by ID. Creates a .bak backup before writing.
Check if a citation ID exists in the bibliography. Fast boolean check before citing.
Retrieve a single bibliography entry by ID. Returns the full YAML block.
List all bibliography entries of a given CSL type (e.g., "legal_case", "book", "article-journal", "chapter").
Search bibliography entries across all fields: author, title, type, year, editor, container-title. Use ONE search term per call (e.g., "Pahlow" or "OLG Köln"). For multiple lookups, call this tool multiple times.
Output schemas not explicitly documented in source code. While input schemas are comprehensive (JSON Schema with types and descriptions), return types for all 14 tools are not visible in the provided code. LLMs cannot reliably infer what fields to expect from tool responses.
Error handling descriptions lack actionable recovery guidance. Tools reference errors (e.g., 'duplicate ID', 'not found') but do not guide the LLM on what to do next or which alternative tools to call. Example: bib:add describes validation but doesn't say 'call bib:exists first to check for duplicates'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 11 | - | v1 |
Get bibliography statistics: total entry count and breakdown by CSL type.
Update fields of an existing bibliography entry. Only the specified fields are changed; all other fields remain untouched. Creates a .bak backup before writing.
Validate the entire bibliography file: YAML syntax, required fields per CSL type, duplicate IDs, and missing issued dates. Returns a list of errors and warnings.
Update status (and optionally note) for multiple citations at once. Select entries either by a list of IDs or by filter (current status). At least one of `ids` or `filter_status` must be provided.
Extract citations from Pandoc inline footnotes (^[...]) for verification tracking. This is a CITATION VERIFICATION tool, not bibliography management. It extracts citations so the LLM can systematically verify that each cited source actually supports the claim made in the text. Use `registry_path` to save/merge results into a JSON registry file (preserves existing claims and statuses). Re-running after text edits is safe: exact cite matches preserve claims/status, proximity matching (±5 lines) recovers claims when cite text changed. Each citation captures ~200 chars of surrounding context for claim formulation. Workflow: extract → set claims → verify each claim against the source using research tools → update status.
Retrieve one or more citation entries by ID. Returns full details including cite, context, claim, status, and note.
Show verification progress of a citation registry: counts by status and list of citations. Use `filter_status` to focus on specific statuses, `filter_claim` to search claims or find missing ones.
Batch update citation verification entries. Each entry can set claim, status, and/or note independently. The `claim` field records WHAT the text asserts at this citation point. The `status` tracks verification progress: pending → under_review → verified/disputed/not_found. If an ID does not exist and `cite` is provided, creates a new entry (for inline citations not in footnotes).
Tool descriptions for ctverify:extract and ctverify:status are verbose (>200 chars for extract) and could be condensed. Baseline for A+ tools is 50 - 200 chars; extract at ~350 chars is above the efficient range, risking token waste in LLM reasoning.
Irreversible operations (bib:delete) lack confirmation step or dry-run support. Agents can delete entries without a confirm-before-execute pattern. While a .bak backup is created, the LLM has no way to preview what will be deleted.