Skip to main content
Glama
shuji-bonji

@shuji-bonji/pdf-reader-mcp

by shuji-bonji
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

PDF Reader MCP Server

npm version License: MIT Built with Claude Code

English | 日本語

An MCP (Model Context Protocol) server specialized in deciphering PDF internal structures.

While typical PDF MCP servers are thin wrappers for text extraction, this project focuses on reading and analyzing the internal structure of PDF documents. Pair it with pdf-spec-mcp for specification-aware structural analysis and validation.

PDF family

Server

Role

pdf-spec-mcp

PDF specification knowledge (ISO 32000, PDF/A, PDF/UA)

pdf-reader-mcp (this)

Read and inspect PDF internal structure — what is in a PDF

pdf-verify-mcp

Authenticity verification — whether it is genuine: cryptographic signature verification, tamper detection, PAdES level, PDF/A validation, encrypted-PDF decryption

pdf-reader-mcp inspects signature structure (inspect_signatures); for cryptographic signature verification, trust/revocation evaluation, and PDF/A conformance validation, use pdf-verify-mcp.

Features

19 tools organized into three tiers:

Tier 1: Basic Operations

Tool

Description

get_page_count

Lightweight page count retrieval

get_metadata

Full metadata extraction (title, author, PDF version...)

read_text

Text extraction with Y-coordinate reading order (opt-in split_columns: 2 | 3 for untagged multi-column PDFs, compact_whitespace for Japanese forms). Resolves /ActualText replacements (§14.9.4, both the structure-element and the Span marked-content path). Reports text extractability per page (§9.10.1) so an empty result is never mistaken for an empty page. For logical order in tagged PDFs, prefer extract_structured_text

search_text

Full-text search with surrounding context. Searches the same text read_text returns, /ActualText included, so a hit means what a reader sees (a note names any page whose marked content could not be aligned)

read_images

Embedded image XObjects as PNG or JPEG files, returned as MCP image content blocks so a vision model can read them. max_width / max_height downscale by area average; the response has a byte budget and names anything it leaves out

read_url

Fetch a remote PDF and extract its text — nothing more. The bytes are not saved; to use the other 18 tools on a URL's PDF, download it first and pass the local path (see "read_url and the read-only boundary")

render_page

Rasterise pages to PNG/JPEG via PDFium-WASM (optional dependency @hyzyla/pdfium). The next step when text extractability says no_text_layer / not_extractable — draws the whole page, vector art and forms included

summarize

Quick overview report (metadata + text + image count + per-document text extractability)

Tier 2: Structure Inspection

Tool

Description

inspect_structure

Object tree and catalog dictionary analysis

inspect_tags

Tagged PDF structure tree visualization

inspect_fonts

Font inventory (embedded/subset/type detection)

inspect_annotations

Annotation listing (categorized by subtype)

inspect_signatures

Digital signature field structure analysis

extract_structured_text

Tagged PDF text in logical content order (ISO 32000-2 §14.8.2.5), each piece labelled with its structure type (H1 / P / Table …). Resolves /ActualText, separates /Alt and list labels, keeps page-spanning elements whole. include_bbox: true adds where each element is drawn — one rectangle per page, in the form add_annotation takes

extract_tables

Tagged PDF <Table> subtree → Markdown table (preserves columns). A table continuing across a page break is ONE table (pages array)

locate_objects

Object number → page and rectangle, in the coordinate form pdf-writer-mcp add_annotation takes. Bridges pdf-verify-mcp verify_integrity's "which objects changed" to "where they are". Each location names its basis: an annotation's own /Rect is exact, a content stream can only say "the whole page"

Tier 3: Validation & Analysis

Tool

Description

validate_tagged

Deprecated — PDF/UA pass/fail belongs to pdf-verify-mcp validate_conformance (flavour: "pdfua-1"). Kept until the next major

validate_metadata

Deprecated — same migration path as above. Kept until the next major

compare_structure

Structural diff between two PDFs (properties + fonts)

read_url and the read-only boundary (#25)

read_url returns text, and only text. This is a decision, now stated rather than implied: the fetched bytes are discarded after extraction, because saving them would make a reader tool write to the file system, and every tool of this server is read-only (readOnlyHint: true — all 19 of them).

To run search_text, inspect_structure, extract_tables, render_page or anything else against a PDF that lives at a URL, download the file first — with whatever fetch capability the calling environment has — and pass the local path. Fetching is the caller's responsibility, deliberately: an agent environment always has a way to download a file, and a reader that also writes files has stopped being a pure observer.

read_url remains the right tool for the one-shot question: what does the document at this URL say?

Pages can be rendered when text cannot be read (#23)

summarize reporting hasText: false used to be a dead end: nothing in this server could read the document any further. render_page closes that — it rasterises pages to PNG or JPEG and returns them as MCP image content blocks, so a vision model can read a scan, a diagram, a filled form, or handwriting.

render_page({ file_path: "/path/to/scan.pdf", pages: "1-3", format: "jpeg" })

pages is required: rendering is the most expensive operation here, and "all pages" of a 500-page scan should be a decision, not a default. The same 4 MB response budget as read_images applies, with omissions named.

Rendering runs on PDFium compiled to WebAssembly (@hyzyla/pdfium, an optional dependency). A WASM binary is the same bytes on every platform, so the published package still behaves identically wherever npx runs it — the reason native addons are not used here. Without the dependency installed, render_page reports what to install and every other tool works normally. PDFium (BSD-3-Clause) is a different engine from the pdf.js this server reads text with; the tool description says so, because a rendering difference between engines must not be attributed to the file.

Measured before choosing this: pdf.js + @napi-rs/canvas (1.0.7 and 0.1.80) segfaults the whole process on pages that draw images — exactly the pages this tool exists for — and renders blank pages when standardFontDataUrl is not configured.

Images come back as image files (#22)

read_images used to base64 imgData.data — pdfjs's decoded pixels. An 8×8 RGB image was 192 bytes with no PNG or JPEG signature anywhere in it, so the result could not be opened by any viewer and could not be read by a vision model, which is the reason to extract an image in the first place.

Images are now encoded (PNG by default, lossless; format: "jpeg" with quality when smaller matters) and returned as MCP image content blocks, with the metadata alongside in a text block. Both encoders are written out here — no native addon, no per-platform binary.

The response is bounded at 4 MB of encoded image data. A 200 dpi A4 scan is ~11.6 MB of pixels on its own, so images past the budget are named with the reason rather than dropped:

read_images({ file_path: "/path/to/scan.pdf", pages: "1", max_width: 1200, format: "jpeg" })

read_images returns the image XObjects a page draws. It is not a picture of the page — vector drawings and text are not covered by it.

Text extractability — three states, not two (#21)

read_text used to answer with text or with nothing, and nothing meant three different things. ISO 32000-2 §9.10.1 separates them, so this server does too. Every text-returning tool — read_text, read_url, search_text, extract_structured_text, summarize — reports, per page:

State

Condition

What to do next

extracted

Every font used has a route to Unicode under §9.10.2

Use the text

no_text_layer

No text-showing operator (Tj TJ ' "), image content present

The page is pixels. OCR or a rendered image is needed; this server does neither

not_extractable

A font used has no /ToUnicode, no standard encoding and no known CID collection

Text is missing or wrong. The report names the fonts and the clause

not_observed

Encrypted, or the content stream could not be read

Nothing was measured. Not the same as "nothing is there"

not_extractable is reported per font, so a page that mixes a readable font with an unreadable one is a partial loss and says so, rather than passing as complete.

The observation is made from the file, not from pdf.js's output: pdf.js synthesises a toUnicode map for every font it loads, so asking it whether a font has a /ToUnicode CMap answers yes for fonts whose dictionary has none.

Related MCP server: PDF Reader MCP Server

Installation

npx (recommended)

npx @shuji-bonji/pdf-reader-mcp@latest

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "pdf-reader-mcp": {
      "command": "npx",
      "args": ["-y", "@shuji-bonji/pdf-reader-mcp@latest"]
    }
  }
}

Use @latest. The -y flag in npx -y <pkg> only skips the install prompt — it does not check for updates. Without @latest, npx keeps running whichever version it cached the first time, so new releases never reach you. If you suspect you are on a stale version, run rm -rf ~/.npm/_npx and restart your client.

Claude Code

claude mcp add pdf-reader-mcp -- npx -y @shuji-bonji/pdf-reader-mcp@latest

From Source

git clone https://github.com/shuji-bonji/pdf-reader-mcp.git
cd pdf-reader-mcp
npm install
npm run build

Usage Examples

Get Page Count

get_page_count({ file_path: "/path/to/document.pdf" })
→ 42

Search Text

search_text({
  file_path: "/path/to/spec.pdf",
  query: "digital signature",
  pages: "1-20",
  max_results: 10
})
→ Found 5 matches (page 3, 7, 12, 15, 18)

Summarize

summarize({ file_path: "/path/to/document.pdf" })
→ | Pages | 42 |
  | PDF Version | 2.0 |
  | Tagged | Yes |
  | Signatures | No |
  | Images | 15 |

Validate Tagged Structure (PDF/UA)

validate_tagged({ file_path: "/path/to/document.pdf" })
→ ✅ [TAG-001] Document is marked as tagged
  ✅ [TAG-002] Structure tree root exists
  ⚠️ [TAG-004] Heading hierarchy has gaps: H1, H3
  ❌ [TAG-005] Document has 3 image(s) but no Figure tags

Validate Metadata

validate_metadata({ file_path: "/path/to/document.pdf" })
→ ✅ [META-001] Title: "Annual Report 2025"
  ⚠️ [META-002] Author is missing
  ✅ [META-006] PDF version: 2.0

Compare Structure

compare_structure({
  file_path_1: "/path/to/v1.pdf",
  file_path_2: "/path/to/v2.pdf"
})
→ | Page Count  | 10 | 12 | ❌ |
  | PDF Version | 1.7 | 2.0 | ❌ |
  | Tagged      | true | true | ✅ |

Extract Structured Text (Tagged PDF, logical order)

extract_structured_text({ file_path: "/path/to/report.pdf", pages: "1-2" })
→ # Structured Text
  - **Tagged**: Yes / **Language**: en-US / **Elements**: 7

  ## Logical Content Order

  - **Document** (pages 1–2)
    - **H1** (page 1) — Quarterly Report
    - **P** (pages 1–2) — This paragraph begins on page one and continues on page two.
    - **Table** (page 1)
      | Item | Amount |
      |---|---|
      | Sales | 100 |
    - **Figure** (page 2) — *alt:* A bar chart of sales

This answers "what is the text of the H1?" — which read_text (flat, coordinate order) cannot. Order is a depth-first traversal of the structure tree (ISO 32000-2 §14.8.2.5). /ActualText replaces the glyphs (§14.9.4), /Alt stays out of the body text (§14.9.3), list labels are reported separately, and an element spanning a page break stays ONE element. Use roles: ["H1", "H2"] to pull an outline. Untagged PDFs return isTagged: false with a reason — nothing is guessed from coordinates.

include_bbox: where the element is drawn

extract_structured_text({ file_path: "/doc.pdf", roles: ["P"], include_bbox: true })
→ - **P** (page 1) — Measured paragraph
    - *bbox* p1 `(50.0, 297.5, 161.4, 308.6)` — text-extent
  - **Figure** (page 1)
    - *bbox* p1 `(50.0, 150.0, 110.0, 190.0)` — layout-attribute-bbox

Rectangles are in PDF default user space (origin bottom-left, pt, normalised) — exactly what pdf-writer-mcp add_annotation takes, so "annotate this paragraph" needs no coordinate conversion in between. /Rotate and a shifted /CropBox do not move them.

basis says how strong the claim is, and the two are different in kind:

basis

What it is

layout-attribute-bbox

The /BBox the file declares (ISO 32000-2 Table 379), read through /A or /C + /ClassMap. A statement by the producer, reported as-is — and the only source for content that has no text

text-extent

Measured from the element's text: baseline origin plus the font's ascent/descent. The line box, not the glyph outlines. Images and vector art contribute nothing

An element spanning pages gets ONE RECTANGLE PER PAGE — merging them would put content on a page it is not on. An element with no rectangle says why in boxNote rather than returning a zero-sized one.

A declaration is reported as-is, and cross-checked. Files state nonsense: the cover Figure of both Well-Tagged PDF 1.0 and the Tagged PDF Best Practice Guide declares /BBox [-32768 -32768 32767 32767] — int16 sentinels where a rectangle should be — and PDF32000_2008 has 131 of its 545 declarations reaching past the page edge. Since this output is meant to go straight into add_annotation, a declaration is checked against the page box (§7.7.3.3) and against the element's own text; either contradiction is reported in boxNote, with the rectangle still returned unaltered.

Measured against independent ground truth: on Well-Tagged PDF (WTPDF) 1.0, the 166 Link structure elements were compared with the 173 Link annotation /Rect values the producer placed for the same links — median IoU 0.972, none disjoint.

Extract Tables (Tagged PDF)

extract_tables({ file_path: "/path/to/kaisei-tsutatsu.pdf", pages: "1" })
→ # Extracted Tables
  - **Tagged**: Yes / **Pages Scanned**: 1 / **Tables Found**: 1

  ## Table 1 — Page 1

  | 改正後 | 改正前 |
  | --- | --- |
  | …第２条第 16 項《定義》… | …第２条第 15 項《定義》… |

A table that continues across a page break is reported as ONE table — pages is an array (e.g. ## Table 3 — Pages 5–7), and a table touching the requested pages range is returned whole. Cell text honours /ActualText replacements (as do read_text and search_text since #18). Untagged PDFs return an empty result with a note recommending the column-aware fallback below.

Read Untagged Multi-Column PDF

read_text({ file_path: "/path/to/older-shinkyu.pdf", split_columns: 2 })
→ // Plain Y-sort would interleave columns:
//   "改正後セル1   改正前セル1\n 改正後セル2   改正前セル2..."
//
// With split_columns: 2 the left column is emitted first, then the right:
//   "改正後セル1\n改正後セル2\n…\n\n改正前セル1\n改正前セル2\n…"

Use split_columns: 2 | 3 for untagged multi-column PDFs. For Tagged PDFs with proper <Table> markup, extract_tables (above) is preferred.

Compact Whitespace (Japanese Forms)

read_text({ file_path: "/path/to/form.pdf", compact_whitespace: true })
→ // Original PDF uses U+3000 fullwidth space as visual indentation:
//   " (   )   自   年   月   日   法   有 （   年   月   日）   有   有"
//
// With compact_whitespace: true:
//   "( ) 自 年 月 日 法 有 （ 年 月 日） 有 有"
//
// Empirically reduces character count by ~40% on form PDFs.

compact_whitespace is orthogonal to split_columns — both can be combined.

Tech Stack

  • TypeScript + MCP TypeScript SDK

  • pdfjs-dist (Mozilla) — text/image extraction, tag tree, annotations

  • normativepdf + @normativepdf/recover — COS object access, read from files whose cross-reference table does not follow ISO 32000-2 §7.5

  • Vitest — unit + E2E testing (483 tests)

  • Biome — linting + formatting

  • Zod — input validation

Testing

npm test              # Run all tests (unit + E2E: 483 tests)
npm run test:e2e      # E2E tests only (283 tests)
npm run test:watch    # Watch mode

Architecture

pdf-reader-mcp/
├── src/
│   ├── index.ts              # MCP Server entry point
│   ├── constants.ts          # Shared constants
│   ├── types.ts              # Type definitions
│   ├── tools/
│   │   ├── tier1/            # Basic tools (7)
│   │   ├── tier2/            # Structure inspection (6)
│   │   ├── tier3/            # Validation & analysis (3)
│   │   └── index.ts          # Tool registration
│   ├── services/
│   │   ├── pdfjs-service.ts        # pdfjs-dist wrapper (parallel page processing)
│   │   ├── recover-service.ts      # @normativepdf/recover — opening a document,
│   │   │                           #   and how far it could be read (DocumentScope)
│   │   ├── structure-service.ts    # Catalog, page tree, object statistics
│   │   ├── font-service.ts         # Fonts named in each page's /Resources
│   │   ├── signature-service.ts    # Signature fields of the AcroForm (structure only)
│   │   ├── content-stream-service.ts  # Marked-content operators, text-showing tally
│   │   ├── struct-tree-service.ts  # Logical structure (tags, structured text)
│   │   ├── validation-service.ts   # Validation & comparison logic
│   │   └── url-fetcher.ts          # URL fetching
│   ├── schemas/              # Zod validation schemas
│   └── utils/
│       ├── pdf-helpers.ts    # PDF utilities (page range parsing, file I/O)
│       ├── batch-processor.ts # Batch processing for large PDFs
│       ├── formatter.ts      # Output formatting
│       └── error-handler.ts  # Error handling
└── tests/
    ├── tier1/                # Unit tests
    └── e2e/                  # E2E tests (16 suites, 283 tests)

Error Contract (houki-hub family)

Since v0.6.0, this MCP returns structured errors that follow the houki-hub family error contract, sharing a unified code vocabulary across the family. Combined with houki-egov-mcp / houki-nta-mcp, an LLM or Skill layer can interpret errors with consistent logic.

Implementation is independent — no dependency on houki-abbreviations or other family packages. The reference implementation is houki-egov-mcp/src/errors.ts; pdf-reader-mcp's local definition is in src/errors.ts.

On error, every tool returns isError: true and the JSON-stringified LawServiceError in content[0].text:

{
  "error": "The file does not appear to be a valid PDF.",
  "code": "INVALID_PDF",
  "hint": "ファイルが破損していないか確認してください。",
  "next_actions": [
    {
      "action": "inspect_structure",
      "reason": "PDF が壊れている可能性があります。Catalog / Pages 等の構造を確認してください"
    }
  ],
  "detail": { "cause": "Invalid PDF structure" }
}

Codes used by pdf-reader-mcp

code

用途

INVALID_ARGUMENT

パス・URL・ページ範囲などクライアント側引数の不正

DOC_NOT_FOUND

ファイル未存在 (ENOENT)

INVALID_PDF

PDF として不正・破損

ENCRYPTED_PDF

暗号化 PDF (現状未対応)

UNSUPPORTED_PDF_FEATURE

サポート外の PDF 機能

FILE_TOO_LARGE

50MB 上限超過 (pdf-reader 固有)

SOURCE_API_ERROR

URL fetch の HTTP エラー (4xx/5xx)

SOURCE_TIMEOUT

リモート取得タイムアウト

SOURCE_UNAVAILABLE

DNS / 接続失敗

INTERNAL_ERROR

パーミッション拒否を含むその他バグ

Migration note (v0.5.x → v0.6.0)

旧 v0.5.x までは content[0].text に Error: ...\n\nSuggestion: ... という人間可読文字列を入れていました。v0.6.0 では同じ場所に JSON 文字列 が入ります。LLM 側でテキスト解釈に依存していた場合は、JSON.parse(content[0].text) での解釈に切り替えてください。isError: true フラグで構造化エラーかどうかを判定できます。

Pairing with pdf-spec-mcp

pdf-spec-mcp provides PDF specification knowledge (ISO 32000-2, etc.). With both servers enabled, an LLM can perform specification-aware workflows:

  1. summarize — get a PDF overview

  2. inspect_tags — examine the tag structure

  3. pdf-spec-mcp get_requirements — fetch PDF/UA requirements

  4. validate_tagged — check conformance

  5. compare_structure — diff before/after fixes

License

MIT

Available Tools

16 tools
compare_structureCompare PDF StructuresA
Read-onlyIdempotent

Compare the internal structures of two PDF documents and identify differences.

Args:

  • file_path_1 (string): Absolute path to the first PDF file

  • file_path_2 (string): Absolute path to the second PDF file

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Structural comparison including: property-by-property diff (page count, PDF version, encryption, tagged status, object counts, page dimensions, file size, catalog entries, signatures), font comparison (fonts unique to each file and shared fonts), and a summary.

Examples:

  • Compare two versions of the same document

  • Verify structural consistency across PDF exports

  • Identify differences in PDF generation pipelines

ParametersJSON Schema
NameRequiredDescriptionDefault
file_path_1YesAbsolute path to the first PDF file for comparison
file_path_2YesAbsolute path to the second PDF file for comparison
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already mark the tool as read-only and idempotent. The description adds value by specifying the return content (property-by-property diff, font comparison, summary) and that it reads two files. No contradictions.

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

Conciseness5/5

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

Description is well-organized with a brief intro, args list, returns list, and examples. Every sentence is necessary, no fluff.

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

Completeness5/5

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

Despite no output schema, the description thoroughly explains what is returned (structural comparison details). All 3 parameters (2 required) are described, and examples provide practical context.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds examples and return format details beyond the schema, such as the default for response_format and the structure of the comparison output.

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

Purpose5/5

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

The description clearly states it compares internal structures of two PDF documents and identifies differences, listing specific aspects like property-by-property diff and font comparison. This distinguishes it from sibling tools like inspect_structure which likely handle single documents.

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?

Examples provided (e.g., comparing two versions of the same document, verifying structural consistency) give clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, though the sibling list implies other tools for different tasks.

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

extract_tablesExtract Tables (Tagged PDF)A
Read-onlyIdempotent

Extract every <Table> subtree from a Tagged PDF as a structured row/cell list, optionally rendered as Markdown tables.

How it works: walks the StructTree and pulls cell text for each <TR> → <TH>/<TD>, then collapses kerning whitespace (e.g. "消 費 税 法" → "消費税法"). This sidesteps reading-order extraction's failure mode on multi-column tables (typical of 新旧対照表 PDFs).

Args:

  • file_path (string): Absolute path to a local PDF file

  • pages (string, optional): Page range. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Markdown — # Extracted Tables summary block followed by one ## Page N — Table M section per table with a GFM table.

JSON — { isTagged, tables: [{ page, index, headerRows, bodyRows, footerRows }], totalTables, pagesScanned, note? }.

Limitations:

  • Untagged PDFs return an empty result and a note.

  • colspan/rowspan are not honoured (cells are listed in source order).

  • Nested tables are skipped to keep page indices stable.

Examples:

  • Pull 新旧対照表 from a kaisei tsutatsu PDF for diffing

  • Convert 帳票 (form template) tables into structured data

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
pagesNoPage range to process. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses key behavioral traits: how it walks the StructTree, collapses kerning whitespace, and handles unsupported features (colspan, nested tables). These details go beyond the annotations (readOnlyHint, idempotentHint), which already indicate safe, non-destructive usage, providing agents with full context.

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

Conciseness5/5

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

The description is well-structured with clear sections: main purpose, how it works, args, returns, limitations, examples. Every sentence adds value, and the most critical information (what the tool does) is front-loaded, making it easy for an agent to quickly understand and act.

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

Completeness5/5

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

Given the complexity of table extraction from tagged PDFs, the description covers all necessary aspects: purpose, mechanics, parameter details, return formats (including examples), and limitations. No output schema is provided, but the description compensates by detailing the JSON structure. The examples further clarify use cases.

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

Parameters4/5

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

The input schema covers all three parameters with descriptions (100% coverage). The description adds value by explaining the page range format, enum options for response_format, and return structure details, going beyond the schema to clarify usage.

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

Purpose5/5

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

The description clearly states the tool extracts `<Table>` subtrees from tagged PDFs and provides structured output. It distinguishes itself from sibling tools like `read_text` by explicitly mentioning it handles multi-column tables where reading-order extraction fails, making its purpose highly specific.

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?

The description explains when to use (tagged PDFs with tables, especially multi-column) and notes limitations (untagged PDFs return empty, no colspan/rowspan support, nested tables skipped). It implies an alternative for non-table text extraction but does not explicitly name sibling tools for comparison, leaving room for slight ambiguity.

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

get_metadataGet PDF MetadataA
Read-onlyIdempotent

Extract metadata from a PDF document including title, author, creation date, page count, PDF version, and structural information.

Args:

  • file_path (string): Absolute path to a local PDF file

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Metadata including: title, author, subject, keywords, creator, producer, creation/modification dates, page count, PDF version, linearized/encrypted/tagged/signature flags, file size.

Examples:

  • Get document properties for cataloging

  • Check if a PDF is tagged (accessibility)

  • Verify PDF version compatibility

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by listing exact return fields and confirming the read-only nature, with no contradictions.

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

Conciseness5/5

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

Description is well-structured with Args, Returns, Examples. Front-loaded with purpose, every sentence is useful, no fluff.

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?

No output schema, but description lists return fields comprehensively. Covers input, output, examples. Could briefly differentiate from sibling tools like validate_metadata, but overall very complete.

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 baseline is 3. Description repeats parameter descriptions but adds context like 'local PDF file' and default format, along with examples. Minimal additional meaning beyond schema.

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

Purpose5/5

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

The description clearly states 'Extract metadata from a PDF document' and lists specific fields like title, author, page count, etc. It distinguishes from sibling tools like validate_metadata and inspect_structure by focusing on general metadata extraction.

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

Usage Guidelines3/5

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

Description provides examples of when to use (e.g., cataloging, checking tagged, verifying version) but does not explicitly state when not to use or mention alternatives among the many sibling tools.

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

get_page_countGet PDF Page CountA
Read-onlyIdempotent

Get the total number of pages in a PDF document.

This is a lightweight operation that only reads the PDF header, not the full content.

Args:

  • file_path (string): Absolute path to a local PDF file

Returns: Page count as a number.

Examples:

  • Quick check before deciding which pages to extract

  • Validate a PDF file is readable

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint true and idempotentHint true. Description adds that it 'only reads the PDF header, not the full content', which discloses the lightweight nature beyond annotations.

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

Conciseness5/5

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

Description is concise, well-structured with Args, Returns, Examples sections. Front-loaded with purpose, no wasted sentences.

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

Completeness5/5

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

For a simple read-only tool with one parameter and comprehensive annotations, the description covers purpose, usage, return type, and examples. No gaps identified.

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 has 100% coverage with description for file_path. Description adds 'Absolute path' and example format but does not significantly add beyond the schema. Baseline 3 applies.

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

Purpose5/5

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

Clearly states 'Get the total number of pages in a PDF document', which is a specific verb+resource. Differentiates from sibling tools like extract_tables or read_text.

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?

Provides examples of when to use (quick check, validation), implying lightweight operation. Does not explicitly mention when not to use, but context is clear.

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

inspect_annotationsInspect PDF AnnotationsA
Read-onlyIdempotent

Extract and categorize all annotations in a PDF document.

Args:

  • file_path (string): Absolute path to a local PDF file

  • pages (string, optional): Page range. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Total annotation count, breakdown by subtype (Link, Widget, Highlight, Text, etc.) and by page, flags for links/forms/markup presence, and individual annotation details.

Examples:

  • Check for form fields (Widget annotations)

  • Find all links in a document

  • Inventory markup annotations (highlights, comments)

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
pagesNoPage range to process. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds details on return structure (count, breakdown, flags, details) without contradiction.

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?

Well-structured with clear sections (Args, Returns, Examples) but somewhat verbose; could be trimmed slightly while retaining all necessary information.

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

Completeness5/5

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

Given the lack of output schema, the description thoroughly explains the return value (count, breakdown, flags, details) and provides concrete examples covering key use cases.

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

Parameters4/5

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

Parameters are fully described in the schema (100% coverage). The description repeats format but adds useful context via concrete examples, especially for pages and response_format.

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

Purpose5/5

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

Clearly states 'Extract and categorize all annotations in a PDF document.' Verb and resource are specific, and the tool is well-differentiated from siblings like inspect_fonts or inspect_structure.

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?

Provides examples of use cases (check form fields, find links, inventory markup annotations) but does not explicitly state when to use this tool over alternatives or when not to use it.

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

inspect_fontsInspect PDF FontsA
Read-onlyIdempotent

List all fonts used in a PDF document with their properties.

Args:

  • file_path (string): Absolute path to a local PDF file

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Font name, type (TrueType, Type1, CIDFont, etc.), encoding, embedded/subset status, and pages where each font is used.

Examples:

  • Check if all fonts are embedded (required for PDF/A, PDF/X)

  • Identify font types and encodings

  • Find which pages use specific fonts

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4.1/5.0
Behavior4/5

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

Annotations indicate read-only, non-destructive, idempotent behavior. Description adds value by detailing what properties are returned (name, type, encoding, embedded/subset status, pages), which is beyond annotation scope. No contradiction.

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?

Well-structured with summary, Args, Returns, Examples. Front-loaded with clear purpose. Each section is concise and informative, though the examples could be slightly tighter.

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?

Given no output schema, description adequately covers return data. Context of multiple siblings is addressed by specific use-case examples. Sufficient for an agent to understand tool purpose and output.

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 baseline 3. Description largely repeats schema for file_path and response_format, but the Returns section explains the output structure, adding some semantic value beyond schema.

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

Purpose5/5

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

The description clearly states the tool lists all fonts in a PDF with properties. It provides specific verb ('List') and resource ('fonts used in a PDF document'), and distinguishes from sibling tools (e.g., extract_tables, read_text) by targeting a unique aspect of PDF content.

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?

Examples explicitly state when to use: checking font embedding for PDF/A/X compliance, identifying font types/encodings, finding pages using specific fonts. While no explicit exclusions or alternatives are given, the examples give clear context for typical use cases relative to siblings.

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

inspect_signaturesInspect PDF Digital SignaturesA
Read-onlyIdempotent

Examine digital signature fields in a PDF document.

Args:

  • file_path (string): Absolute path to a local PDF file

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Total signature field count, signed/unsigned breakdown, and details for each field (signer name, reason, location, signing time, filter/subFilter).

Note: This tool inspects signature field structure only. Cryptographic signature verification is not performed.

Examples:

  • Check if a PDF has been digitally signed

  • Inspect signer information and signing dates

  • Verify signature field structure

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, which the description complements by explicitly stating it only inspects structure and does not perform verification. There is no contradiction, and the description adds important behavioral context (no cryptographic verification) beyond what annotations provide.

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

Conciseness5/5

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

The description is concise and well-structured: a single sentence for purpose, followed by Args, Returns, Note, and Examples sections. Every sentence adds necessary information without redundancy, and the most critical information ('Examine digital signature fields') is front-loaded.

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

Completeness5/5

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

For a simple tool with two parameters and no output schema, the description covers all necessary aspects: purpose, input requirements, output details (including example fields), and limitations. The examples provide concrete usage scenarios, making it contextually complete for agent invocation.

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

Parameters4/5

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

Input schema covers both parameters with descriptions, but the tool description adds value by explaining the file_path as 'absolute path to a local PDF file' and response_format with default and examples. The 'Returns' section and examples further clarify parameter usage, compensating for the schema's 100% coverage baseline.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Examine digital signature fields in a PDF document.' It specifies the output (total count, signed/unsigned breakdown, details per field) and distinguishes it from sibling tools like validate_tagged by focusing on structure only. The verb 'examine' and resource 'digital signature fields' are specific and unambiguous.

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?

The description provides explicit contexts for use ('Check if a PDF has been digitally signed', 'Inspect signer information and signing dates') and a clear limitation ('Cryptographic signature verification is not performed'). It implicitly suggests when not to use (if verification is needed) but does not name alternative tools for that purpose.

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

inspect_structureInspect PDF StructureA
Read-onlyIdempotent

Examine PDF internal object structure including catalog entries, page tree, and object statistics.

Args:

  • file_path (string): Absolute path to a local PDF file

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Catalog entries (keys and types), page tree info (page count, MediaBox samples), object statistics (total count, stream count, type distribution), and encryption status.

Examples:

  • Examine document catalog for structural features

  • Count PDF objects and streams

  • Check page dimensions across the document

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4.1/5.0
Behavior4/5

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

Annotations (readOnlyHint, destructiveHint, idempotentHint) indicate safe, idempotent behavior. The description adds specifics about returned data (catalog entries, object statistics, encryption status) and parameters, providing value beyond annotations without contradiction.

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

Conciseness5/5

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

The description is well-organized into Args, Returns, and Examples sections, concise without extraneous text. Front-loaded purpose sentence efficiently conveys the tool's function.

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

Completeness5/5

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

Given rich annotations and full schema coverage, the description explains return values clearly (catalog entries, page tree, object stats, encryption). No output schema exists, so the description adequately fills that gap for the tool's moderate complexity.

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?

Input schema has 100% description coverage, already detailing both parameters (file_path, response_format) with defaults and examples. The description reiterates this information with minor elaboration (e.g., example paths), but adds little new meaning.

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

Purpose5/5

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

The description clearly states the tool examines PDF internal object structure, listing specific outputs like catalog entries, page tree, and object statistics. It distinguishes itself from more specialized siblings (e.g., inspect_fonts, inspect_annotations) by offering a broad structural overview.

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

Usage Guidelines3/5

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

The description implies use for general structure inspection but does not explicitly indicate when to choose this tool over siblings like compare_structure or get_page_count. No exclusions or alternatives are mentioned, leaving the agent to infer context.

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

inspect_tagsInspect Tagged PDF StructureA
Read-onlyIdempotent

Analyze the Tagged PDF structure tree for accessibility assessment.

Args:

  • file_path (string): Absolute path to a local PDF file

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Whether the PDF is tagged, the structure tree hierarchy with roles, max nesting depth, total element count, and role distribution (e.g., Document, P, H1, Table, Figure).

Examples:

  • Check if a PDF is tagged for accessibility (PDF/UA)

  • Inspect the tag hierarchy and role distribution

  • Assess document structure quality

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral details such as the return of specific elements (document roles, nesting depth, element count) and output format options, which are not covered by annotations.

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?

The description is well-structured with a purpose sentence, Args/Returns/Examples sections. It is front-loaded with the key action. A minor point: the Returns section could be more concise, but overall it is efficient.

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

Completeness5/5

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

Given the simplicity of the tool (2 params, no output schema, rich annotations), the description covers all needed aspects: purpose, parameters, return values, and usage examples. It is complete for an AI agent to select and invoke correctly.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the return components (e.g., role distribution) and providing examples, which enriches the parameter semantics beyond the schema.

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

Purpose5/5

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

The description clearly identifies the tool's purpose: analyzing the Tagged PDF structure tree for accessibility assessment. It lists specific output components (tagged status, hierarchy, roles, depth, element count, role distribution) and distinguishes it from siblings like validate_tagged and inspect_structure by focusing on the tagged structure tree.

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?

The description provides example use cases (check if tagged, inspect hierarchy, assess structure quality) which implicitly guide usage. However, it does not explicitly compare to sibling tools like inspect_structure or state when not to use this tool, leaving some ambiguity.

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

read_imagesRead PDF ImagesA
Read-onlyIdempotent

Extract images from a PDF document as base64-encoded data.

Extracts embedded images from specified or all pages. Returns image metadata (dimensions, color space) along with raw pixel data in base64.

Args:

  • file_path (string): Absolute path to a local PDF file

  • pages (string, optional): Page range. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.

Returns: Array of extracted images with: page number, index, width, height, color space (RGB/RGBA/Grayscale), bits per component, and base64-encoded data.

Note: Large images may produce very large responses. Use the pages parameter to limit scope.

Examples:

  • Extract all images: { file_path: "/path/to/doc.pdf" }

  • Extract from page 1: { file_path: "/path/to/doc.pdf", pages: "1" }

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
pagesNoPage range to process. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral details like returning metadata and base64 data, and warns about large responses, which goes beyond the annotations.

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

Conciseness5/5

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

The description is well-structured with a brief intro, Args, Returns, Note, and Examples sections. It is front-loaded with the main purpose and every sentence adds necessary information without redundancy.

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

Completeness5/5

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

Even without an output schema, the description explains the return structure in detail (page number, index, dimensions, color space, bits per component, base64 data). Combined with thorough annotations, the description is complete for a read-only extraction tool.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds value by specifying the format for the pages parameter and providing examples, which justifies a score above the baseline of 3.

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

Purpose5/5

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

The description clearly states 'Extract images from a PDF document as base64-encoded data,' which is a specific verb+resource combination. It distinguishes from sibling tools like read_text or extract_tables by focusing on images.

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?

The description provides examples and notes on using the pages parameter to limit scope, and mentions that large images may produce large responses. It does not explicitly state when not to use this tool, but the context is clear.

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

read_textRead PDF TextA
Read-onlyIdempotent

Extract text content from a PDF document with Y-coordinate-based reading order preservation.

Text is extracted page by page, sorted by vertical position (top to bottom) then horizontal position (left to right), providing natural reading order.

For untagged multi-column PDFs (e.g. older 新旧対照表 PDFs that lack a structure tree), pass split_columns: 2 or 3 to bucket items by X-coordinate left-to-right. Tagged PDFs with proper <Table> markup should use the extract_tables tool instead.

For Japanese form-style PDFs (帳票・様式) where U+3000 fullwidth spaces are used as visual indentation, pass compact_whitespace: true to collapse runs of whitespace to a single ASCII space. Cuts 20–40% of token consumption without losing content.

Args:

  • file_path (string): Absolute path to a local PDF file

  • pages (string, optional): Page range to extract. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

  • split_columns (1 | 2 | 3, optional): Column-aware reordering for untagged multi-column PDFs. Default 1 = existing Y-sort.

  • compact_whitespace (boolean, optional): Collapse whitespace runs (incl. U+3000) to one ASCII space and trim each line. Default false.

Returns: Extracted text organized by page number. With split_columns >= 2, columns are separated by a blank line so a downstream LLM can tell them apart.

Examples:

  • Extract all text: { file_path: "/path/to/doc.pdf" }

  • Untagged 新旧対照表: { file_path: "/path/to/older-shinkyu.pdf", split_columns: 2 }

  • Japanese form template: { file_path: "/path/to/form.pdf", compact_whitespace: true }

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
pagesNoPage range to process. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown
split_columnsNoNumber of columns to use when reordering text. 1 (default) = existing Y-sort. 2 or 3 = bucket by X-coordinate left-to-right. Use for untagged 新旧対照表 / two-column PDFs where Y-sort would interleave columns. Tagged PDFs with proper <Table> markup should use extract_tables instead.
compact_whitespaceNoWhen true, collapse runs of whitespace (incl. fullwidth space U+3000) to a single ASCII space and trim each line. Reduces token consumption on Japanese form-style PDFs. Default: false (no whitespace normalization).

TDQS

A5/5.0
Behavior5/5

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

Annotations already indicate readOnly, non-destructive, idempotent behavior. The description adds reading order details, page-by-page extraction, and column separation behavior, providing full transparency beyond annotations.

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

Conciseness5/5

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

The description is well-structured with clear sections, bullet points, and examples. Every sentence adds value, making it informative without unnecessary repetition.

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

Completeness5/5

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

Despite lacking an output schema, the description explains return format (organized by page, column separation). All parameters are fully documented, and the tool's functionality is comprehensively covered.

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

Parameters5/5

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

Schema coverage is 100%, and the description expands on each parameter with use cases, formats, and effects (e.g., compact_whitespace reduces tokens). Examples clarify complex parameters like split_columns.

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

Purpose5/5

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

The description clearly states 'Extract text content from a PDF document' with specific reading order preservation. It differentiates from sibling tools like extract_tables (for tagged PDFs) and others, making the tool's unique role evident.

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

Usage Guidelines5/5

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

The description provides explicit guidance: when to use split_columns (untagged multi-column PDFs) and compact_whitespace (Japanese form PDFs). It also directs users to extract_tables for tagged PDFs, offering clear alternatives.

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

read_urlRead PDF from URLA
Read-only

Fetch a PDF from a URL and extract its text content.

Downloads the PDF from the specified URL, then extracts text with Y-coordinate-based reading order. Supports HTTP and HTTPS. Maximum file size: 50MB. Timeout: 30 seconds.

Like read_text, accepts split_columns: 2 | 3 for untagged multi-column PDFs and compact_whitespace: true to collapse U+3000 / ASCII whitespace runs. Tagged PDFs should use extract_tables instead.

Args:

  • url (string): URL pointing to a PDF file (HTTP or HTTPS)

  • pages (string, optional): Page range to extract. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

  • split_columns (1 | 2 | 3, optional): Column-aware reordering. Default 1 = existing Y-sort.

  • compact_whitespace (boolean, optional): Collapse whitespace runs (incl. U+3000) to one ASCII space. Default false.

Returns: Extracted text organized by page number, same format as read_text.

Examples:

  • Read remote PDF: { url: "https://example.com/document.pdf" }

  • Untagged 2-column PDF: { url: "https://...", split_columns: 2 }

  • Japanese form: { url: "https://...", compact_whitespace: true }

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL pointing to a PDF file (HTTP or HTTPS)
pagesNoPage range to process. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown
split_columnsNoNumber of columns to use when reordering text. 1 (default) = existing Y-sort. 2 or 3 = bucket by X-coordinate left-to-right. Use for untagged 新旧対照表 / two-column PDFs where Y-sort would interleave columns. Tagged PDFs with proper <Table> markup should use extract_tables instead.
compact_whitespaceNoWhen true, collapse runs of whitespace (incl. fullwidth space U+3000) to a single ASCII space and trim each line. Reduces token consumption on Japanese form-style PDFs. Default: false (no whitespace normalization).

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark it as read-only and non-destructive. The description adds details: downloads PDF, Y-coordinate-based reading order, max 50MB, 30s timeout, and parameter behaviors (e.g., split_columns for column reordering, compact_whitespace for Japanese PDFs). No contradiction.

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

Conciseness5/5

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

The description is succinct yet comprehensive: 4 short paragraphs, bullet-point args, examples. Front-loaded with main purpose. Every sentence adds value.

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

Completeness5/5

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

Despite no output schema, the description covers all 5 parameters, limits, timeout, format, and provides examples. It references read_text for return format, which is sufficient given the shared format. Highly complete.

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

Parameters5/5

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

With 100% schema coverage, baseline is 3, but description adds significant meaning: explains split_columns' use for untagged multi-column PDFs, compact_whitespace for reducing tokens in Japanese forms, and response_format options. Examples illustrate usage.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Fetch a PDF from a URL and extract its text content.' It distinguishes from siblings by mentioning 'Like read_text' and explicitly directing tagged PDFs to 'extract_tables'.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool vs alternatives: 'Tagged PDFs should use extract_tables instead.' It also implies use for URL-based PDFs and reference to read_text for similar functionality.

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

search_textSearch PDF TextA
Read-onlyIdempotent

Search for text within a PDF document. Returns matching locations with surrounding context.

Case-insensitive search across all or specified pages. Each match includes the page number, the matched text, and configurable surrounding context.

Args:

  • file_path (string): Absolute path to a local PDF file

  • query (string): Text to search for (case-insensitive, 1-500 chars)

  • pages (string, optional): Page range to search. Omit for all pages.

  • context_chars (number): Characters of context before/after match (default: 80)

  • max_results (number): Maximum matches to return (default: 20, max: 100)

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Search matches with page number, matched text, and surrounding context.

Examples:

  • Search entire PDF: { file_path: "/path/to/doc.pdf", query: "digital signature" }

  • Search specific pages: { file_path: "/path/to/doc.pdf", query: "error", pages: "1-10" }

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
queryYesText to search for (case-insensitive)
pagesNoPage range to process. Format: "1-5", "3", or "1,3,5-7". Omit for all pages.
context_charsNoNumber of characters to show before and after each match
max_resultsNoMaximum number of matches to return
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing case-insensitivity, context output, page range support, and configurable limits. It could mention performance implications for large PDFs, but overall it provides good behavioral insight beyond annotations.

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

Conciseness5/5

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

The description is well-structured: a concise purpose sentence, clear parameter list (Args), return description, and practical examples. Every sentence is informative and earns its place.

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

Completeness5/5

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

Given 6 parameters, no output schema, and the presence of sibling tools, the description is complete. It covers all parameter details, return format, examples, and edge cases (like all pages vs. specific pages).

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

Parameters4/5

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

With 100% schema description coverage, the schema already documents each parameter. However, the description adds examples, default values, and constraints (e.g., query length, context_chars range) that enhance understanding beyond the schema.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Search for text within a PDF document. Returns matching locations with surrounding context.' This specifies the verb (search), resource (PDF text), and output, distinguishing it from sibling tools like read_text (extracts all text) or inspect_structure.

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?

The description provides clear context for usage: it performs case-insensitive search across all or specified pages, and offers examples. It does not explicitly exclude scenarios or mention alternatives, but the context of sibling tools implies its specialized role.

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

summarizeSummarize PDFA
Read-onlyIdempotent

Generate a quick overview report of a PDF document.

Combines metadata, text presence check, image count, and a text preview from the first page into a single summary. Useful as a first step before deciding which detailed tools to use.

Args:

  • file_path (string): Absolute path to a local PDF file

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Summary including: page count, PDF version, file size, tagged/encrypted/signature flags, text presence, image count, and a text preview from page 1.

Examples:

  • Quick overview: { file_path: "/path/to/doc.pdf" }

  • Machine-readable: { file_path: "/path/to/doc.pdf", response_format: "json" }

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it combines several analyses (metadata, text, images) but doesn't contradict annotations or add surprising behaviors. Adequate for a safe read tool.

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?

Structured with summary, details, Args, Returns, Examples. Front-loaded with purpose. Efficient but not overly terse; every section earns its place.

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?

Despite no output schema, description fully lists return value components. With 100% schema coverage and clear usage guidance, the tool is well-documented for an AI agent.

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?

Input schema has 100% coverage with detailed descriptions for both parameters. Description's Args section echoes schema info with default and enum values, but adds no new meaning beyond what schema provides.

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

Purpose5/5

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

Title and first sentence clearly state the tool generates a quick overview report. Description includes specific elements (metadata, text presence, image count, text preview) and differentiates from siblings by stating it's a first step before using detailed tools.

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?

Explicitly says 'Useful as a first step before deciding which detailed tools to use', which implies context and alternatives. Examples show typical usage. Lacks explicit when-not-to-use but is clear enough.

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

validate_metadataValidate PDF MetadataA
Read-onlyIdempotent

Validate PDF metadata conformance against best practices and specification requirements.

Args:

  • file_path (string): Absolute path to a local PDF file

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Validation results including: total checks, pass/fail counts, detailed issues with severity, metadata field presence summary, and an overall summary.

Checks performed:

  • Title presence (required for PDF/UA, PDF/A)

  • Author presence

  • Creation date format validation

  • Modification date presence

  • Producer identification

  • PDF version detection

  • Tagged flag status

  • Subject and Keywords presence

  • Encryption and accessibility impact

Examples:

  • Verify PDF metadata completeness for PDF/A archival

  • Check metadata requirements for PDF/UA compliance

  • Audit document metadata for publishing standards

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true. The description adds value by listing all checks performed (title, author, dates, etc.) and detailing return components, which provides substantial behavioral context beyond annotations.

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

Conciseness5/5

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

The description is efficiently structured with clear sections (Args, Returns, Checks, Examples). Every line adds value; no redundancy or unnecessary words.

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

Completeness5/5

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

Given the tool's complexity, the description covers purpose, parameters, return values, detailed check list, and usage examples. No gaps despite missing output schema.

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% with detailed descriptions for both parameters. The description repeats file_path and response_format in Args without adding new semantic information, so it meets the baseline but does not enhance understanding.

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

Purpose5/5

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

The description clearly states 'Validate PDF metadata conformance against best practices and specification requirements,' providing a specific verb and resource. It distinguishes from siblings like get_metadata (retrieval) and validate_tagged (tag validation) by focusing on metadata conformance.

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?

The description gives explicit usage examples (PDF/A, PDF/UA, publishing audits) but does not directly compare with alternatives or specify when not to use the tool. The context is clear but lacks exclusion guidance.

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

validate_taggedValidate Tagged PDFA
Read-onlyIdempotent

Validate PDF/UA tagged structure requirements.

Args:

  • file_path (string): Absolute path to a local PDF file

  • response_format ('markdown' | 'json'): Output format (default: 'markdown')

Returns: Validation results including: whether the PDF is tagged, total checks performed, pass/fail counts, detailed issues with severity levels (error/warning/info), and a summary.

Checks performed:

  • Document marked as tagged

  • Structure tree root existence

  • Document root tag presence

  • Heading hierarchy (H1-H6) sequential order

  • Figure tags for images

  • Paragraph tag presence

  • Structure element count

  • Table tag structure (TR/TH/TD)

Examples:

  • Check if a PDF meets PDF/UA accessibility requirements

  • Identify missing or incorrect tag structure

  • Assess document accessibility quality

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local PDF file (e.g., "/path/to/document.pdf")
response_formatNoOutput format: "markdown" for human-readable, "json" for structured datamarkdown

TDQS

A4.4/5.0
Behavior5/5

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

Annotations indicate read-only, non-destructive, idempotent behavior. The description adds substantial behavioral context by listing all performed checks (8 specific checks) and return values. No contradictions.

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?

The description is well-structured with clear sections (Args, Returns, Checks performed, Examples). It is somewhat lengthy but every section adds value. Front-loaded with purpose.

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

Completeness5/5

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

Given the tool's complexity (multiple checks, no output schema), the description fully conveys inputs, outputs (detailed return fields), and examples. Agent can reliably invoke and interpret results.

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% with both parameters fully described. The description restates parameter info but adds default value. No additional semantic value beyond schema for parameter understanding.

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

Purpose5/5

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

The title 'Validate Tagged PDF' and description explicitly state validation of PDF/UA tagged structure requirements. The description lists specific checks (e.g., heading hierarchy, table tags) that clearly differentiate it from sibling tools like 'inspect_tags' or 'validate_metadata'.

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?

The description provides clear examples of when to use the tool (e.g., check PDF/UA compliance, identify missing tags). It does not explicitly contrast with alternatives, but the examples give sufficient context for agent to decide.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 16 tool updatesv0.6.2
    • First observedcompare_structure
    • First observedextract_tables
    • First observedget_metadata
    • First observedget_page_count
    • First observedinspect_annotations
    • First observedinspect_fonts
    • First observedinspect_signatures
    • First observedinspect_structure
    • First observedinspect_tags
    • First observedread_images
    • First observedread_text
    • First observedread_url
    • First observedsearch_text
    • First observedsummarize
    • First observedvalidate_metadata
    • First observedvalidate_tagged
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 16 tools

Disambiguation5/5

Each tool targets a specific PDF aspect: text extraction, table extraction, image extraction, metadata, structural inspection, annotation, font, signature, tag accessibility, comparison, search, validation, and summary. No two tools perform the same function; even read_text and read_url differ by source. All purposes are clearly distinct.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (e.g., extract_tables, inspect_fonts, validate_metadata). The verbs are varied (compare, extract, get, inspect, read, search, validate) but each is appropriate for the action, and there is no mixing of conventions like camelCase.

Tool Count5/5

16 tools is well-scoped for a PDF analysis MCP server. It provides a comprehensive set for reading, inspecting, and validating PDFs without being overwhelming. Each tool earns its place; there are no redundant or trivial tools.

Completeness5/5

The tool surface covers all major PDF analysis needs: metadata, text (local & URL), tables, images, structure, annotations, fonts, signatures, tags, search, comparison, and validation. There are no obvious gaps; the set allows agents to thoroughly inspect a PDF's content and properties.

Maintenance

ActivityActive
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers