@shuji-bonji
基本信息
An MCP (Model Context Protocol) server specialized in deciphering PDF internal structures.
使用下面的配置,将此服务器添加到你的 MCP 客户端。
{
"mcpServers": {
"pdf-reader-mcp": {
"command": "npx",
"args": [
"-y",
"@shuji-bonji/pdf-reader-mcp"
]
}
}
}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
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
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. `/ActualText` replacements (ISO 32000-2 §14.9.4) are resolved, on both of the paths that clause defines: the `/ActualText` of a structure element, and the one in a `Span` marked-content property list — the latter occurs in untagged documents too. So a word carried as ActualText (ligature substitutes, hyphenation fixes) reads here the way a person viewing the page sees it, not in its glyph form. For **tagged** PDFs, `extract_structured_text` is still the better tool when order matters: it returns text in logical content order (ISO 32000-2 §14.8.2.5), which this tool does not — read_text sorts by coordinate. Tables in tagged PDFs are best read with `extract_tables`. 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. 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". **Omitting it means ALL pages** — on a large document that consumes the whole response budget in one call. Past ~50 pages, search_text first and pass an explicit range here. - 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. Every page also reports how much of its text could be converted to Unicode (ISO 32000-2 §9.10.1): `extracted`, `no_text_layer` (no text-showing operator, image content present — reading it needs OCR or a rendered page), `not_extractable` (a font used here offers no route to Unicode, so text is missing or wrong), or `not_observed` (encrypted or unreadable content stream). An empty result is therefore never by itself evidence that a page has no text. Two separate readings produce that answer: taking the characters off the page, and observing whether those characters have a route to Unicode. Either can fail on its own, so the response says which of the two was done, under `scope`. When the characters were taken but the observation could not run, the text is still returned and `extractability` is left off the pages — absent is not `extracted`. When the characters could not be taken but the observation ran, `text` is `null` (not `""`, which would say the page has no text) and the per-page observation still tells you whether the page has any text-showing operator at all. Only when neither reading could be done is this an error, and it then names both reasons. Returns: `{ scope, pages }`. `pages` is the extracted text organized by page number, preceded by the extractability tally. 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 }
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. The search runs over the same text `read_text` returns, so `/ActualText` replacements (ISO 32000-2 §14.9.4) match: a word carried as ActualText (ligature substitutes, hyphenation fixes) is found under the spelling a viewer shows, not under its glyph form. Rarely, a page's marked content cannot be aligned with the extracted text and the replacement is left unresolved; when that happens on a search with no hits, the result carries a `note` naming those pages. 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, plus `scope` — which of the two readings behind the answer were done: searching the characters on the page, and observing whether those characters have a route to Unicode (ISO 32000-2 §9.10.1). When the search itself could not run, `totalMatches` and `matches` are `null` rather than `0` and `[]`: "could not search" and "searched and found nothing" are different answers. 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" }
Extract embedded images from a PDF document as PNG or JPEG files. Each image is returned as an MCP image content block, so a vision-capable model can look at it directly. A text block lists the metadata for all of them (page, index, size in the file, size returned, colour space, encoded bytes). These are the image XObjects the page draws, not a picture of the page. A page whose content is vector drawing, or whose text is what you want to see, is not covered by this tool. Response size is bounded: at most 4 MB of encoded image data per call. Images beyond the budget are named in the text block with the reason and are not returned — nothing is dropped silently. A 200 dpi A4 scan is ~11.6 MB of pixels on its own, so pass `pages`, `max_width` or `max_height` when working with scans. 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". **Omitting it means ALL pages** — on an image-heavy document that exhausts the byte budget immediately. Name the pages you need. - format ('png' | 'jpeg', optional): Output encoding. Default 'png' (lossless). 'jpeg' is smaller and composites alpha over white. - quality (1-100, optional): JPEG quality. Ignored for PNG. - max_width (number, optional): Downscale images wider than this (area average). Never enlarges. - max_height (number, optional): Downscale images taller than this. Returns: A text block with the metadata table and any omissions, then one image content block per returned image. Examples: - Extract all images: { file_path: "/path/to/doc.pdf" } - A scanned page, small enough to look at: { file_path: "/path/to/scan.pdf", pages: "1", max_width: 1200, format: "jpeg" }
Fetch a PDF from a URL and extract its text content. Text is ALL this tool returns — see the scope note below. 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. **Scope (#25):** the fetched bytes are discarded after extraction; this tool deliberately does not save them. Every other tool of this server takes a `file_path`, so to use search_text, inspect_structure, extract_tables, render_page or anything else on a URL's PDF, download the file to local disk FIRST (with whatever fetch capability the calling environment has) and pass its path. This keeps every tool of this server read-only with respect to the file system — writing files is not a reader's job. read_url exists for the one-shot case: "what does the document at this URL say?" 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: `{ scope, pages }`, the same shape as read_text: `pages` is the extracted text by page number, and `scope` says which of the two readings behind it were done — taking the characters off the page, and observing whether those characters have a route to Unicode (ISO 32000-2 §9.10.1). Either can fail on its own; only when neither could be done is this an error, and it then names both reasons. 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 }
Rasterise pages of a PDF to PNG or JPEG images, returned as MCP image content blocks. This is the tool for documents whose text cannot be read as text: pages `read_text` reports as `no_text_layer` or `not_extractable`, vector drawings, forms, handwriting, stamps. It draws the PAGE — everything on it — where `read_images` only extracts the image XObjects a page happens to embed. Rendering uses PDFium compiled to WebAssembly (optional dependency `@hyzyla/pdfium`). Note this is a different engine from the pdf.js this server reads text with; where their behaviour on a damaged file differs, neither output is evidence about the other. If the dependency is not installed, this tool says so and every other tool works normally. `pages` is required — rendering is the most expensive operation here, and "all pages" of a large scan should be a decision, not a default. The response carries at most 4 MB of encoded images; pages past the budget are named with the reason, not dropped. Args: - file_path (string): Absolute path to a local PDF file - pages (string, REQUIRED): Page range: "1-3", "5", "1,3,5-7". - dpi (36-600, optional): Density, default 150. 150 reads well; 300 for small print. - max_width (number, optional): Pixel-width cap; wins over dpi when smaller. - format ('png' | 'jpeg', optional): Default 'png'. 'jpeg' is usually right for scans. - quality (1-100, optional): JPEG quality. Returns: A text block with per-page metadata (point size, pixel size, effective dpi, bytes) and any omissions, then one image content block per rendered page. Rasterising a page can take unbounded time — a tiling pattern (ISO 32000-2 §8.7.3.1) whose `/XStep` or `/YStep` is a near-zero magnitude asks for an astronomical number of tiles, and the clause forbids only zero. Each page therefore gets 20 seconds (`PDF_READER_RENDER_TIMEOUT_MS` overrides it); the rendering runs off the main thread, so a page that does not finish is stopped and named in the omissions rather than taking the server down with it. The pages rendered before it are still returned, and the pages after it are reported separately as not attempted — "could not be rendered" and "never started" are different answers. Examples: - A scanned page: { file_path: "/path/to/scan.pdf", pages: "1", format: "jpeg" } - A diagram at high detail: { file_path: "/path/to/doc.pdf", pages: "3", dpi: 300 }
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') `hasText` is decided from page 1's preview and cannot say *why* text is absent. `textExtractability` answers that over every page (ISO 32000-2 §9.10.1): `extracted`, `no_text_layer` (image content, no text-showing operator — the page needs OCR or a rendered image), `not_extractable` (a font used offers no route to Unicode), or `not_observed` (encrypted or unreadable content stream). `unreadablePages` lists the pages that are not `extracted`, with the reason. The summary ends with a `next` list: tool suggestions derived from the observations themselves (hasText false → render_page; tagged → extract_structured_text / extract_tables; large page count → search_text before read_text). Each line names the observation it follows from; nothing is enforced and no ordering is implied. Returns: Summary including: page count, PDF version, file size, tagged/encrypted/signature flags, text presence, per-document text extractability, the pages that are not fully extractable, image count, a text preview from page 1, and the `next` suggestions. Four separate readings produce that summary — the document information, the text of page 1, the image count, and the extractability observation — and any of them can fail on its own. `scope` says which were done. A field whose reading did not happen is `null`, never `0`, `false` or `""`: "not read" and "read and found nothing" are different answers, and `next` stays silent about any premise that was not observed. Examples: - Quick overview: { file_path: "/path/to/doc.pdf" } - Machine-readable: { file_path: "/path/to/doc.pdf", response_format: "json" }
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 COS types), page tree info (page count, MediaBox samples), object statistics, and encryption status. Object statistics report three separate counts: - byType: the COS type of each indirect object (ISO 32000-2 §7.3) — one of dict, stream, array, name, string, integer, real, boolean, null, ref - byDocType: the /Type of each dictionary (Catalog, Pages, Page, Font, ObjStm, XRef, ...) - unreadable: objects the cross-reference table names but that could not be read. This is counted apart from totalObjects: 0 means "every object was read", not "nothing was checked". Examples: - Examine document catalog for structural features - Count PDF objects and streams - Check page dimensions across the document
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
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
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)
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
Extract every `<Table>` subtree from a Tagged PDF as a structured row/cell list, optionally rendered as Markdown tables. How it works: walks the document's StructTreeRoot depth-first (the same walker as `extract_structured_text` / `inspect_tags`) 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). A Table that continues across a page break is ONE table (ISO 32000-2 §14.8.2.5 NOTE 2) — `pages` is an array, and a table touching the requested page range is returned whole. Cell text honours `/ActualText` replacements (§14.9.4). 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 `## Table N — Page(s) …` section per table with a GFM table. JSON — `{ isTagged, tables: [{ pages, index, headerRows, bodyRows, footerRows }], totalTables, pagesScanned, note? }`. `index` is the table's 1-based position in logical content order, document-wide. Limitations: - Untagged PDFs return an empty result and a `note`. - colspan/rowspan are not honoured (cells are listed in source order). - Nested tables are not emitted separately (their text appears in the outer cell). Examples: - Pull 新旧対照表 from a kaisei tsutatsu PDF for diffing - Convert 帳票 (form template) tables into structured data
Extract a tagged PDF's text in logical content order, with each piece labelled by its structure type. This answers "what is the text of the H1?" — which read_text (flat, coordinate order), inspect_tags (structure, no text) and extract_tables (text, tables only) each cannot. Args: - file_path (string): Absolute path to a local PDF file - pages (string, optional): Page range ("1-5", "3", "1,3,5-7"). Omit for all pages. An element that touches the range is returned whole, even if it continues outside it. - roles (string[], optional): Structure types to include, e.g. ["H1","H2"] for an outline - include_bbox (boolean): Also report where each element is drawn (default: false) - response_format ('markdown' | 'json'): Output format (default: 'markdown') Returns: isTagged, the document language, and a flat list of elements in logical content order. Each element has: role, depth (nesting; top level is 0), text, pages, and optionally alt / label / rows / boxes / boxNote. `scope` says which of the two readings behind that answer were done — reading the structure tree, and observing whether the characters under it have a route to Unicode (ISO 32000-2 §9.10.1). When the structure tree could not be read, `isTagged` and `elements` are `null` rather than `false` and `[]`: "not read" and "read and found no tags" are different answers. The list is flat with a depth field rather than nested — a depth-first pre-order plus depth encodes the tree exactly, so nothing is lost. Table is the exception and carries rows, because a table is two-dimensional and depth cannot express "row 2, column 3". Key properties: - Order is a depth-first traversal of the document's structure tree, which is how ISO 32000-2 §14.8.2.5 defines logical content order. - An element that spans pages stays ONE element (pages is an array). A paragraph split across a page break is returned as one paragraph, not two. - ActualText replaces the glyphs when present (§14.9.4: "a replacement, not a description"). Alt is reported separately in alt and never as text — it describes content that has no text (§14.9.3), so it must not leak into the body. - Lbl (a list bullet or number) is reported in label, not mixed into text. - Artifacts (page numbers, running heads) are excluded: §14.8.2.5 NOTE 3 puts them outside the logical content order. With include_bbox (answers "where is this paragraph?", so an annotation can be placed on it): Each element gains boxes — ONE RECTANGLE PER PAGE, because an element that spans pages has no single rectangle. Each is { page, rect: {x1,y1,x2,y2}, basis } in PDF default user space (origin bottom-left, pt, already normalised), which is exactly what pdf-writer-mcp add_annotation takes: no coordinate system has to be reinterpreted in between. /Rotate and a shifted /CropBox do not affect it. basis says how strong the claim is, and the two are not the same kind of claim: - layout-attribute-bbox — the /BBox the file DECLARES for the element (ISO 32000-2 Table 379). A statement by the producer about its own geometry, reported as-is. This is the only source for content that has no text. - text-extent — MEASURED from the text the element owns: baseline origin plus the font's ascent/descent. That is the line box, not the glyph outlines. Images and vector drawings contribute nothing to it. When a declared /BBox does not cover the text measured inside it, that disagreement is reported in boxNote rather than smoothed over. An element with no rectangle has no boxes and carries boxNote saying why — a Figure holding one image is the usual case (§14.8.4.8.5: such an element "should have a BBox attribute"). Absent is not zero-sized, and neither is guessed at. Untagged PDFs return isTagged: false with a reason and no elements. Nothing is guessed from coordinates — §14.8.2.5 NOTE 1 is explicit that page order need not match logical order, so a guess could n…
Report where the given objects sit on the page. Bridges "which object" to "which coordinates": pdf-verify-mcp's verify_integrity names the objects an incremental update changed, and pdf-writer-mcp's add_annotation wants a page number and a rectangle. The rectangle is returned in PDF user space (origin bottom-left, pt, x1 < x2 and y1 < y2 — ISO 32000-1 §7.9.5 normalised form), which is exactly what add_annotation takes. Args: - file_path (string): Absolute path to a local PDF file - object_numbers (number[]): Object numbers to locate, e.g. [25, 27] - response_format ('markdown' | 'json'): Output format (default: 'markdown') Returns: Per object: whether it exists, its /Type and /Subtype, and the places it occupies, each with the basis the coordinates rest on: - annotation-rect — the object's own /Rect. Exact. - page-box — the object is a page; the rectangle is its crop/media box. - page-content-stream — the object draws the page; the rectangle is the WHOLE page, not the part that changed. - page-resource — a font, image or colour space used by the page. No rectangle exists for it. Limits (observations, not judgements): - Narrowing a content stream to the paragraph that moved needs a content-stream walk with graphics state; this tool does not do it and says so rather than inventing a rectangle. - An object that does not exist (freed by a later revision) is returned with found: false — not as "no coordinates". - In an encrypted document, coordinates and types are still reliable (numbers and names are not encrypted, ISO 32000-1 §7.6.2) but field names are reported as null instead of mojibake. Examples: - Turn verify_integrity's "obj 27 was added after signing" into a page and rectangle - Find which page a changed form field widget is on before annotating it
[DEPRECATED — will be removed in the next major version] Prefer pdf-verify-mcp's `validate_conformance` with `flavour: "pdfua-1"` (or `"pdfua-2"`). It supersedes this tool rather than merely replacing it: it verifies the actual `/Alt` and `/ActualText` values of Figure tags (this tool only counts Figures), checks Link `/Contents`, inspects StructTreeRoot from the catalog directly (this tool synthesises it per page), cites ISO 14289 clauses, and delegates to veraPDF when available. Reason: the family boundary is "pass/fail against an ISO standard belongs to pdf-verify-mcp; reporting observations belongs to pdf-reader-mcp". This tool predates pdf-verify-mcp and was the exception. Use `inspect_tags` here for structure-tree facts — that tool is NOT deprecated. This tool remains a quick preflight and still works. Only the checks below are performed; a pass here does not imply PDF/UA conformance. 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. `totalChecks` counts the checks that were actually decided. A check whose premise could not be observed is not counted there and appears in `notChecked` with the reason — TAG-005 judges Figure tags against the number of images the page draws, so without that number it would have to assume zero images and would report a pass for something nobody looked at. 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
[DEPRECATED — will be removed in the next major version] For standards conformance, prefer pdf-verify-mcp's `validate_conformance` (`flavour: "pdfua-1"` / `"pdfa-*"`), which judges against the ISO text and delegates to veraPDF when available. Use `get_metadata` here if you just want to read metadata fields. Reason: the family boundary is "pass/fail against an ISO standard belongs to pdf-verify-mcp; reporting observations belongs to pdf-reader-mcp". This tool predates pdf-verify-mcp. Known limitation (not being fixed — superseded): the checks read the document information dictionary only. PDF/UA-1 §7.1 requires `dc:title` in the XMP metadata stream and states a conforming reader "shall ignore" the Info dictionary; it also requires `ViewerPreferences/DisplayDocTitle = true` and `Suspects = false`, none of which are checked here. ISO 32000-2 §14.3.3 deprecates the Info dictionary except CreationDate/ModDate. Treat the results below as general best-practice hints, not PDF/UA or PDF/A grounds. 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 (all against the Info dictionary — see the limitation above): - Title presence (best practice; NOT the PDF/UA basis, which is XMP dc:title) - 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: - Quick check of document metadata completeness for publishing standards - (For PDF/A archival or PDF/UA compliance, use pdf-verify-mcp validate_conformance instead)
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. The comparison needs both files, so an unreadable file is an error — but the error names which of the two could not be read, and says that the other one was fine. Examples: - Compare two versions of the same document - Verify structural consistency across PDF exports - Identify differences in PDF generation pipelines
Pdf Reader Mcp Server is an MCP (Model Context Protocol) server specialized in deciphering PDF internal structures. It provides 15 tools organized into three tiers—basic operations, structure inspection, and validation & analysis—focusing on reading and analyzing the internal structure of PDF documents rather than simple text extraction. It is designed for developers and quality assurance professionals working with PDF content, and it pairs with pdf-spec-mcp for specification-aware validation and analysis.
Install the server via npx @shuji-bonji/pdf-reader-mcp. For Claude Desktop, add it to claude_desktop_config.json as an MCP server. For Claude Code, run claude mcp add pdf-reader-mcp -- npx -y @shuji-bonji/pdf-reader-mcp. It can also be run from source by cloning the repository and running npm run build. Tools are invoked by calling their name with parameters such as file_path, query, or pages.
Typical PDF MCP servers are thin wrappers for text extraction, while this server focuses on reading and analyzing the internal PDF structure. It can be paired with pdf-spec-mcp for specification-aware analysis and validation.
It uses TypeScript with the MCP TypeScript SDK, pdfjs-dist for text/image extraction and tag tree parsing, pdf-lib for low-level object structure analysis, Vitest for testing, and Zod for input validation. ###
Upload once. Find, use and share across your AI workflows. drop.media is one media library for you and every AI agent you use: files added from Claude, ChatGPT, Cursor, the terminal or the web can be found, reused and sh
MCP Workspace Server: A secure Model Context Protocol server providing file, git, and GitHub tools for AI assistants within a sandboxed project directory.
DeviceLink lets you share folders from your computer with AI assistants, securely and in real-time. Nothing is uploaded. Your files stay on your machine, and are only accessible while the device sharing them is connected
📄 The PDF intelligence layer for AI agents — Agent Document Twin, evidence-first extraction, visual crops, OCR provenance, trust reports, and benchmark-gated releases. MCP server for Claude, Cursor, VS Code, and any MCP client.
filesystem MCP server for accessing WSL distributions from Windows
评论