Loading ToolBench
MCP server for manipulating Microsoft Word documents
This MCP server implements 26 Word document manipulation tools with visible schemas and descriptions. Naming is generally clear and action-verb based (get_*, add_*, create_*, format_*). However, several quality gaps emerge: (1) Many parameter descriptions are minimal, often just reiterating the parameter name without explaining constraints, valid values, or when to use them. (2) Output schemas are not documented in the tool definitions, responses are JSON strings without declared field structures, forcing LLMs to parse unstructured text. (3) Error handling is present but generic; most tools return JSON with 'success' and 'error' fields but lack actionable recovery guidance. (4) No enums are used for constrained parameters (e.g., heading level 1-9, border styles, shading patterns); these accept free strings, inviting invalid input. (5) Several tools combine related operations (e.g., add_heading + format headings) that could be split for better composability. Input schemas are visible and properly typed, which is a baseline strength. Description lengths vary widely, some tools have good 50-100 char descriptions; others are generic 20-40 char stubs. Per-tool analysis below shows this variance.
Add an endnote to a specific paragraph in a Word document.
Add a footnote after specific text in a Word document with proper formatting.
Add a footnote to a specific paragraph in a Word document.
Add a heading to a Word document with optional formatting.
Add a paragraph to a Word document with optional formatting.
Add an image to a Word document.
Add a table to a Word document.
Output schemas not documented. Tools return JSON strings (e.g., '{"success": true, "comments": [...]}') but the MCP tool definitions do not declare output field structure. LLMs cannot know what fields to expect without parsing the response as unstructured text.
Parameter descriptions lack actionable constraints. Examples: heading 'level' param (1-9) has no enum or description stating the range; 'border_style' in format_table accepts free strings but should enumerate ['none', 'single', 'double', 'thick']; color parameters accept hex or named colors but validation rules are not documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Convert all footnotes to endnotes in a Word document.
Convert a Word document to PDF format.
Create a copy of a Word document.
Create a custom style in the document.
Create a new Word document with optional metadata.
Find occurrences of specific text in a Word document.
Format a table with borders, shading, and structure.
Format a specific range of text within a paragraph.
Extract all comments from a Word document.
Extract comments from a specific author in a Word document.
Extract comments for a specific paragraph in a Word document.
Get information about a Word document.
Get the structure of a Word document.
Extract all text from a Word document.
Get the raw XML structure of a Word document.
Get text from a specific paragraph in a Word document.
List all .docx files in the specified directory.
Merge multiple Word documents into a single document.
Apply shading/filling to a specific table cell.
Generic parameter descriptions. 'filename' is described only as 'Path to the Word document' across all 26 tools, no guidance on whether it should be relative/absolute, whether it must exist, or whether to use forward/backslash on Windows. 'text' param is described only as 'Heading text' or 'Paragraph text' with no character limits, encoding requirements, or examples of what happens with special characters or line breaks.
Error handling is present but not actionable. All tools return JSON with 'success': false and an 'error' string. However, the error messages do not guide LLM recovery: e.g., 'Document does not exist' does not suggest calling list_available_documents(); 'Invalid paragraph index' does not hint at how many paragraphs are available. Errors lack the 'Categorize errors as retryable, user-fixable, or fatal' pattern.
Tools combine multiple concerns that could be split for better composability. E.g., add_heading combines text insertion + multi-level formatting (font, bold, italic, border), could be separate 'add_heading' + 'format_heading'. add_table combines creation + optional data population, which could be 'create_table' + 'populate_table'. This reduces flexibility in agent composition.
No batch operations. Agents needing to add 10 paragraphs must make 10 sequential calls to add_paragraph. A batch variant (e.g., add_paragraphs with array input) would reduce latency and token waste.