Loading ToolBench
AI-optimized DOCX manipulation engine: deterministic OOXML editing with tracked changes, hash-anchored addressing, and a token-efficient agent view.
DocxEngine provides 11 well-named tools with complete input schemas and descriptions. Tool names follow verb_noun convention (docx_replace, docx_edit_paragraph, docx_insert, docx_delete, docx_validate, docx_repair, docx_save, docx_open, docx_outline, docx_read, docx_search). All tools have descriptions (10 - 200 chars, within baseline 10 - 1024 range). All parameters have type definitions and descriptions. However, output schemas are not documented in the provided source, only input schemas are visible. Error handling is present (ToolError with codes like 'not_found', 'ambiguous_target') but recovery guidance is minimal. Parameter descriptions are functional but lack format/constraint details (e.g., 'anchor hash' is unexplained; 'response_format' accepts 'concise' or 'detailed' but this is not enumerated in schema). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible in the code, despite clear risk classifications (READ_ONLY, WRITE, DESTRUCTIVE, WRITE). This is a significant gap for agent planning.
Delete one paragraph or a contiguous range; tracked deletion is a redline.
Rewrite a paragraph's full text; tracking emits the §6 minimal word-level redline.
Insert new paragraphs (plain text or minimal Markdown) after/before an anchor.
Open a .docx from a path or base64 bytes; returns the doc_id handle + summary.
The heading tree and table list with anchors, style cascade resolved.
The Markdown projection of an anchor window, a range, or a whole story.
Apply the §8a mechanical fixes; reports what was fixed and what remains.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'returns the doc_id handle + summary') but formal output schema definitions are not visible in source. LLMs cannot plan downstream calls without knowing return field names and types.
Tool annotations missing. Tools are classified by risk (READ_ONLY, WRITE, DESTRUCTIVE) but no readOnlyHint, destructiveHint, or idempotentHint annotations are visible in the MCP registration. Agents cannot distinguish safe from unsafe operations without explicit hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Replace text in one anchored paragraph or across the whole body.
Validate (§8), then write atomically (§9). Refuses on error-severity issues.
Coalesced-text search: matching anchors with snippets and heading context.
Run the §8 package checks; issues carry severity/part/message/fix_hint.
Parameter constraints not enumerated in schema. 'response_format' accepts 'concise' or 'detailed' but is defined as a free-form string, not an enum. 'scope' in docx_read and docx_search similarly lacks enum constraint. LLMs may hallucinate invalid values.
Error recovery guidance minimal. ToolError codes ('not_found', 'ambiguous_target') are present but error responses do not consistently guide the agent on next steps. E.g., 'Text not found' should suggest 'Try docx_search() to locate the exact text.'
Anchor hash format undocumented. 'anchor' parameter appears in 8 tools but its format, generation, and lifecycle are not explained in parameter descriptions. Agents cannot reason about when anchors become stale or how to obtain them.