PDF Inspector MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PDF_INSPECTOR_MCP_MAX_DOCS | No | Maximum number of cached open PDF documents (LRU eviction). Default is 8; invalid values fall back to 8. Set via the MCP client config env block, e.g. {"env": {"PDF_INSPECTOR_MCP_MAX_DOCS": "4"}}. | 8 |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pdf_get_metadataA | Document-level facts: page count, PDF version, encryption flag, first-page size, title/author/producer and the font names the pages reference. Use this first to learn how many pages a document has before calling the page tools.
Returns the extractor's metadata dictionary unchanged ( |
| pdf_extract_pageA | Extract every object of one page: characters, words, rectangles, lines, curves, images and tables.
|
| pdf_extract_documentA | Extract every object of every page in a range: the whole document, or first_page..last_page. Omit both bounds for the whole document. Returns |
| pdf_analyze_fontsA | Per-font usage statistics: character count, pages, size range and colours. Omit both bounds to analyse the whole document. Returns |
| pdf_get_imageA | Fetch one embedded image's bytes as base64, addressed by the stream_id reported for that image. Call The complete base64 payload is always returned inline: this tool is the one deliberate exception to the 1 MB inline limit the other tools enforce, because the image is the whole point of the call. Large images therefore produce a large response. |
| pdf_exportA | Export extracted PDF data as JSON or CSV, either inline or to a file. This is the tool for anything bigger than a single page: JSON keeps the same
shapes as the extract tools (metadata, page count, object types, pages) and CSV
lays out one |
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 6 tools
Each tool targets a distinct concern (metadata, page extraction, document extraction, image bytes, font stats, export), but pdf_extract_document and pdf_export with scope='document' produce largely the same payload, as do pdf_extract_page and pdf_export with scope='page'. The descriptions do explain the split (export is the large-document escape hatch), so an agent can choose, but the boundary is not razor-sharp.
All six tools use a uniform pdf_ prefix plus a verb_noun pattern (get_image, get_metadata, extract_page, extract_document, analyze_fonts, export). Verb choice is predictable and no casing or style drift appears.
Six tools is tightly scoped to the PDF-inspection domain, and each one earns its place: a metadata probe, two extraction granularities, a binary-image fetch, a font analytics shortcut, and an export/overflow path. Nothing feels padded or missing at the count level.
The surface covers the core lifecycle: inspect metadata, extract page or document objects, pull image bytes, analyse fonts, and export to JSON/CSV. Gaps are minor but real — no text search/find, no outline/bookmark or annotation/form-field access, and no page rendering to an image — though agents can approximate search by extracting and filtering.