A Model Context Protocol server providing tools to read/write docx files
This server defines 4 tools for DOCX manipulation with explicit schemas and descriptions visible in mcp_server_office/tools.py. All tools have input schemas and descriptions, but several quality gaps prevent a higher score: (1) Naming is inconsistent, 'edit_docx_insert' and 'edit_docx_paragraph' lack clear verb-noun distinction and conflate multiple editing strategies; (2) Descriptions are present but generic, lacking WHEN to use guidance or clear state-modification warnings; (3) Parameter descriptions exist but are sparse, many lack format/constraint details; (4) No output schemas are documented, forcing LLMs to infer response structure; (5) No error handling guidance provided. The server sits at the lower end of 'fair' (C grade), with functional but underspecified tool definitions.
Insert new paragraphs into a docx file. Accepts a list of inserts with text and optional paragraph index. Each insert creates a new paragraph at the specified position. If paragraph_index is not specified, the paragraph is added at the end. When multiple inserts target the same paragraph_index, they are inserted in order. Returns a git-style diff showing the changes made.
Make text replacements in specified paragraphs of a docx file. Accepts a list of edits with paragraph index and search/replace pairs. Each edit operates on a single paragraph and preserves the formatting of the first run. Returns a git-style diff showing the changes made. Only works within allowed directories.
Read complete contents of a docx file including tables and images. Use this tool when you want to read file endswith '.docx'. Paragraphs are separated with two line breaks. This tool convert images into placeholder [Image]. '--- Paragraph [number] ---' is indicator of each paragraph.
Create a new docx file with given content. Editing exisiting docx file with this tool is not recomended.
No output schemas documented. LLMs cannot predict what fields are returned (git-style diff? JSON? raw text?) or how to chain subsequent tool calls. This violates the pattern:tool-description and pattern:response-shaper requirements.
Tool naming lacks clarity in distinguishing edit operations. 'edit_docx_insert' vs 'edit_docx_paragraph' does not follow the verb_noun pattern clearly, both start with 'edit_docx' and force LLMs to read descriptions to understand the difference. Consider 'insert_docx_paragraphs' and 'replace_docx_text' for disambiguation.
Missing state-modification warnings. 'write_docx' and editing tools create or modify files, but descriptions do not explicitly warn of destructive behavior. Per pattern:command-tool, write operations must declare their irreversibility to enable agent caution. write_docx description says 'not recommended for editing' but does not say what it DOES do (create/overwrite).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Parameter descriptions lack format and constraint details. 'path' parameter in all tools says 'Absolute path' but does not specify: (1) must be under current working directory (edit tools hint at this but read_docx/write_docx do not); (2) .docx file extension required; (3) file must exist (for read_docx) or not exist (for write_docx). Format constraints should be explicit in descriptions per pattern:constrained-input.
write_docx content parameter description is dense and hard to parse. It mixes multiple encoding rules ('Two line breaks = paragraph', 'Table starts with [Table]', 'escape line breaks'). No example provided despite complexity. LLMs will struggle to format content correctly. Should be reformatted into clearer, bullet-point guidance or examples.
No error handling guidance. If a file is not found, path is invalid, or edit indices are out of bounds, tools provide no recovery hints. Per pattern:recovery-guide, errors must tell the LLM what to do next (e.g., 'File not found. Call read_docx with a valid path or use write_docx to create it.').
edit_docx_paragraph description mentions 'Only works within allowed directories' but does not define what 'allowed directories' are. This is a security-relevant constraint that should be explicit in the tool description to avoid agent confusion or misuse.