Loading ToolBench
Model Context Protocol server for Paperless-ngx, backed by pypaperless.
Solid foundation with consistent naming (verb_noun pattern), reasonable descriptions (avg ~80 chars), and documented input schemas. However, output schemas are not explicitly documented in the source, parameter descriptions lack detail on constraints/formats, and error handling guidance is minimal. 11 of 14 tools are READ_ONLY (good for safety), but 3 tools (triage_inbox, monthly_review, find_duplicates) are prompts, not traditional tools, their input schemas are empty, which violates the parameter documentation requirement. Pagination is well-implemented across list tools (offset/limit pattern), but descriptions don't explain when to use each tool or what distinguishes similar ones (e.g., list_tags vs list_correspondents).
Workflow prompt for finding duplicate documents
Get document fields and short content preview
Get full OCR'd text of a document
Get Paperless-ngx server information and version
List all correspondents with pagination
List all document types with pagination
List saved views (curated queries) with pagination
Three prompt-based tools (triage_inbox, monthly_review, find_duplicates) have empty input schemas and minimal descriptions. Prompts are not traditional tools and should not be scored as tools; if they are meant to be tools, they need proper input schemas and descriptions explaining when/why to invoke them.
Output schemas are not documented in the source code. LLMs cannot plan downstream calls or extract required fields (e.g., document IDs for chaining) without knowing what search_documents or get_document returns. This violates the pattern:tool requirement.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
List all storage paths with pagination
List all tags with pagination
List deleted documents with pagination
Workflow prompt for monthly document review
Execute a saved view query
Search documents with full-text query and Django-style filters
Workflow prompt for triaging inbox documents
Parameter descriptions lack constraint details. 'limit' is described as 'Maximum 100 items per page' but does not specify minimum (1?), default, or whether it's required. 'query' in search_documents lacks format guidance (full-text syntax, wildcards, boolean operators). Descriptions should state expected format, range, and allowed values per pattern:constrained-input.
List tools (list_tags, list_correspondents, etc.) have identical descriptions and parameter sets but no guidance on when to call each. LLMs cannot distinguish between them without additional context. Descriptions should explain what each list reveals and when to use it (e.g., 'Call this to discover available tags before filtering documents').
No error handling guidance visible in tool descriptions. If search_documents returns no results, or get_document fails with 404, the descriptions do not tell LLMs what to do next (e.g., 'Try a broader query' or 'Verify the document ID'). This violates pattern:recovery-guide.