docs-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROOT | No | The resolution root for relative paths (--root <dir>). Defaults to the process cwd. | . |
| ALLOW_WRITE | No | Restricts writes to the given directory (--allow-write <dir>); may be repeated. If omitted, no additional restriction is applied. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| docx_readA | Read a Microsoft Word .docx document and return its paragraphs with 1-based indices. Use this before docx_edit: the returned paragraph Modes:
Large documents are paged: pass from/to to move through them, and check |
| docx_editA | Apply edits to a Microsoft Word .docx document and write the result back. Call docx_read first to learn paragraph indices. All Operations:
By default the file is modified in place, and the first in-place edit leaves a one-time backup next to it as ".orig.docx". Pass output_path to write elsewhere instead, or dry_run:true to see what would change without writing anything. |
| docx_createA | Create a new Microsoft Word .docx document from plain text. Each paragraph is either a string, or an object {text, style} where style is a Word style id such as Heading1, Heading2 or Title. The produced file is a valid OOXML package that opens in Word, WPS and LibreOffice. Fails if the target path already exists — pick another path instead of overwriting by accident. |
| pdf_infoA | Open a PDF and report what it is: page count, document metadata, whether it has a real text layer, and its table of contents. Call this first, before pdf_read or pdf_render_page. It tells you which reading strategy works:
The returned |
| pdf_outlineA | Read a PDF's table of contents (bookmarks) as a flat list with real page numbers. This is the navigation index for reading: each entry has a 1-based Not every PDF has a usable outline — a scanned book often does, a print-to-PDF rarely does.
When |
| pdf_readA | Read the text of a PDF, page by page, with the page layout reconstructed into paragraphs. Returns 1-based page numbers with their text. Headings are marked with a leading "# " so the structure of the page is visible. Pages are paged: pass from/to to move through the document. This only works on PDFs that carry a text layer. If the PDF is a scan (pdf_info reports scanned: true), there is no text to extract and this tool refuses — render the pages with pdf_render_page and read them as images instead. For a scanned PDF you can still use pdf_outline to learn which page a chapter starts on, then pass that page to pdf_render_page. |
| pdf_render_pageA | Render one page of a PDF as an image and return it for you to look at. This is how you read a scanned PDF, and how you see anything that plain text cannot carry: figures, block diagrams, circuit drawings, tables, equations, page layout, handwriting. The rendered page is returned as an actual image, so you see exactly what is on it. Options:
To read a run of pages, call this once per page. Do not try to read a 400-page book end to end: use pdf_outline to find the relevant section and render only those pages. |
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 7 tools
The four PDF tools (info, outline, read, render_page) and three DOCX tools (read, edit, create) target clearly distinct actions with clear format prefixes. The only overlap is that pdf_info also returns a table of contents while pdf_outline is dedicated to it, which the descriptions partially reconcile but could cause slight hesitation.
A strong, predictable format_action convention is used throughout (pdf_read, pdf_render_page, docx_read, docx_edit, docx_create). Minor deviation: pdf_info and pdf_outline are noun-style rather than verb-style, slightly breaking the verb_noun pattern.
Seven tools is well-scoped for a document-handling server, with each one earning its place (info, outline, read, render for PDF; read, edit, create for DOCX). No redundancy or bloat.
DOCX has full lifecycle coverage (create, read, edit/update) and PDF reading is thorough across text, scanned, and outline modes. Gaps: no PDF creation or PDF editing, though that may be out of scope for the server's apparent read-PDF/write-DOCX focus.