Template-driven docx generation MCP server: AI writes the content, your template controls the style.
Two well-defined tools with comprehensive schemas and detailed descriptions. Both tools have clear verb-noun naming (inspect_template, render_document) and extensive parameter documentation. Schemas are complete with proper JSON Schema types and descriptions. However, error handling lacks actionable recovery guidance, and output schemas are described in prose rather than formally documented. No tool annotations (readOnlyHint/destructiveHint) despite clear risk profiles. Descriptions are excellent (200+ chars each), exceeding the 10-1024 baseline. Parameters are well-typed with constraints documented inline.
Inspect a .docx template before rendering: returns every {{placeholder}} it contains (name, kind, location), the style catalog (style_id, name, kind, in_use), the document outline as content blocks (headings and table anchors), and whether the body has a {{content}} anchor. Any ordinary Word document works as a template with no preparation. Call this first to learn what data fields and styles render_document can use.
Render a .docx template into a finished document. 'data' fills {{placeholder}} values (scalars fill {{name}}; an array of objects loops a {{#section}} table row; a false/empty value removes a {{#section}} conditional). 'blocks' writes free-form content: into the {{content}} anchor when the template has one, otherwise replacing the whole body while headers, footers, page setup, and styles are kept from the template. Both may be combined or omitted (omitting both copies the template). Styling always follows the template; missing styles degrade gracefully and every degradation is reported in 'warnings'. Returns {"output_path": ..., "warnings": [...]}.
Output schemas not formally documented. Both tools describe return values in prose (e.g., 'Returns {"output_path": ..., "warnings": [...]}') rather than as structured JSON Schema. LLMs cannot reliably parse prose schemas for downstream tool chaining.
Missing tool annotations. render_document is destructive (WRITE risk) and inspect_template is read-only, but neither declares destructiveHint or readOnlyHint. Agents cannot infer safety properties without explicit annotations.
Error handling lacks recovery guidance. No documented error cases, retryability classification, or actionable next steps. E.g., if template_path is invalid or render fails due to missing styles, the LLM receives no guidance on what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 79 | 2026-07-28+ | v2 |
render_document 'blocks' parameter uses oneOf with inline type discriminator but lacks clear enum documentation. The 'type' field values (heading, paragraph, table, list, image, page_break) are discoverable only by reading the schema, not the description.
No pagination or result limits documented. inspect_template returns 'every {{placeholder}}' and 'style catalog' without stating max counts. Large templates could produce unbounded output, risking context window exhaustion.