PrecisionPDF-MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PRECISIONPDF_ROOT | Yes | The PDF workspace directory. Confine all PDF and image I/O to this 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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_pdfsA | List PDF files within the configured local workspace (up to 200). |
| read_pdf_pageB | Read selectable text from a 1-based PDF page; includes SHA-256 document fingerprint. |
| propose_highlightA | Find exact normalized words and report their locations WITHOUT modifying any PDF. If passage repeats on the page, specify 1-based occurrence explicitly. |
| apply_highlightA | Apply a proposed exact-match highlight with a checked source fingerprint. New output must not exist. For subsequent updates, the input and output may be the same *-annotated.pdf file when overwrite_annotated_copy is true. Do NOT call without showing the proposal to the user for review. |
| list_annotationsB | Read existing PDF annotations, including stored colors and object references. |
| render_pdf_pageB | Render a PDF page (including annotations) to a local PNG for visual review. |
| propose_annotation_updateA | Preview changing ONE existing highlight's color or opacity; no edits. Obtain page and xref from list_annotations. Review the proposed edit first. |
| apply_annotation_updateA | Change ONE existing highlight after explicit user approval. Requires a fresh fingerprint and an existing *-annotated.pdf copy. Never use shell commands to delete or reconstruct the PDF. |
| propose_annotation_removalB | Preview removal of ONE existing highlight without modifying the PDF. |
| apply_annotation_removalB | Remove ONE existing highlight after explicit user approval. Refuses to edit original PDFs, stale files, and non-highlight annotations. |
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 10 tools
Each tool has a clearly distinct purpose, and the propose_/apply_ pairing cleanly separates preview from committed edits (highlight, update, removal). Read/list/render tools (list_pdfs, read_pdf_page, render_pdf_page, list_annotations) target different resource aspects with no overlap.
All names follow a consistent snake_case verb_noun pattern (list_pdfs, read_pdf_page, propose_highlight, apply_annotation_update, etc.). The propose_*/apply_* convention is applied uniformly across the three annotation operations.
Ten tools is well within the ideal range and each earns its place, covering discovery, reading, rendering, and the full propose/apply lifecycle without redundancy.
The surface covers the full highlight lifecycle (create/update/remove) via paired propose/apply tools, plus listing PDFs, reading text, rendering for review, and listing annotations. No obvious gaps for a local PDF annotation workflow.