Skip to main content
Glama
JoyTruepath

TruePath PDF MCP Server

by JoyTruepath
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

TruePath PDF — MCP server

Let your AI process PDFs locally. Files never leave your Mac.

@truepathpdf/mcp-server is a Model Context Protocol server that lets Claude, Cursor, and any other MCP-aware client read and process PDF files on your machine — without uploading them anywhere.

Built and maintained by Joy Truepath Pte. Ltd., the team behind the TruePath PDF Mac app.

Status

v0.3 — free tier complete (9 of 9 tools). Read + edit + rasterise + GUI handoff: get_info, extract_text, search, split, merge, pages, to_images, extract_images, open_in_truepath. The full Pro tier (redact, fill_form, flatten, sign, compress, annotate, autocrop, batch, ocr) lands behind an Ed25519 license key in v0.4.

open_in_truepath requires the TruePath PDF Mac app v1.0.1 or newer (the truepath:// handler is added in 1.0.1; the v1.0.0 build does not register it).

Related MCP server: PDF Knowledgebase MCP Server

Privacy

  • 100% local. The MCP server runs on your machine and never talks to a network.

  • No telemetry, no analytics, no phone-home.

  • Free tools work fully offline, forever, with no key.

  • Pro tools (coming soon) are gated by an offline Ed25519 license check — still no network call at use time.

Install

# npx — no install required
npx -y @truepathpdf/mcp-server

# or install globally
npm install -g @truepathpdf/mcp-server
truepath-pdf-mcp

Requires Node.js 20 or newer.

Hook up to Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "truepath-pdf": {
      "command": "npx",
      "args": ["-y", "@truepathpdf/mcp-server"]
    }
  }
}

Restart Claude Desktop. The truepath-pdf tools appear in the tool tray.

Tools (v0.2)

get_info

Page count, first-page size (with an allSameSize flag), encryption status, and embedded PDF metadata (title, author, dates, producer, format version).

{ "path": "/Users/you/Documents/report.pdf" }

extract_text

Plain-text extraction. Optional 1-based page range ("3", "1-5", "1,3,5-7"). Output is grouped by page with ===== Page N ===== markers so the model can cite the right page.

{ "path": "/Users/you/Documents/report.pdf", "pages": "1-3" }

search

Substring search across the whole document. Returns each hit's page, offset within the page, and a snippet of surrounding text. Use for grep-style discovery before a heavier extract_text.

{ "path": "/Users/you/Documents/report.pdf", "query": "revenue", "contextChars": 80 }

split

Split one PDF into N by page ranges. Each range becomes one output file.

{ "path": "/in.pdf", "ranges": ["1-3", "4-7", "8"], "outputDir": "/out" }

merge

Combine two or more PDFs into one, in the given order.

{ "paths": ["/a.pdf", "/b.pdf", "/c.pdf"], "outputPath": "/out/merged.pdf" }

pages

Delete, rotate, and reorder pages in one pass. delete is applied first (page numbers in rotate refer to the source PDF); reorder is applied to the survivors.

{
  "path": "/in.pdf",
  "outputPath": "/out/edited.pdf",
  "delete": "2,5",
  "rotate": [{ "page": 1, "degrees": 90 }],
  "reorder": [3, 1, 2]
}

to_images

Rasterise PDF pages as PNG or JPG at a chosen DPI. Common DPIs: 96 (screen), 150 (print preview), 300 (print).

{ "path": "/in.pdf", "outputDir": "/out", "pages": "1-5", "dpi": 150, "format": "png" }

extract_images

Pull embedded images out of a PDF and write each as a PNG. Reports any images skipped because of unsupported pixel layouts (CMYK, palettized, etc).

{ "path": "/in.pdf", "outputDir": "/out" }

open_in_truepath

Hand a local PDF to the TruePath PDF Mac app via truepath://open?path=…. Fire-and-forget: macOS launches (or routes to) the app, the URL handler opens the PDF. Use this after reading / analyzing in MCP to drop the user into the GUI for annotation, signing, redaction, etc.

{ "path": "/Users/you/Documents/report.pdf" }

Optional scheme param for re-branded engine builds (default truepath; the Yochen core build uses yochenpdf).

If the app isn't installed (no truepath:// handler registered — the app is absent or older than v1.0.1), the tool doesn't error. It returns handedOff: false with a one-line pointer to the TruePath PDF download so you can install it and retry. (Only for the default truepath scheme; a custom scheme gets a plain failure.)

Roadmap

Pro tier (v0.4, Ed25519 license key, offline verify)

  • redact — text-preserving redaction via PDFium (the same engine the Mac app uses; the words are removed from the file, not just covered)

  • fill_form — fill AcroForm fields, save with values preserved

  • flatten — bake filled forms / annotations into the page stream

  • sign — visible signature placement, signed-PDF write

  • compress — recompress images / streams to shrink file size

  • annotate — programmatic highlight / underline / sticky-note

  • autocrop — detect content bounds and crop margins

  • batch — apply any tool across a glob of files

  • ocr — Apple Vision OCR (Mac only, on-device, CJK-strong)

A buy-once Pro key will be available via Lemon Squeezy at launch (target: USD 29, includes 12 months of updates). Owners of the TruePath PDF Mac app will be able to redeem their App Store receipt for a Pro MCP key via an in-app button.

License

MIT for the MCP shell. Transitive dependencies:

Pro tier will additionally bundle a prebuilt PDFium library (BSD/Apache, the same one used by Chrome).

Contact

Available Tools

9 tools
extract_imagesExtract embedded imagesA

Pull embedded images out of a PDF and write each as a PNG. Unsupported pixel layouts (e.g. CMYK, palettized) are skipped and reported.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to the source PDF.
pagesNo1-based page range. Omit for all pages. Format: "1-5" or "1,3,5-7".
basenameNoStem for output filenames. Default = source name. Final form: '<stem>-p001-img01.png'.
outputDirYesDirectory to write extracted images into.

TDQS

A4.1/5.0
Behavior4/5

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

Without annotations, the description takes full responsibility for behavior. It discloses unsupported pixel layouts are skipped and reported. However, it doesn't mention if the output directory must exist, if files are overwritten, or if a return value is provided. Still, the key behavioral trait is covered.

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?

Two sentences, front-loaded with action, no unnecessary words. Each sentence earns its place.

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

Completeness3/5

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

Given no output schema and no annotations, the description is somewhat complete but lacks details on return values (e.g., list of extracted files or status). The agent might need to infer success from side effects.

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 description coverage is 100%, so baseline is 3. The description adds context about PNG output and skipped layouts but does not enhance parameter meaning 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 action ('pull embedded images'), the resource ('PDF'), the output format ('PNG'), and handling of unsupported layouts. It distinguishes itself from siblings like extract_text and to_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 implies when to use this tool but does not explicitly state when not to use it or suggest alternatives. For example, it doesn't mention that extract_text is for text extraction or to_images for page-level images.

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

extract_textExtract textA

Extract plain text from a local PDF. Optionally restrict to a page range like "1-5" or "1,3,5-7". Output is split by page with === Page N === markers.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to a PDF on the local filesystem.
pagesNoPage range (1-based). Examples: "3", "1-5", "1,3,5-7". Omit for all pages.

TDQS

A3.8/5.0
Behavior4/5

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

Describes output format (split by page with markers) and optional page range. Since no annotations provided, the description adequately covers behavioral aspects for a read-only extraction tool, though does not mention error handling or performance limits.

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?

Two concise sentences, front-loaded with primary action. No unnecessary words; every sentence adds value.

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?

With no output schema, the description appropriately explains output format and parameter usage. Could mention error cases or file requirements, but overall sufficient for a simple tool with two parameters.

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 already provides detailed descriptions for both parameters (path and pages). The description only restates the page range functionality, adding minimal new semantic value 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?

Clearly states it extracts plain text from a local PDF, specifies optional page range and output format. Distinguishes from sibling tools by focusing on text extraction rather than info retrieval or search.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives like get_info or search. Does not mention prerequisites or scenarios where this tool is appropriate.

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

get_infoGet PDF infoA

Return page count, first-page size, encryption status, and embedded metadata (title, author, dates, producer, etc.) for a local PDF.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to a PDF on the local filesystem.

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description bears the full burden. It states outputs but does not disclose error handling, file existence checks, or side effects. The tool is implicitly read-only, but this is not explicit.

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 a single sentence that efficiently lists all key outputs. Every word is informative, with no redundancy or filler.

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 the tool's low complexity (1 parameter, no nested objects, no output schema), the description is mostly complete. It covers the core outputs but could mention return format or error cases for full clarity.

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 description coverage is 100%, so the parameter 'path' is adequately described in the schema. The description adds no extra meaning beyond what the schema provides, meeting the 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 verb (return) and the resource (PDF info), listing specific items like page count, encryption status, and metadata. It distinguishes from siblings extract_text and search by focusing on metadata rather than text extraction or searching.

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 when needing PDF metadata, but provides no explicit guidance on when to use this tool versus alternatives. No when-not-to-use or prerequisite conditions are mentioned.

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

mergeMerge PDFsA

Combine two or more PDFs into one, preserving page order. Outputs to a caller-specified path.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathsYesTwo or more absolute PDF paths to combine, in order. The result preserves pages in the order given.
outputPathYesAbsolute path for the combined output PDF. Its parent directory will be created if missing.

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It mentions preserving page order and output path but lacks details on permissions, error handling, or other behavioral traits.

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 one sentence, front-loaded with the main action, and contains no unnecessary words.

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

Completeness4/5

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

For a simple merge tool with two parameters and no output schema, the description covers the main functionality. It could mention output behavior or results, but overall it is fairly 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. The description does not add significant new semantics beyond what the schema already provides (e.g., 'preserving page order' is also in schema descriptions).

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 combines two or more PDFs into one, preserving page order, and specifies the output is to a caller-specified path. This distinguishes it from siblings like split, extract, etc.

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 usage for merging PDFs but does not provide explicit when-to-use or when-not-to-use guidelines, nor does it mention alternatives among the sibling tools.

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

open_in_truepathOpen in TruePath PDF (Mac app)A

Hand a local PDF to the TruePath PDF Mac app via its truepath:// URL scheme so the user can finish work in a GUI (annotate, sign, fill forms, redact). The bridge is fire-and-forget — the app handles opening from there. Requires the app installed (https://joytruepath.com/truepath-pdf).

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to the PDF to open in the TruePath PDF Mac app.
schemeNoURL scheme of the receiving app. Default "truepath". Set this if you're handing off to a re-branded build of the engine — e.g. "yochenpdf" for the Yochen core build, or whatever urlScheme the destination's Brand.plist exposes.

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description discloses key behaviors: fire-and-forget, requires app installation, and links to download. However, it does not specify error handling (e.g., if app is missing or path invalid) or whether the function returns any status. This leaves some behavioral transparency gaps.

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 two sentences, efficiently front-loading the purpose. Every sentence adds value: first sentence gives action and use case, second explains mechanism and requirement. No extraneous words.

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, the description explains the fire-and-forget nature and app requirement. It lacks explicit error handling or return value details, but for a simple open-in-app tool, the context is fairly complete for an agent to use 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 coverage is 100%, so baseline is 3. The description adds meaning for the 'scheme' parameter by explaining its default and when to override it (re-branded builds), which goes beyond the schema's description. The 'path' parameter is similarly clarified as absolute path.

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 hands a local PDF to the TruePath PDF Mac app via URL scheme, with a specific verb 'hand' and resource 'local PDF'. It distinguishes itself from sibling tools like extract_images, merge, etc., which serve different purposes.

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: use when the user needs GUI-based work on a PDF (annotate, sign, fill forms, redact) and notes it's fire-and-forget. However, it lacks explicit when-not-to-use instructions or alternatives, though the context is sufficient for an agent.

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

pagesEdit pages (rotate / delete / reorder)A

One-pass page editor. Delete pages, rotate specific pages by 90°/180°/270°, and reorder the result — in any combination. Page numbers in rotate refer to the SOURCE PDF; reorder refers to post-delete positions.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to the source PDF.
deleteNoPages to delete, 1-based, comma/range form. Example: "1,3,5-7". Applied BEFORE rotate and reorder.
rotateNoPer-page absolute rotations applied to pages that survive the delete step. Page numbers refer to the SOURCE PDF, not the post-delete one — easier to reason about.
reorderNoNew page order, expressed as 1-based positions in the post-delete output. Example: [3,1,2] puts page 3 first. Must be a permutation of all surviving pages.
outputPathYesAbsolute path to write the result to.

TDQS

A4.3/5.0
Behavior4/5

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

The description explains the order of operations (delete first, then rotate and reorder) and clarifies that rotate page numbers refer to source PDF while reorder uses post-delete positions. Without annotations, this provides good transparency, though it could mention that the output file overwrites without warning.

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 three sentences, front-loaded with the main purpose and operation order. Every sentence adds value without redundancy.

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 the complexity of combining delete, rotate, and reorder with different page references, the description covers the essential nuances. However, it could explicitly state that the output file will be overwritten if it exists.

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?

All parameters have schema descriptions (100% coverage), but the tool description adds crucial context about the order of operations and page numbering semantics for rotate and reorder, which are not present in the schema. This significantly aids correct 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 title and description clearly state the tool edits PDF pages by deleting, rotating, and reordering. It distinguishes itself from sibling tools like extract_images, merge, and split, which perform different operations.

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 usage for combined page edits ('in any combination') but does not explicitly state when to use this tool versus alternatives. No when-not or alternative tool guidance is provided.

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

splitSplit PDFA

Split a PDF into multiple PDFs by page ranges. Each range becomes one output file written into outputDir.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to the source PDF.
rangesYesPage ranges to split into separate output PDFs, 1-based. Examples: ["1-3", "4-7", "8"] produces three files. Each range becomes one output PDF.
basenameNoStem for output filenames. Default = source filename without .pdf. Final names look like '<basename>-1-3.pdf'.
outputDirNoDirectory to write outputs into. Defaults to the source PDF's directory.

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that each range becomes one output file written into an output directory. However, it does not specify whether files are overwritten, whether the directory is created if missing, or any permission requirements. This is adequate but lacks deeper behavioral 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 two sentences and front-loaded with the core purpose: 'Split a PDF into multiple PDFs by page ranges.' Every word is informative and no redundancy is present. It is optimally concise.

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

Completeness3/5

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

Given no output schema, the description should at least hint at what the tool returns. It mentions that output files are written but does not specify if the tool returns file paths, a success message, or nothing. For a moderately complex tool with 4 parameters, this omission leaves the agent uncertain about the response.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema, merely reiterating that ranges produce output files. The schema already describes all four parameters clearly, including examples for ranges and defaults for basename and outputDir.

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 'Split a PDF into multiple PDFs by page ranges,' which includes a specific verb (split) and resource (PDF). It distinguishes from sibling tools like merge (combining), extract_images (image extraction), and extract_text (text extraction).

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 when to use this tool (splitting a PDF by page ranges) but does not explicitly mention when not to use it or identify alternative tools for similar tasks. It is sufficient for an agent to infer appropriate usage, but explicit exclusions would strengthen it.

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

to_imagesRender pages to imagesA

Rasterize PDF pages as PNG or JPG at a chosen DPI. Useful for previews, OCR pipelines, or feeding pages back to a vision model.

ParametersJSON Schema
NameRequiredDescriptionDefault
dpiNoRender resolution. Default 150. PDF native is 72; common values: 96 screen, 150 print preview, 300 print.
pathYesAbsolute path to the source PDF.
pagesNo1-based page range, e.g. "3", "1-5", "1,3,5-7". Omit for all pages.
formatNoOutput format. Default "png". "jpg" is smaller but lossy.
basenameNoStem for output filenames. Default = source filename without .pdf. Final names: '<basename>-001.png' (page number padded to 3 digits).
outputDirYesDirectory to write the rendered images into.
jpgQualityNoJPEG quality 40-100. Default 85. Ignored for PNG.

TDQS

A3.9/5.0
Behavior3/5

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

Covers basic behavior but lacks disclosure of potential slowness, memory use, or file creation details beyond what schema provides.

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?

Two sentences with no fluff; use cases are front-loaded and relevant.

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

Completeness3/5

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

Adequate for a tool with detailed schema, but misses context on output file creation and page range interpretation beyond 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?

Description adds little beyond schema which already has detailed parameter descriptions (100% coverage).

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 it rasterizes PDF pages to PNG or JPG at chosen DPI, distinguishing from siblings like extract_text and extract_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?

Mentions specific use cases (previews, OCR, vision model) and implies alternatives via sibling context, but no explicit when-not-to-use.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv0.3.0
    • Addedextract_images
    • Addedmerge
    • Addedopen_in_truepath
    • Addedpages
    • Addedsplit
    • Addedto_images
  2. 3 tool updatesv0.1.0
    • First observedextract_text
    • First observedget_info
    • First observedsearch
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: extracting full text, retrieving metadata, and searching for substrings. There is no overlap or ambiguity.

Naming Consistency4/5

Two tools follow verb_noun pattern (extract_text, get_info) while search is a verb alone, but the naming is still clear and predictable overall.

Tool Count5/5

Three tools cover the core operations—extraction, metadata, and search—without being excessive or insufficient for a PDF utility server.

Completeness5/5

The tool set provides a complete workflow for text-based PDF interaction: extract full text with page range, get metadata, and search. No obvious gaps for the intended purpose.

Maintenance

ActivityStale
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JoyTruepath/truepath-pdf-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server