Loading ToolBench
Model Context Protocol (MCP) server exposing stemma's tracked-change DOCX editing verbs over stdio.
Stemma-mcp exposes 7 DOCX-manipulation tools with complete JSON schemas and descriptions. All tools have descriptions (10-200 chars) and input schemas with typed parameters. However, schemas lack depth: selector parameters in accept_changes/reject_changes use generic 'object' type with oneOf-style properties but no explicit discriminator or required field constraints. Output schemas are entirely undocumented, LLMs cannot predict what these tools return. Error handling is absent from descriptions; no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Parameter descriptions are minimal (e.g., 'Change selector: one of by_ids...' lacks format/constraint details). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (WRITE vs READ_ONLY). Naming is verb-first and clear (accept_, reject_, check_, validate_, apply_, review_, audit_), but descriptions do not explain WHEN to use each tool or what distinguishes review_session from audit_docx.
Accept tracked changes in a DOCX document by revision selector (by IDs, by author, by range, or all)
Apply a batch of edit transactions to a DOCX document in sequence
Generate an audit report for a DOCX document, including revision history and change summary
Validate a proposed edit transaction against a DOCX document without applying it
Reject tracked changes in a DOCX document by revision selector (by IDs, by author, by range, or all)
Open an interactive review session for a DOCX document, returning the document structure and tracked changes
Validate a DOCX file for OOXML compliance and structural integrity
Output schemas completely undocumented. LLMs cannot predict return types, field names, or structure for any of the 7 tools. This forces agents to guess what data is available and breaks tool chaining.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk levels. accept_changes, reject_changes, apply_batch are marked WRITE but lack destructiveHint. This prevents agents from reasoning about side effects and retry safety.
Selector parameter in accept_changes/reject_changes uses generic 'object' type with oneOf-style properties (by_ids, by_author, by_range, all) but no discriminator, required field constraints, or format guidance. LLMs cannot determine which selector variant to use or how to construct valid input.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
No error handling guidance in any tool description. No indication of retryability, user-fixable vs fatal errors, or recovery paths. Agents cannot determine what to do if a tool fails.
review_session and audit_docx have overlapping purposes (both inspect DOCX state) but descriptions do not clarify when to use each. review_session returns 'document structure and tracked changes'; audit_docx returns 'audit report...revision history'. Ambiguous distinction invites wrong tool selection.