Loading ToolBench
MCP server for Nutrient Document Engine that provides tools for document processing, extraction, annotation, and manipulation including text extraction, table extraction, form processing, document editing, and more.
The server exposes 21 tools covering document operations across read, write, and destructive categories. All tools have names, descriptions, and visible input schemas in src/mcpTools.ts. However, several critical quality gaps emerge: (1) Parameter descriptions are present but minimal (typically 10-30 chars, below the 72-char baseline for A-grade tools); (2) No output schemas are documented, callers cannot see what fields to expect from responses; (3) No error handling or recovery guidance is specified; (4) Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are missing despite risk categorization being assigned to tools; (5) Parameter constraints (enums, ranges, patterns) are largely absent, e.g., 'angle' parameter in rotate_pages accepts any integer, not the documented 90/180/270/-90/-180/-270 set. The naming is generally good (verb_noun pattern, no 'and' operations combining concerns), but parameter descriptions lack actionable constraints. Risk classification is present but not exposed to the protocol layer where it could guide agent behavior.
Add an annotation to a document
Add a new page to a document
Add a watermark to a document
Apply redactions to a document (permanently remove redacted content)
Create a redaction annotation on a document
Delete annotations from a document
Duplicate an existing document
No output schemas documented for any tool. Callers cannot discover what fields responses contain, forcing LLMs to guess or hallucinate response structure. This violates the pattern:tool-description baseline requiring full API contract documentation.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are missing from schema registration despite risk classification being internally assigned. Tools marked as DESTRUCTIVE (apply_redactions, delete_annotations) should expose destructiveHint=true to guide agent caution. This violates pattern:command-tool guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Extract form field data from a document
Extract key-value pairs from document content
Extract tables from a document
Extract text from a document or specific pages
Fill form fields in a document
Check the health and availability of the Document Engine service
List available documents
Merge pages from multiple documents into a single document
Read annotations from a document
Read document information and metadata
Render a document page as an image
Rotate pages in a document
Search for text within documents
Split a document into multiple documents
Parameter descriptions are minimal (10-30 chars typical vs 72-char baseline). Example: 'The page index to render' (26 chars) lacks guidance on valid range (0 to max_pages-1), whether it's 0-indexed or 1-indexed, or behavior when out of bounds. This prevents LLMs from constructing valid calls without trial-and-error.
No constraint enums declared for parameters with known value sets. rotate_pages accepts 'angle' as unconstrained integer, should declare enum [90, 180, 270, -90, -180, -270]. add_annotation 'type' parameter accepts free-form string, should be enum ['highlight', 'note', 'underline', ...]. This invites hallucinated values from LLMs.
No error handling or recovery guidance specified. If extract_text fails because page_index is out of bounds, or fill_form_fields fails because a field name is invalid, no tool description tells the LLM what to do next (e.g., 'Call list_documents first to confirm document exists' or 'See available fields in extract_form_data'). This violates pattern:recovery-guide.
list_documents lacks pagination parameters (limit, offset, next_cursor). If the document library grows to hundreds or thousands, a single unbounded list call will return too much data, bloating the context window and inviting hallucination. Pattern:paginated-result baseline requires pagination support.
merge_document_pages and split_document accept 'source_documents' and 'page_indices' as array parameters with undocumented item structure. Is a page_indices array [0, 2, 5] or [{page_index: 0}, {page_index: 2}]? Undocumented nested structures force LLMs to guess at valid syntax.
fill_form_fields accepts 'fields' as an object with undocumented key-value structure. Are keys field names or field IDs? What are valid value types (string, number, date, boolean)? Undocumented object shapes force LLMs to request schema discovery or infer from examples.