Loading ToolBench
MCP Doc Forge presents a collection of document processing tools with mixed quality. While all 16 tools have explicit schema definitions and basic descriptions, the definitions lack depth and sophistication expected of production-grade tools. Tool naming is inconsistent (some use verbs like 'document_reader', others use passive constructions like 'pdf_merger'). Descriptions are brief but present (avg ~60-70 chars), meeting the bare minimum. Schemas are present and properly structured with required fields, but lack output schema documentation and error handling guidance. Parameter descriptions exist but are minimal. Critical issues: (1) No output schemas documented for any tool, leaving LLMs uncertain about return structures. (2) No error handling guidance, tools return generic success/error objects without actionable recovery paths. (3) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite 9+ destructive/write tools. (4) Parameters lack type hints and validation constraints, e.g., 'fromEncoding' and 'toEncoding' accept free strings with no enum constraint. (5) File path parameters expose potential path traversal vulnerabilities (no sanitization visible in schema). (6) Tool names use inconsistent patterns, some start with object then verb (pdf_merger, html_cleaner), others start with verb (document_reader). This violates the verb_noun naming convention.
Read content from non-image document-files at specified paths, supporting various file formats: .pdf, .docx, .txt, .html, .csv
Convert DOCX to HTML while preserving formatting
Convert DOCX files to PDF format
Read Excel file and convert to JSON format while preserving structure
Convert between different document formats (Markdown, HTML, XML, JSON)
Clean HTML by removing unnecessary tags and attributes
Extract all resources (images, videos, links) from HTML
No output schemas documented for any of the 16 tools. LLMs cannot determine what fields/structure to expect from responses, forcing them to guess or treat responses as opaque strings. This violates the fundamental pattern:tool and pattern:response-shaper requirements.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. 9 tools are marked WRITE (destructive) but lack destructiveHint annotation. LLMs cannot determine which tools are safe to retry or have irreversible consequences.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Format and beautify HTML code
Convert HTML to Markdown format
Convert HTML to plain text while preserving structure
Merge multiple PDF files into one
Split a PDF file into multiple files
Compare two text files and show differences
Convert text between different encodings
Format text with proper indentation and line spacing
Split text file by specified delimiter or line count
Encoding parameters ('fromEncoding', 'toEncoding' in text_encoding_converter) accept free-form strings without enum constraints. Invalid encodings like 'fake_encoding' would be passed to the tool without validation. Should use enum: ['utf8', 'utf16', 'ascii', 'big5', 'gbk'] etc.
File path parameters (filePath, inputPath, outputDir, etc.) have no validation hints or sanitization guidance in schemas. Path traversal attacks (e.g., '../../../etc/passwd') are not prevented at schema level. While implementations may sanitize, the schema should document expected path constraints.
No error handling guidance in tool descriptions or schemas. Tools return generic {'success': true/false, 'data'/'error': string} but do not tell LLMs what to do on failure. Should include recovery guidance like 'If file not found, use document_reader with correct path' or indicate which errors are retryable.
Tool naming is inconsistent. 'pdf_merger' and 'html_cleaner' start with object/noun, while 'document_reader' and 'text_splitter' use verb_noun. Inconsistency confuses LLMs, some tools should be renamed to verb_noun: 'merge_pdfs', 'clean_html', 'extract_html_resources' for clarity.
Parameter descriptions are minimal (typically 1 sentence, ~20-50 chars). Should include format, constraints, and examples. E.g., 'outputDir' currently says 'Directory where merged PDFs should be saved' but should say 'Directory where merged PDFs should be saved (must exist; relative paths from cwd)' or similar.
html_extract_resources tool lacks clarity on what 'resources' means. Should specify: 'Extracts images, videos, stylesheets, scripts, and links (returns list of URLs or file paths depending on whether content is embedded or external).'
text_splitter 'value' parameter is overloaded. When splitBy='lines', value should be a number; when splitBy='delimiter', it should be a string. Schema shows type: string for both. Should either split into two separate tools or use oneOf schema with conditional validation.
excel_read tool returns undefined output schema. Code mentions 'convert to JSON format' but schema does not document what the JSON structure looks like. Should document: is it an array of objects (rows)? Does it include sheet metadata? Are headers separate?