pdf-triage-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PDF_TRIAGE_ROOTS | No | Directories the server may read. Corresponds to the --root option (repeatable). Separate multiple directories with the platform PATH delimiter (`:` on macOS/Linux, `;` on Windows). If not set, defaults to the current working directory. | |
| PDF_TRIAGE_LOG_LEVEL | No | Logging level. Corresponds to --log-level. One of debug|info|warn|error|silent. Default: info. | |
| PDF_TRIAGE_MAX_CHARS | No | Maximum truncation ceiling for extracted text. Corresponds to --max-chars. Default: 40000. Max: 200000. | |
| PDF_TRIAGE_MAX_FILE_BYTES | No | Largest PDF file size in bytes to read. Corresponds to --max-file-bytes. Default: 104857600 (100 MB). |
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 |
|---|---|
| pdf_classifyA | Triage a local PDF without extracting its text (typically 10-50ms). Returns whether the document is text-based, scanned, image-based or mixed, a confidence score, and the exact 1-indexed pages that need OCR. ALWAYS call this before pdf_extract on an unfamiliar or large document: it is cheap, and it tells you whether local extraction is worth attempting at all. If it reports scanned, image_based, or encoding issues, do not extract — route the document to an OCR service instead. |
| pdf_extractA | Extract a local PDF to Markdown, preserving headings, lists and tables. Output is TRUNCATED by default to protect your context window — to read a long document, call repeatedly with the |
| pdf_searchA | Find text inside a local PDF and return matching pages with surrounding context. Much cheaper than pdf_extract when you only need to locate something — use this first on long documents, then pdf_extract with the |
| pdf_tablesA | Return only the tables from a local PDF as Markdown, skipping prose. Useful for invoices, financial statements and reports where the numbers are the point. Tables are detected from the PDF's own drawing operations and text alignment — the cell values are read directly from the document, not guessed by a model or OCR. |
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 4 tools
Each tool addresses a distinct task—classifying the PDF, extracting full text, searching for terms, and extracting tables. There is no overlap; even pdf_extract and pdf_tables differ in scope (full vs. tables only). An agent can confidently choose the right tool based on intent.
All tools share the pdf_ prefix and use a verb or descriptive noun (classify, extract, search, tables). While 'tables' is a noun rather than a verb, the pattern is otherwise consistent and predictable.
With four tools covering classification, extraction, search, and table extraction, the set is well-scoped for a PDF triage server. Each tool has a clear purpose without redundancy.
The toolset covers the full triage workflow: classify to decide if OCR is needed, extract to get full content, search to locate information, and tables for structured data. Missing functionality like OCR itself is deliberately outsourced, so the surface is complete for its intended domain.