Loading ToolBench
MCP server for document operations (Word, Excel, PDF)
The server defines 5 document operation tools with basic schema structures, but suffers from significant gaps in descriptions, parameter documentation, and error guidance. Tool names follow verb_noun convention (positive), but descriptions are minimal and lack LLM-optimized detail. Parameter schemas are present but lack descriptions for most fields. Error handling is present but not actionable, returns success/failure booleans without recovery guidance. The operations parameter in edit_word_document and edit_excel_file accepts an array of dictionaries with variable schema depending on the 'type' field, but this polymorphic structure is not formally documented in the schema, making it ambiguous for LLMs. No parameter enums are used despite operations having finite, known types. Output schemas are present (returns dict) but not formally documented. Security: all tools perform file I/O with user-supplied paths, no validation against path traversal. No audit logging for destructive operations. This is a fair/poor implementation (C-/D+ range) typical of community servers lacking production polish.
Convert a text file to a Microsoft Word document.
Create a new Excel file with the provided content.
Create a new Microsoft Word document with the provided content.
Edit an existing Excel file using the specified operations.
Edit an existing Microsoft Word document using the specified operations.
Parameter descriptions missing for array/object fields. The 'operations' parameter in edit_word_document and edit_excel_file is documented as 'List of operations...' but does not describe the schema of each operation dict (required fields, valid types, constraints). LLMs cannot infer valid operation formats without explicit documentation of each operation type's expected parameters.
No input validation or path traversal protection. Tools accept arbitrary 'filepath' parameters without sanitization. An LLM could be tricked (via prompt injection) into passing '../../../../etc/passwd' or similar, reading/writing files outside intended scope. Requires input validation and sandboxing.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Operations use string 'type' instead of enum. Valid operation types (add_paragraph, add_heading, edit_paragraph, delete_paragraph, update_cell, etc.) are hard-coded in implementation but not exposed as schema enums. LLMs will invent invalid operation types, causing silent failures with generic error messages.
Error responses lack actionable recovery guidance. All errors return {success: false, message: '...'}. LLMs receive no classification (retryable vs fatal), no suggestions for next steps, no invalid value + constraint pairs. E.g., 'File not found' tells agent nothing about whether to check path or use a different tool.
Tool descriptions too brief (30-50 chars) to distinguish use cases. 'Create a new Microsoft Word document with the provided content' does not explain when to use create_word_document vs convert_txt_to_word, or whether content can be formatted. Baseline is 194 chars; these are 3-4x too short.
No polymorphic schema documentation. edit_word_document accepts operations with different shapes depending on type (add_paragraph takes 'text' and 'level', edit_paragraph takes 'index' and 'text', etc.). JSON Schema cannot cleanly express this polymorphism, and parameter description does not enumerate each operation type's required/optional fields. LLMs will guess at parameter names.
No output schema documentation. Tools return dicts with 'success', 'message', 'filepath' fields, but this is not formally documented in a structured return type schema. LLMs cannot reliably extract filepath from response or chain results to downstream calls.
No dry-run or confirmation for destructive operations. delete_paragraph and delete_column are irreversible; no dry-run mode or confirmation step exists. Agents making mistakes will silently corrupt files. Requires confirmation_request pattern.
Parameter format/constraint documentation missing. 'content' parameter in create_word_document and create_excel_file lacks guidance on format. For Excel, is CSV or JSON required? No max length, no examples, no validation hints.