Skip to main content
Glama
EthanCheung-gh

PDF Inspector MCP

pdf_export

Export extracted PDF data as JSON or CSV, inline or to a file, for a single page or a document range. Filter object types to trim the payload.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page number; only used when scope='page' (required there). Ignored when scope='document' - use first_page/last_page to bound a range.
pathYesPath to the PDF: absolute, or relative to the server process working directory. Any readable regular file is accepted; the .pdf suffix is not required.
scopeNo'document' (default) exports a page range; 'page' exports the single 'page'.document
formatNoOutput format: 'json' (default) or 'csv'.json
passwordNoPassword for an encrypted PDF. Omit or pass null for unprotected documents.
last_pageNoLast page of a document-scope export (1-based, inclusive). Defaults to the last page.
first_pageNoFirst page of a document-scope export (1-based, inclusive). Defaults to page 1.
output_pathNoFile to write the export to. The parent directory must already exist. Omit to receive the content inline (large results are written to the temp directory instead).
object_typesNoObject types to include: any of char, word, rect, line, curve, image, table. Omit for all types; unknown names are ignored and the output uses the canonical order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does disclose key behavior: the inline size limit silently writes to a temp file and returns the path, and output_path requires an existing parent directory. It omits overwrite semantics for an existing output_path and failure behavior for wrong passwords.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the one-line purpose, then the format semantics, then the scope rule, then trimming and output routing. Slightly verbose with some restatement of scope rules already in the schema, but every sentence conveys usable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no output schema and no annotations, it covers format shapes, scope selection, payload trimming, and the inline/disk fallback. Missing pieces are overwrite behavior and error cases (bad password, missing directory), which leave a modest gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents each parameter and the baseline applies. The description adds conditional coupling (page only meaningful under scope='page') and what the output shapes look like per format, but most per-parameter meaning is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Export extracted PDF data as JSON or CSV') and scopes it against the extract tools ('anything bigger than a single page'). It does not name the specific siblings (pdf_extract_page / pdf_extract_document) it is contrasted with, so the differentiation is suggestive rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear decision rules: scope='page' with page for one page, scope='document' with first_page/last_page for ranges, and a stated volume threshold ('bigger than a single page'). It stops short of naming which extraction sibling to use for the single-page case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.