Loading ToolBench
MCP server for Nutrient DWS Processor API
This server provides 7 tools with moderately good descriptions and schemas. Most tools have proper naming conventions (verb_noun pattern) and detailed descriptions (ranging from 180-800 chars, above the 194-char baseline). However, there are several significant gaps: (1) Input schemas lack depth, parameters have descriptions but many lack type constraints, enums, and range specifications; (2) Output schemas are not documented for any tool, making it unclear what structured data agents should expect; (3) Some parameter relationships are underdocumented (e.g., 'stage' and 'apply' in ai_redactor are mutually exclusive but this is only weakly hinted); (4) Error handling guidance is absent, tools do not explain retryability, recovery steps, or what happens on failure; (5) Security concerns around file paths are not addressed (no mention of path traversal validation). The server does show strengths: verb-first naming (document_processor, parse_document, extract_fields), detailed feature lists in descriptions, and explicit risk categorization (DESTRUCTIVE, READ_ONLY, WRITE).
Detect and permanently redact sensitive content using the Nutrient AI Redaction API. Reads input files from the local file system or sandbox (if enabled) and writes redacted output back locally. Automatically detects and permanently removes sensitive information from documents using AI analysis. Detected content types include: • Personally identifiable information (names, addresses, phone numbers) • Financial data (credit card numbers, bank accounts, SSNs) • Email addresses and URLs • Protected health information (PHI) • Any custom criteria you specify By default (when neither stage nor apply is set), redactions are detected and immediately applied. Set stage to true to detect and stage redactions without applying them. Set apply to true to apply previously staged redactions.
Check your Nutrient DWS API credit balance and usage for the current billing period. This is a read-only account lookup. It does not upload any document content. Returns: subscription type, total credits, used credits, and remaining credits.
List the contents of a directory in a sandbox-aware way. Returns a tree of files and subdirectories with metadata (size, type, modification time).
Process, convert, and transform documents using the Nutrient API. Reads input files from the local file system or sandbox (if enabled) and writes results back locally. Features: • Import XFDF annotations • Flatten annotations • OCR processing • Page rotation • Watermarking (text/image) • Redaction creation and application Output formats: PDF, PDF/A, images (PNG, JPEG, WebP), Office (DOCX, XLSX, PPTX) For structured data extraction (typed JSON or Markdown with bounding boxes and confidence scores), use the dedicated parse_document tool instead.
Output schemas completely undocumented across all 7 tools. LLMs cannot predict what structured data to expect, forcing them to guess or make wasteful follow-up calls.
Nested object schemas lack type information. 'instructions' in document_processor and 'signatureOptions' in document_signer are typed as 'object' with no documented nested fields, forcing LLMs to infer the structure or make invalid calls.
Enum constraints not visible in schemas. parse_document accepts 'formats' and 'mode' parameters; descriptions list allowed values ('spatial', 'markdown', 'text', 'structure', 'understand', 'agentic') but no formal enum constraints prevent LLMs from passing invalid values.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Digitally sign PDF files using the Nutrient Sign API. Reads input files from the local file system or sandbox (if enabled) and writes signed output back locally. Signature types: • CMS/PKCS#7 (standard digital signatures) • CAdES (advanced electronic signatures) Appearance options: • Visible or invisible signatures • Multiple display modes (signature only, description only, or both) • Customizable elements (signer name, reason, location, date) • Support for watermarks and custom graphics Positioning: • Place on specific page coordinates • Use existing signature form fields
Pull specific named fields out of a document into a JSON shape you define, using the Nutrient DWS Data Extraction API. Reads the input file from the local file system or sandbox (if enabled), or fetches it directly from a URL — provide exactly one of filePath or url. Unlike parse_document, which parses a whole document, extract_fields targets specific fields. Define the shape of the returned object by passing fieldDescriptions, which describe what to extract and how to type it.
Extract structured data from a document using the Nutrient DWS Data Extraction API. Reads the input file from the local file system or sandbox (if enabled), or fetches it directly from a URL — provide exactly one of filePath or url. Output formats: • spatial — typed elements (paragraphs, tables, key-value pairs, formulas, pictures, handwriting) with bounding boxes, confidence scores, and reading order. Written to outputPath (the list can be large). • markdown — whole-document Markdown. Returned inline, or written to outputPath when provided (recommended for large documents). Good for RAG and search indexing. • Both at once via formats: ["spatial", "markdown"] — a second format costs no extra credits, so ask for both up front instead of extracting twice. Processing modes (cost per page): text = fast Markdown, no OCR (1 credit); structure = OCR spatial (1.5 credits); understand = AI-augmented, default (9 credits); agentic = VLM-augmented (18 credits). Note: markdown output and any extracted content are returned into this conversation and may be logged by the host. For sensitive documents, prefer spatial output to a file plus targeted extract_fields calls.
No error handling or recovery guidance. Tools do not document what happens on failure, whether errors are retryable, or what the LLM should do next. No distinction between 'API offline' (retry) vs 'invalid file path' (user correction needed).
Mutually exclusive parameters documented inconsistently. parse_document and extract_fields accept mutually exclusive filePath/url; ai_redactor accepts mutually exclusive stage/apply. Descriptions note this weakly; should be explicit in the parameter descriptions and enforced with clear error messages.
Path traversal and input validation not addressed. document_processor, document_signer, ai_redactor, parse_document accept file paths; no mention of path sanitization or traversal prevention. LLM could be tricked into reading/writing arbitrary files.
Missing idempotency guidance. Destructive tools (document_processor, document_signer, ai_redactor) do not document whether repeated calls with identical parameters are safe. Agents may retry on ambiguous failures, causing duplicate actions.