Loading ToolBench
Universal Document Knowledge Graph MCP Server for AI Agents. Indexes technical digital PDFs into structured knowledge graphs, enabling AI agents to navigate and retrieve compact, evidence-backed context with strict provenance and token budgeting.
DocuGraph demonstrates solid tool design with consistent naming (verb_noun pattern), comprehensive parameter schemas using JsonSchema, and detailed descriptions. All 10 tools follow the document_* prefix convention and include structured input/output types. However, several tools lack output schema documentation in the visible code, and some parameter descriptions could be more prescriptive about constraints and error recovery. Error handling is present but minimal, most tools lack actionable recovery guidance. The server shows good composition (each tool has one clear responsibility) and proper parameter typing, placing it in the B/good range.
List embedded file attachments (e.g. ZUGFeRD XML, CSV, datasets) in a document with metadata.
Extract interactive form fields (AcroForms) from a document, with optional page filtering and filled-only mode.
Extract hyperlinks and internal cross-references from a document, with optional page and link-type filtering.
Retrieve the full text of a specific section by its identifier, with optional parent context and token limiting.
Get structural metadata, page count, and section overview for an indexed document.
List the indexed PDF documents, with page counts, SHA-256 hashes, and the cache directory they were read from. Call this first to learn the document_id values the other tools take.
Output schemas not documented in visible code. While input schemas are well-defined via JsonSchema structs (DocumentQueryParams, RenderPageResult, etc.), the actual response structures for most tools are inferred from Rust types but not explicitly documented in tool registration. LLMs need to know what fields to expect in responses to plan downstream calls.
Error handling lacks actionable recovery guidance. Tools return errors but do not guide the LLM on next steps (e.g., 'document not found, call document_list() to see available IDs'). This forces agents to guess recovery strategies.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Retrieve the hierarchical table of contents for a document, with optional depth limiting.
Search indexed documents using hybrid BM25 + semantic retrieval with configurable output modes (evidence, context, or ranked hits) and strict token budgeting.
Read a contiguous range of pages from a document as plain text, with character limiting to prevent context explosion.
Render a single page of a PDF document to a PNG image with configurable resolution, returning base64-encoded data and data URI.
Parameter constraints not fully specified in descriptions. For example, document_render_page.max_width has min/max bounds (200 - 2048) documented in the description, but document_query.max_tokens and max_items lack guidance on reasonable ranges. Descriptions should state 'default: 1200, recommended: 500 - 2000' to prevent LLM hallucination of extreme values.
document_get_links and document_get_forms lack explicit enum validation in descriptions. The 'kind' parameter in document_get_links accepts 'all|external|internal' but the description does not emphasize these are the ONLY valid values. LLMs may hallucinate alternatives like 'mailto' or 'anchor'.
No pagination or result-limiting guidance for document_list when corpus is large. If hundreds of documents are indexed, returning all summaries could exhaust context. The tool should document a limit and offer pagination (offset/limit or cursor).