Loading ToolBench
Dependency-free stdio MCP server for native MathType automation in Word and PowerPoint
This MCP server implements 8 well-structured tools for MathType automation in Microsoft Office. Tool definitions are explicit and visible in scripts/mcp_server.py with proper schema declarations and annotations. Strengths: all tools have descriptions (194-300+ chars), comprehensive tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), clear verb-noun naming conventions, and proper JSON Schema with required/properties/additionalProperties. Weaknesses: parameter descriptions are minimal or absent (only 'Absolute path to X' provided), no output schemas documented, no error recovery guidance, no pagination or result-limiting patterns for list-like tools, and missing actionable error messages. The server targets a specialized domain (MathType Office automation) where the tool interface is appropriate, but the parameter annotation quality falls short of production baselines (94% of A+ tools have full param descriptions; this server has ~20-30% coverage).
Persist the skill default: simple equation numbers (1), (2), ...; no chapter or section component; whole-document application; automatic field updates; first-number warning enabled; reference warning disabled. The bridge enforces this format on every processed document and updates the matching MathType warning preferences for the user.
Check PowerPoint COM, MathType 7 desktop, its PowerPoint add-in, and Equation.DSMT4 registration required for direct editable MathType OLE equations in PPTX.
Check Windows, Microsoft Word COM, MathType 7, the Word add-in template, and Equation.DSMT4 registration. This is read-only.
Silently replace marker-only PPTX text boxes with editable, centered Equation.DSMT4 floating OLE objects through hidden Word MathType conversion and MathML validation. PowerPoint has no MathType-native Word equation numbering/reference mechanism.
Replace manifest markers in a DOCX with genuine Equation.DSMT4 MathType OLE equations. Numbered displays use MathType-native MTPlaceRef/SEQ fields in (1) format. References use MathType's MTReference placeholder and GOTOBUTTON/REF pipeline, never Word numbered lists.
Parameter descriptions are minimal or missing entirely. Tools accept file paths (input_path, output_path, manifest_path, document_path, presentation_path) but descriptions only state 'Absolute path to X' without explaining what format is expected, how the path is resolved, or what happens if the file is not found. LLMs cannot infer error recovery from these bare descriptions.
No output schemas are documented. Tools like render_mathtype_word_document and validate_mathtype_word_document perform complex operations but do not specify what fields/structure they return. LLMs cannot plan downstream tool calls or extract required data (e.g., validation success/failure details, error details) without knowing the response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Update all Word fields in a DOCX so MathType equation numbers and references refresh. Write to a new output path, or pass overwrite=true to update the input in place.
Verify that a PPTX contains the expected named, centered Equation.DSMT4 OLE objects, that their embedded MathML matches the manifest, and that no markers remain.
Open a DOCX read-only and verify genuine Equation.DSMT4 objects, simple MathType-native number fields, native references and target bookmarks, sequential numbering, resolved markers, and absence of Word built-in OMath equations.
Missing actionable error handling and recovery guidance. The server implements PowerShell subprocess calls (scripts/mcp_server.py uses subprocess to invoke mathtype-word.ps1) but does not document what error states are possible, how they are signaled (status codes, error messages), or what the LLM should do to recover (retry, call a different tool, ask the user). Pattern compliance requires error responses to tell the agent what to do next.
Path traversal and injection vulnerabilities. Tools accept file paths as strings (input_path, output_path, manifest_path) without visible sanitization or validation. An LLM could be tricked into passing relative paths (../../../sensitive.docx) or command injection payloads in manifest_path that are passed to subprocess. Security pattern requires input sanitization.
The overwrite parameter defaults to false with no warning in descriptions. For destructive tools (render_mathtype_word_document, update_mathtype_word_fields), the description should explicitly state the default behavior and recommend when to set overwrite=true. Currently, an LLM cannot infer whether overwrite=false means 'fail if file exists' or 'skip overwrite silently'.
No dry-run or confirmation pattern for destructive operations. The render_* and update_* tools are irreversible (they modify DOCX and PPTX files). Following the confirmation-request pattern, these tools should support a dry_run mode or require explicit confirmation before writing to disk.
manifest_path parameter on render and validate tools lacks schema constraints and description of expected format. No indication of what constitutes a valid 'schema v1 JSON manifest', is it a specific JSON structure? Where does it come from? How does the LLM know what to pass?