Skip to main content
Glama
EthanCheung-gh

PDF Inspector MCP

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PDF_INSPECTOR_MCP_MAX_DOCSNoMaximum 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 (pages, version, encrypted, page_w, page_h, title, author, producer, fonts).

pdf_extract_pageA

Extract every object of one page: characters, words, rectangles, lines, curves, images and tables.

page is 1-based and must be within the document. The result is one PageData object (width, height and one array per object type), suitable for inspecting layout, text runs and detected tables. Very large pages are rejected: use pdf_export with output_path for those.

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 {'metadata', 'pageCount', 'pages'} where pages holds one PageData object per extracted page and pageCount is the number of pages actually returned, not the document's total. Large documents should be read in ranges, or exported with pdf_export.

pdf_analyze_fontsA

Per-font usage statistics: character count, pages, size range and colours.

Omit both bounds to analyse the whole document. Returns {'fonts': [...]} sorted by charCount descending; each entry has fontname, pages, charCount, sizeMin, sizeMax and colors. Use it to find which text is prominent without extracting whole pages.

pdf_get_imageA

Fetch one embedded image's bytes as base64, addressed by the stream_id reported for that image.

Call pdf_extract_page/pdf_extract_document first and take stream_id from an object of type image (p<page>_img_<index>, index is 0-based within the page). On success returns {'base64', 'format', 'mime_type', 'byte_length'} with the full, untruncated payload; images in non-web formats are transcoded to PNG. On failure returns {'error': '...'} unchanged.

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 # <type> section per type. Choose scope='page' with page for one page, or scope='document' with optional first_page/last_page. object_types trims the payload and output_path writes the file to disk; otherwise the content comes back inline unless it exceeds the inline limit, in which case it is written to a file in the OS temp directory and that path is returned instead.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 6 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues