verified-docx-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VERIFIED_DOCX_MCP_ALLOWED_FILE_ROOTS | No | Colon-separated list of allowed file roots for path safety. Defaults to the user's home directory. This allowlist is used to resolve path arguments. | User's home directory |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| export_pdfA | Render a local .docx to PDF via Microsoft Word and report its page count. output_path must fall inside VERIFIED_DOCX_MCP_ALLOWED_FILE_ROOTS (defaults to the user's home directory), must not resolve to a credential path, and its parent directory must already exist. This is a read/render tool: the source .docx is never modified (Word opens a private staged copy — see render.py), so the return value has no "applied" key. Returns pdf_path, sha256, page_count (best-effort; None — never a guessed 0 — when it cannot be determined), page_count_source ("word"|"pdfinfo"|"regex"|None), engine ("word"; the only engine, D2: no LibreOffice), and left_open_document (the rendered document's window title in Word — see render.py's module docstring for why it is never auto-closed). Errors:
INVALID_INPUT - a bad path or output_path
RENDER_ENGINE_UNAVAILABLE - no render engine available (Word only)
AUTOMATION_NOT_GRANTED - macOS declined Automation control of Word
for this app; run |
| lock_statusA | Report Word/LibreOffice owner-file presence and sync-quiesce state. Data only — never refuses. Owner-file detection recognizes Word's "~$" owner file (matched by shared filename suffix, not by constructing one exact expected name — see _word_owner_file_matches's docstring) and LibreOffice's ".~lock.#". Sync-quiesce takes two (size, mtime_ns) samples ~1.5s apart and also checks for ".tmp"/".~*" siblings in the same directory (OneDrive/iCloud staging artifacts); "sync_quiesced" is false if either signal suggests the file is still being written. Returns path, owner_file ({present, path, format, owner_name}), sync_quiesced, sync_detail ({sample_1, sample_2, interval_seconds, tmp_siblings}). Errors: INVALID_INPUT - path does not exist or is outside the allowed roots |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
export_pdf and lock_status have completely different purposes: one renders a docx to PDF, the other inspects owner/lock and sync state. There is no overlap in inputs, outputs, or side effects, so an agent should never confuse them.
Both names use snake_case and are readable, but export_pdf follows an imperative verb+object pattern while lock_status is a noun phrase without a verb. Adding a verb like get_lock_status or check_lock_status would make the naming pattern consistent.
Two tools is on the thin side and feels closer to a utility script than a full MCP server. However, the server appears intentionally scoped to safe docx rendering and preflight lock inspection, so the count is borderline rather than excessive.
The two tools cover the core workflow of checking whether a docx is locked/syncing and then rendering it to PDF. Minor gaps exist—such as no explicit docx validity check or wait-for-quiesce helper—but agents can work around them with repeated lock_status calls and careful error handling.