Local-first DOCX formatter for academic papers with a content-fingerprint guard that proves the text was left untouched — only the formatting changed. Exposes the same local, content-guarded formatting pipeline used by the CLI as MCP tools.
Three tools with complete, well-documented definitions. All tools have clear action-verb names (format_, extract_, score_), comprehensive descriptions (140-200 chars each), and complete input schemas with typed parameters and descriptions. Descriptions exceed the 10-char minimum and are specific enough to guide LLM selection. Parameter descriptions explain purpose and constraints. Output schemas are documented in docstrings. No critical security issues (file paths are passed as strings, no secrets exposed). Main gaps: no enum constraints for the 'engine' parameter (accepts 'python'/'auto'/'word-com'/'libreoffice' but not enforced in schema), no explicit error handling guidance in descriptions, and no pagination or batch parameters (though not applicable here). Tool composition is sound, each tool has exactly one responsibility, with clear data flow from extract_format_rules → format_paper/score_paper chains.
Extract structured formatting rules from a format guide, without changing any file. Reads ``format_file`` (a .docx/.doc/.txt guide) and returns the parsed rules (margins, fonts, sizes, line spacing, headings, required sections, etc.) as a JSON-serializable dict. Useful for previewing what the formatter will enforce.
Reformat an academic paper DOCX to match a format guide, content-guarded. Extracts formatting rules from ``format_file`` (a .docx/.doc/.txt guide), applies them to ``paper_file`` (a .docx), and writes the formatted document plus reports into ``out_dir``. A content fingerprint of the body and table text is compared before and after; if that text changed, the run raises instead of writing a silently altered document (fail-closed).
Score a paper against a format guide read-only, without modifying it. Reads-only: extracts rules from ``format_file`` and scores ``paper_file`` against them, returning the score, per-check penalties, and actionable diagnostics. Does not write or alter any file.
engine parameter accepts free-form strings instead of enum constraint. The description lists valid values ('python', 'auto', 'word-com', 'libreoffice') but JSON schema does not enforce them. LLMs may pass invalid engine values, causing runtime errors instead of being rejected at schema validation.
Error handling descriptions are missing. Tools mention 'fail-closed' and content fingerprinting but do not describe what happens on errors, what recovery steps an LLM should take, or what error messages to expect. This violates the recovery-guide pattern.
Output schemas are documented in docstring comments but not formalized in JSON Schema. The mcp.tool() decorator does not show explicit returnType or output schema in the visible code. LLMs cannot programmatically parse the structure of returned dicts.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 79 | 2026-07-28+ | v2 |