The pdf-toolkit-mcp server provides 22 tools for comprehensive PDF manipulation, covering reading, creating, manipulating, rendering, and securing documents. It works offline with no external dependencies (pure WASM/JavaScript).
Read & Extract
Extract text content from PDF pages
Retrieve metadata (title, author, page count, dates, etc.)
List form fields with names, types, and values
Convert PDF content to reading-order Markdown
Search for specific text across pages and return snippets
Compare two PDFs page-by-page
Manipulate
Merge multiple PDFs into one (preserving form fields)
Split a page range into a new file (preserving form fields)
Delete specific pages (preserving form fields)
Reorder pages in any sequence, including duplicates (preserving form fields)
Rotate pages by 90, 180, or 270 degrees
Flatten form fields (bake values into static content)
Encrypt with AES-256 password protection (user and owner passwords)
Add configurable page numbers
Embed QR codes or barcodes (Code128, DataMatrix, EAN-13, PDF417, Aztec)
Add a diagonal text watermark with configurable opacity and font size
Embed PNG or JPEG images at custom coordinates
Fill interactive form fields with data
Create
Generate PDFs from plain text (configurable page size, font, margins)
Create PDFs from Markdown (headings, tables, lists, code blocks, optional header/footer)
Generate PDFs from named templates: invoice, report, or letter
Render
Render PDF pages to PNG/JPEG images, including inline images for vision models
💼 Available for freelance MCP/AI integration work — DM @aryansalian03 or via aryanbv.com
A write-capable PDF toolkit for any MCP client. It provides 22 tools for reading, creating, rendering, transforming, and securing PDFs. That includes rendering pages to images so vision models can read scanned documents, building PDFs from Markdown or structured data, AES-256 encryption, and merge and split operations that keep form fields intact. There are no native dependencies, so it runs locally from a single npx command.
npx -y @aryanbv/pdf-toolkit-mcpIt needs no config files, API keys, Docker, or compiler, and it works offline.
Most PDF servers for MCP only read. This one also writes: it creates documents from Markdown or structured data, fills and flattens forms, rearranges page structure, and applies AES-256 encryption, all without a native build toolchain.
A few things worth knowing:
It reads scans. pdf_render_pages rasterizes pages to images, so a vision-capable model can read scanned or image-only PDFs that have no text layer.
Merge, split, reorder, and delete preserve AcroForm fields rather than dropping them. Names that collide between inputs are namespaced per source, and every call reports what it preserved, renamed, or dropped.
Encryption is AES-256 through qpdf, not the legacy RC4 scheme.
Every engine is WASM or plain JavaScript, so npx works on Node 20 and later across Windows, macOS, and Linux with no node-gyp, canvas binding, or prebuilt binary.
Errors carry stable codes, stack traces stay internal, off-page placements are rejected instead of silently clipped, and large responses are truncated without breaking JSON.
Related MCP server: pretext-pdf-mcp
Add to claude_desktop_config.json:
{
"mcpServers": {
"pdf-toolkit": {
"command": "npx",
"args": ["-y", "@aryanbv/pdf-toolkit-mcp"]
}
}
}claude mcp add pdf-toolkit -- npx -y @aryanbv/pdf-toolkit-mcpAdd to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"pdf-toolkit": {
"command": "npx",
"args": ["-y", "@aryanbv/pdf-toolkit-mcp"]
}
}
}VS Code uses "servers", not "mcpServers". Copying another client's config will fail silently. This also requires the GitHub Copilot extension with Agent mode.
Add to .vscode/mcp.json:
{
"servers": {
"pdf-toolkit": {
"command": "npx",
"args": ["-y", "@aryanbv/pdf-toolkit-mcp"]
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"pdf-toolkit": {
"command": "npx",
"args": ["-y", "@aryanbv/pdf-toolkit-mcp"]
}
}
}Once connected, ask for what you want in plain language and the client selects the tool and fills in the arguments. The JSON blocks below show the arguments each tool accepts, for reference.
Category | Tool | Description |
Read |
| Extract text from PDF pages (first 10 by default) |
| Get title, author, subject, page count, dates, producer, and file size | |
| List form fields (text, checkbox, dropdown, radiogroup, listbox, button, signature) with names, types, values, and required status | |
| Convert a PDF to reading-order Markdown (column clustering, heading inference, list detection) | |
| Find text across pages and return page numbers with surrounding snippets (literal, case-insensitive by default) | |
| Page-by-page text diff between two PDFs | |
Manipulate |
| Merge multiple PDFs into one (preserves form fields) |
| Extract a page range into a new PDF (preserves form fields) | |
| Delete a page range and keep the rest (preserves form fields) | |
| Reorder pages in any order, duplicates allowed (preserves form fields) | |
| Rotate pages by 90, 180, or 270 degrees | |
| Bake form-field values into static content (removes interactivity) | |
| AES-256 password protection with user and owner passwords | |
| Add page numbers (configurable position, format, start, and size; rotation-aware) | |
| Embed a QR code or barcode (QR, Code128, DataMatrix, EAN-13, PDF417, Aztec; rotation-aware) | |
Create |
| Create a PDF from plain text (page size A4, Letter, or Legal; non-Latin via |
| Create a rich PDF from Markdown: headings, tables, lists, code, blockquotes (A4, Letter, or Legal) | |
| Create a PDF from a named template (invoice, report, letter) | |
| Fill form fields (text, checkbox, dropdown, radiogroup, listbox; non-Latin via | |
| Add a diagonal text watermark to pages | |
| Embed a PNG or JPEG image into a page | |
Render |
| Render pages to PNG or JPEG files, or return inline images a vision model can read directly |
Turn Markdown into a multi-page PDF in a single call. It supports CommonMark and GFM: headings, bold and italic, tables, ordered and bullet lists, fenced code, and blockquotes, rendered with @react-pdf/renderer.
"Create a PDF from this Markdown report."
pdf_create_from_markdown arguments:
{
"markdown": "# Quarterly Report\n\nRevenue grew **23% YoY**.\n\n| Region | Q1 2025 | Q1 2026 |\n|--------|---------|--------|\n| Americas | $1.2M | $1.5M |\n| EMEA | $800K | $960K |\n\n## Key Wins\n\n1. 12 new enterprise contracts\n2. Churn down to 3.1%",
"outputPath": "/path/to/report.pdf",
"pageSize": "Letter"
}Tables size their columns to content and honor alignment, nested lists indent, and long code lines wrap. Add page numbers afterward with pdf_add_page_numbers.
Generate documents from structured data using the invoice, report, and letter templates.
"Create an invoice for Riverbend Outfitters."
pdf_create_from_template arguments:
{
"templateName": "invoice",
"data": {
"companyName": "Northpoint Design",
"clientName": "Riverbend Outfitters",
"invoiceNumber": "2026-0042",
"invoiceDate": "2026-04-01",
"items": [
{ "description": "Website redesign", "quantity": 40, "unitPrice": 150 },
{ "description": "Annual hosting", "quantity": 1, "unitPrice": 299 }
],
"taxRate": 18,
"currency": "USD",
"paymentTerms": "Net 30"
},
"outputPath": "/path/to/invoice.pdf"
}The invoice template's optional currency accepts an ISO code or a symbol. WinAnsi-safe symbols ($ € £ ¥) render as glyphs; a code that Helvetica cannot draw, such as INR, KRW, or TRY, falls back to its ISO code label (INR 20.00), so any currency works without error. The pdf-toolkit://templates resource lists every template and the fields it accepts.
Many PDFs are scans with no text layer. pdf_render_pages rasterizes pages so a vision-capable client can read them.
"Read this scanned contract."
Inline mode returns pages as images the model reads directly (up to 5 pages; DPI is auto-capped to protect the context window):
{ "filePath": "/path/to/scanned.pdf", "inline": true }Or write image files to disk (default 150 DPI, first 50 pages, PNG):
{
"filePath": "/path/to/scanned.pdf",
"pages": "1-3",
"dpi": 200,
"format": "jpeg",
"outputDir": "/path/to/output"
}"Convert report.pdf to Markdown so I can summarize it."
pdf_to_markdown reconstructs reading order from text positions. It clusters up to two content columns (plus full-width title and footer bands), infers headings from font size, and detects lists. It works best on clean digital PDFs; use pdf_render_pages for scans. Returns the first 10 pages by default.
{ "filePath": "/path/to/report.pdf", "pages": "1-5" }"Find every mention of 'indemnification' in contract.pdf."
pdf_search arguments:
{
"filePath": "/path/to/contract.pdf",
"query": "indemnification",
"caseSensitive": false
}Each match comes back with its page number and a surrounding snippet. Matching is a literal, case-insensitive substring by default; set caseSensitive: true for exact case. Regex search is intentionally left out, because an attacker-supplied pattern can trigger catastrophic backtracking (ReDoS) that single-threaded JavaScript cannot reliably interrupt. Safe regex is planned for a later release.
"What changed between v1.pdf and v2.pdf?"
pdf_compare arguments:
{ "filePathA": "/path/to/v1.pdf", "filePathB": "/path/to/v2.pdf" }It reports a page-by-page text diff (added and removed) and sets identical: true when the text matches. The diff is text only, so purely visual changes are not detected.
Merging, splitting, reordering, and deleting pages preserve AcroForm fields. Names that collide across inputs are namespaced per source, and each tool returns { preserved, renamed, dropped }, where renamed is a list of { from, to } pairs (address a renamed field by its to name afterward). These tools and pdf_flatten also return a flattened boolean.
"Merge these three forms and flatten the result."
pdf_merge arguments:
{
"filePaths": ["/path/a.pdf", "/path/b.pdf", "/path/c.pdf"],
"outputPath": "/path/merged.pdf",
"flatten": true
}"Remove pages 2 and 5 from report.pdf."
pdf_delete_pages arguments:
{
"filePath": "/path/report.pdf",
"pages": "2,5",
"outputPath": "/path/trimmed.pdf"
}Use pdf_flatten on its own to bake an existing form's values into static content. The output path must differ from the input.
"Encrypt report.pdf with the password 'secure123'."
Encryption is AES-256. Set separate user (open) and owner (edit) passwords for granular access; the owner password defaults to the user password when omitted.
pdf_encrypt arguments:
{
"filePath": "/path/report.pdf",
"outputPath": "/path/report-encrypted.pdf",
"userPassword": "secure123",
"ownerPassword": "admin456"
}"Add a QR code linking to our website on page 1."
pdf_embed_qr_code supports QR Code, Code128, DataMatrix, EAN-13, PDF417, and Aztec. Position and size are configurable, the symbology's aspect ratio is preserved, placement is rotation-aware, and off-page placements are rejected instead of clipped.
The server ships five MCP prompts that script multi-step workflows for the client:
Prompt | Arguments | What it does |
| company_name, client_name, invoice_number, items (plus optional currency, tax_rate, due_date, company_address, client_address, payment_terms, notes) | Parses line items and builds a |
| pdf_path | Discover fields with |
| pdf_path | Try text extraction, fall back to inline |
| pdf_path | Convert to Markdown, then optionally summarize |
| pdf_paths, output_path | Merge multiple PDFs and flatten the form fields |
pdf-toolkit://templates is a JSON resource that lists the templates available to pdf_create_from_template and the fields each one accepts.
"Create a PDF from this Markdown report"
"Generate an invoice for Riverbend Outfitters, 10 hours of consulting at $150/hr"
"Merge january.pdf and february.pdf into q1-combined.pdf"
"Convert this PDF to Markdown so I can summarize it"
"Render this scanned PDF so you can read it"
"Search contract.pdf for 'termination'"
"Compare draft-v1.pdf and draft-v2.pdf"
"Fill the Name field with 'John Doe' in application.pdf"
"Add a CONFIDENTIAL watermark to draft.pdf"
"Encrypt financials.pdf with the AES-256 password 'budget2026'"
"Embed a QR code with our URL on the cover page"
"Reorder pages as 3,1,2 in report.pdf"
Coded errors. Validation and load failures throw a PdfError with a stable code, surfaced as Error [CODE]: message (for example FILE_NOT_FOUND, NOT_A_PDF, PAGE_OUT_OF_RANGE, ENCRYPTED_PDF, RESOURCE_LIMIT). Clients can branch on the code instead of parsing message text, and stack traces are never leaked.
Write-tool output. Write tools create a file at outputPath and return that path plus its size as text, since MCP has no file-content type. outputPath can name an existing file and will overwrite it, so choose a path that does not collide with something you want to keep.
JSON-safe truncation. Responses are capped at 25,000 characters. Object payloads return a valid { truncated, note, preview } envelope rather than a string cut mid-token, so a client's JSON.parse never breaks.
Merge, split, reorder, delete. Form fields are preserved, and colliding names are namespaced and reported in renamed as { from, to } pairs. Unusual forms that cannot be safely reconstructed are reported under dropped rather than failing the operation.
Text extraction. Returns PDF stream order, not visual reading order. Use pdf_to_markdown when reading order matters; raw pdf_extract_text can interleave multi-column layouts.
PDF to Markdown. Reconstructs up to two content columns (plus full-width title and footer bands); pages with three or more columns fall back to single-column reading order. It works best on clean digital PDFs. Tabular content is emitted as positioned text in reading order, not rebuilt as Markdown tables.
Markdown to PDF. Supports CommonMark and GFM (headings, bold and italic, links, lists, tables, fenced code, blockquotes, and horizontal rules). Raw HTML, task-list checkbox state, footnotes, and code syntax highlighting are not supported.
Compare. Text-only diff; visual or layout changes that do not alter text are not detected.
Image embedding. JPEG and PNG only. Off-page placements are rejected with a coded error instead of being silently clipped.
Fonts. Built-in fonts are Latin-only (WinAnsi). For non-Latin scripts such as Arabic, CJK, or Devanagari, pass a .ttf or .otf file through fontPath to pdf_fill_form or pdf_create. Markdown and template PDFs use Helvetica by default.
A multi-engine design. Every engine is pure WASM or JavaScript:
Engine | Role |
@pdfme/pdf-lib | Manipulating existing PDFs: merge, split, rotate, watermark, forms, images, QR, flatten |
@react-pdf/renderer + remark | Creating PDFs from Markdown and templates, including tables and code blocks |
unpdf (pdf.js) | Text extraction, metadata, and positional text for reading-order Markdown |
@hyzyla/pdfium (WASM) | Rendering pages to images for vision |
@neslinesli93/qpdf-wasm (WASM) | AES-256 encryption |
@bwip-js/node | QR codes and barcodes |
Node.js 20 or later. Node 18 and the 20.x line are end-of-life, so Node 22 or 24 LTS is recommended.
npm install # install dependencies
npm run build # compile TypeScript
npm test # run the vitest suite (160 tests)
npm run test:cov # tests with coverage
npm run lint # ESLint
npm run format # Prettier
npm run inspect # MCP Inspector (requires Node >= 22.7.5)See CLAUDE.md for architecture and contribution notes.
Add page numbers to a PDF. Supports configurable position, format, starting number, and font size.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| outputPath | Yes | Absolute path for the output PDF | |
| position | No | Position of page numbers. Defaults to bottom-center. | |
| format | No | Number format. Defaults to "Page X of Y". | |
| startFrom | No | Starting page number. Defaults to 1. | |
| fontSize | No | Font size for page numbers (6–24). Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds no behavioral context beyond annotations, so baseline score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, two sentences with no wasted words. The action is front-loaded and all subsequent information is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description lacks details on return values, error handling, or file constraints. It is adequate but not fully complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes all parameters. The description briefly mentions configurable attributes but does not add meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add page numbers' and identifies the resource (PDF). It lists configurable attributes, making the purpose specific. However, it does not explicitly differentiate from sibling tools like pdf_add_watermark, so a very high score is not warranted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., pdf_add_watermark) or when not to use it. The description only states what it does, not usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a text watermark to PDF pages. Watermark is centered and rotated diagonally by default. Applies to all pages if no page range is specified.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| text | Yes | Watermark text to overlay on pages | |
| outputPath | Yes | Absolute path for the watermarked output PDF | |
| pages | No | Page range, e.g. '1-5' or '1,3,5'. Omit to watermark all pages. | |
| opacity | No | Watermark opacity (0.0–1.0). Defaults to 0.3. | |
| fontSize | No | Watermark font size (10–200). Defaults to 50. | |
| color | No | Watermark color. Defaults to gray. | |
| rotation | No | Watermark rotation in degrees (0–360). Defaults to 45 (diagonal). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by specifying default positioning (centered, rotated diagonally) and page range application. Annotations are not contradicted. However, it does not detail side effects, performance, or file impact, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. It front-loads the essential action and resource, then adds key default information. Ideal structure for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 8 parameters, 100% schema coverage, and existing annotations, the description sufficiently covers default behavior and page range handling. It does not explain the output or side effects, but the output path is self-explanatory. Overall, it is complete for a watermarking tool with good schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters are fully described in the input schema (100% coverage). The description adds context about defaults and page range behavior (e.g., 'Applies to all pages if no page range is specified'), but this largely reinforces existing schema info. Thus, the description adds marginal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a text watermark') and resource ('PDF pages'), and includes default behavior (centered, rotated diagonally). It effectively communicates the tool's purpose, though it does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance, only mentioning that it applies to all pages if no page range is specified. There is no discussion of when to use this tool versus alternatives or exclusions, which is a gap for an 8-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two PDFs page by page (by absolute page index) and report text differences. Returns identical:true when text matches. Diffs content-stream-order text (not visual reading order), so it is best for same-layout documents; reflowed or multi-column PDFs produce noisy diffs. Inserting/deleting a page shifts all later pages and reports them as changed. Large diffs are trimmed (truncated:true) to fit the response limit.
| Name | Required | Description | Default |
|---|---|---|---|
| filePathA | Yes | Absolute path to the first (baseline) PDF file | |
| filePathB | Yes | Absolute path to the second (comparison) PDF file | |
| pages | No | Page range to compare, e.g. '1-5' or '1,3,5'. Defaults to all pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, destructiveHint, etc.), the description discloses that diffs are based on content-stream order, returns identical and truncated flags, and that large diffs are trimmed. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences front-load the purpose and output, then cover limitations and edge cases. Every sentence adds necessary information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a comparison tool with no output schema, the description covers purpose, output flags (identical, truncated), and key limitations. It could be more specific about the output format, but given the complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds context about 'absolute page index' and 'page by page', enhancing understanding of the pages parameter, but the schema already covers the basics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'compare', the resource 'two PDFs', and the method 'page by page by absolute page index', which distinguishes it from other PDF tools that do not perform comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that the tool is best for same-layout documents, warns about noisy diffs with reflowed or multi-column PDFs, and explains the effect of inserting/deleting pages. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new PDF from text content with automatic line wrapping and page overflow. Supports A4, Letter, and Legal page sizes. Provide fontPath for non-Latin text (Arabic, CJK, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| outputPath | Yes | Absolute path for the output PDF file | |
| content | Yes | Text content for the PDF. Use \n for line breaks. | |
| title | No | PDF document title metadata | |
| author | No | PDF document author metadata | |
| pageSize | No | Page size. Defaults to A4. | |
| fontSize | No | Font size in points (6–72). Defaults to 12. | |
| margin | No | Page margin in points (0–500). Defaults to 50. | |
| fontPath | No | Absolute path to a .ttf/.otf font file for non-Latin character support (Arabic, CJK, etc.). The built-in font is Latin-only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: automatic line wrapping, page overflow handling, and fontPath for non-Latin support. Annotations already indicate it's a write (readOnlyHint=false) and idempotent (idempotentHint=true), so the description complements well 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct, front-loaded sentences covering core function, page size support, and fontPath guidance. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main behavior and constraints. With full schema coverage and annotations, the description is sufficient for a tool of this complexity. Could mention whether outputPath overwrites existing files, but idempotentHint implies safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so each parameter is described. The description reinforces the fontPath parameter's purpose for non-Latin text but adds little new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Create a new PDF from text content' with automatic line wrapping and page overflow. Mentions supported page sizes and fontPath for non-Latin. Differentiates from siblings like pdf_create_from_markdown and pdf_create_from_template by focusing on plain text input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for plain text via 'from text content', and hints at alternatives through sibling tool names, but does not explicitly state when to use this vs others or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a rich, high-fidelity PDF from Markdown (CommonMark + GFM). Supports headings, bold/italic, links, ordered/bullet lists, tables, fenced code blocks, blockquotes, and horizontal rules.
| Name | Required | Description | Default |
|---|---|---|---|
| markdown | Yes | Markdown content to render as PDF | |
| outputPath | Yes | Absolute path for the output PDF file | |
| pageSize | No | Page size. Defaults to A4. | |
| title | No | PDF document title metadata | |
| author | No | PDF document author metadata |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true and destructiveHint=false. The description adds value by detailing supported Markdown features (CommonMark + GFM elements), which helps the agent understand output fidelity and constraints. However, it does not disclose behavior for unsupported elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by a list of supported features. It is front-loaded with the main action and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (Markdown to PDF with multiple features), the description covers the supported syntax adequately. No output schema exists, but the tool's purpose (file creation) implies a file at outputPath. Missing details on return values or error handling reduce completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description does not add further explanation beyond what the schema provides, so baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a rich, high-fidelity PDF from Markdown', specifying the verb (create), resource (PDF), and source format (Markdown). It also lists supported syntax elements, distinguishing this tool from siblings like pdf_create (generic) and pdf_create_from_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when Markdown content is available but lacks explicit guidance on when to use this tool versus alternatives (e.g., pdf_create for other inputs). No when-not-to-use or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a polished PDF from a named template (invoice, report, or letter). Pass structured data matching the template's fields; data is validated against the template's schema.
| Name | Required | Description | Default |
|---|---|---|---|
| templateName | Yes | Template to use: invoice, report, or letter | |
| data | Yes | Template data. Invoice: companyName, clientName, invoiceNumber, invoiceDate, items[{description, quantity, unitPrice}], taxRate, currency (ISO code or symbol, default USD), dueDate, notes, paymentTerms. Report: title, author, date, subtitle, sections[{heading, body}]. Letter: senderName, senderAddress, recipientName, recipientAddress, subject, body, closing, signatureName. | |
| outputPath | Yes | Absolute path for the output PDF file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that data is validated against the template's schema, a useful behavioral trait. However, with no annotations providing safety profile (all false), the description does not cover potential side effects like file overwriting, permissions, or error handling. It adds some value but lacks full transparency for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the primary action and provide essential detail on data requirements. Every word is purposeful; no redundancy or filler. The structure efficiently conveys the core function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema and explicit field lists, the description adequately prepares an agent to use the tool. The absence of an output schema is acceptable. Minor gaps like file overwrite behavior or return value are not critical, and overall the description feels complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with descriptions (100% coverage). The description goes further by enumerating the required fields for each template (invoice, report, letter), adding meaningful context beyond the schema, especially for the complex data object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a PDF from a named template (invoice, report, or letter), using a specific verb and resource. This directly distinguishes it from siblings like pdf_create or pdf_create_from_markdown, as it focuses on templates rather than blank documents or markdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a named template and matching structured data are available, but it does not explicitly state when to use this tool versus alternatives (e.g., pdf_create, pdf_fill_form). No exclusions or when-not guidance is provided, leaving the selection mostly to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specific pages from a PDF, keeping the rest in their original order. AcroForm fields on the remaining pages are preserved. Set flatten:true to bake field values into static content. Cannot delete every page.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| pages | Yes | Page range to DELETE, e.g. '2' or '1-3,5' | |
| outputPath | Yes | Absolute path for the output PDF | |
| flatten | No | Flatten the resulting form: bake field values into static content and remove interactivity. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond annotations: it states that AcroForm fields on remaining pages are preserved, explains the flatten option's effect ('bake field values into static content'), and adds the constraint 'Cannot delete every page.' This provides valuable context that annotations (which are minimal) do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each earning its place: first sentence gives purpose, second adds behavioral note on forms, third introduces flatten and constraint. It is front-loaded with the core action and contains no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, key behaviors, and constraints. It does not explicitly state that the original file is left unmodified (implied by outputPath) or error conditions. For a tool with 4 parameters and no output schema, it is largely sufficient, though a brief note on side effects could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 by explaining the flatten parameter's effect on form fields and the limitation that not all pages can be deleted. However, for filePath and outputPath, it adds nothing beyond the schema. The 'pages' parameter description in schema already includes examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete specific pages from a PDF, keeping the rest in their original order,' which is a specific verb and resource. It distinguishes from siblings like pdf_split (which splits into separate files) and pdf_reorder_pages (which changes order). The added note 'Cannot delete every page' further differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where pdf_split or pdf_reorder_pages might be more appropriate. There are no explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Embed a PNG or JPEG image into a specific page of a PDF. Supports custom positioning and optional scaling with aspect ratio preservation.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| imagePath | Yes | Absolute path to the PNG or JPEG image file | |
| page | Yes | Target page number (1-indexed) | |
| x | Yes | X position in points from the left edge of the page | |
| y | Yes | Y position in points from the bottom edge of the page | |
| width | No | Image width in points. Omit to use original width (or scale proportionally if height is set). | |
| height | No | Image height in points. Omit to use original height (or scale proportionally if width is set). | |
| outputPath | Yes | Absolute path for the output PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations providing readOnlyHint=false and destructiveHint=false, the description adds context about supporting custom positioning and scaling. However, it does not mention that the tool creates a new output file or any potential side effects like performance with large files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that effectively communicates the tool's purpose and key capabilities without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description does not need to explain return values. It adequately describes the action and key capabilities, though it could mention that the output is written to the specified outputPath.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters. The description does not add additional semantic meaning beyond what is in the schema, achieving the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it embeds PNG or JPEG images into a specific PDF page, mentioning custom positioning and scaling. This distinguishes it from sibling tools like pdf_add_watermark or pdf_embed_qr_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for embedding images but does not explicitly state when to use this tool versus alternatives like pdf_add_watermark. No guidance on 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.
Embed a QR code or barcode into a specific page of a PDF at given coordinates. Supports qrcode, code128, datamatrix, ean13, pdf417, and azteccode.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| content | Yes | Data to encode in the QR code or barcode | |
| outputPath | Yes | Absolute path for the output PDF | |
| page | Yes | Target page number (1-indexed) | |
| x | Yes | X position in points from the left edge | |
| y | Yes | Y position in points from the bottom edge | |
| size | No | Size of the QR code/barcode in points. Defaults to 100. | |
| type | No | Barcode type. Defaults to qrcode. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive behavior. The description adds context about target page and coordinates, but does not clarify output file handling (e.g., overwriting) or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the core purpose and listing supported barcode types efficiently. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not mention return value, success indication, or error cases. It provides minimal context beyond what is in the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no additional meaning beyond the schema parameter descriptions. The listed barcode types are already defined by the enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool embeds a QR code or barcode into a specific PDF page at coordinates, and lists supported formats. It is distinct from sibling tools like pdf_embed_image or pdf_add_watermark.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for embedding barcodes but does not explicitly state when to use this tool over alternatives (e.g., pdf_embed_image for images) 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.
Encrypt a PDF with AES-256 password protection. Requires a user password to open. Owner password controls editing permissions (defaults to the user password).
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| outputPath | Yes | Absolute path for the encrypted output PDF | |
| userPassword | Yes | Password required to open the PDF | |
| ownerPassword | No | Password for editing permissions. Defaults to userPassword if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, and the description adds context: it reveals AES-256 encryption, default owner password behavior, and that a user password is required. It does not contradict annotations. However, it could mention that the original file is not modified (output to separate path) or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with no redundant information. It is front-loaded with the main action and efficiently conveys key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 parameters, no output schema), the description covers the main purpose and key behavioral aspects. It lacks details about error handling, prerequisites, or side effects, but is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all parameters. The description adds extra meaning by specifying AES-256 encryption and that ownerPassword defaults to userPassword. This goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool encrypts a PDF with AES-256 password protection, specifying both user and owner password roles. It distinguishes from sibling tools like pdf_merge or pdf_split by focusing on encryption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly tell when to use or not use this tool compared to alternatives. While it implies use for password-protecting PDFs, it lacks guidance such as 'use for securing PDFs; for removing encryption, see pdf_decrypt' (not present in siblings). No alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract text content from a PDF file. Returns first 10 pages by default to avoid exceeding LLM context limits. Use the 'pages' parameter for specific pages.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the PDF file | |
| pages | No | Page range, e.g. '1-5' or '1,3,5'. Defaults to first 10 pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining the default page limit and rationale. Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is safe. The description further clarifies behavior (returns text, limited pages) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences. The first sentence states the core purpose, and the second provides essential details about defaults and parameter usage. There is no extraneous information; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of full schema coverage and annotations, the description is complete. It covers purpose, default behavior, and parameter usage. It does not specify the output format (e.g., plain text), but that is implicitly clear. For a non-complex tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are well-documented in the schema. The description reinforces the purpose but does not add new semantic meaning. It mentions the default for 'pages' which is also in the schema. Score is baseline due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Extract text content from a PDF file', which is a specific verb and resource. It distinguishes from sibling tools like pdf_add_page_numbers or pdf_merge, which have different purposes. The default behavior of returning first 10 pages is also noted, adding clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the default (first 10 pages) and how to use the 'pages' parameter for more control. It provides context about avoiding LLM context limits, but does not explicitly mention when not to use this tool or suggest alternatives. Overall, it gives clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill form fields in a PDF. Supports text, checkbox, dropdown, radio, and list-box (multi-select) fields. Provide fontPath for non-Latin text (Arabic, CJK, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the PDF file with form fields | |
| fields | Yes | Object mapping field names to values. Strings for text/dropdown/radio, booleans for checkboxes. | |
| outputPath | Yes | Absolute path for the filled output PDF | |
| flatten | No | Flatten form fields after filling (makes them non-editable). Defaults to false. | |
| fontPath | No | Absolute path to a .ttf/.otf font file for non-Latin character support. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, so the description's mention of filling fields aligns. It adds that flatten can make fields non-editable and notes font requirements for non-Latin text. However, it does not disclose behavior like overwriting existing field values or error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by key details (supported field types and font requirement). Every sentence is essential; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, complete schema coverage, and no output schema, the description adequately covers key aspects: supported field types, required font for non-Latin text, and flatten effect (via parameter). Missing: output path requirements or error scenarios, but schema covers the former.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds that field values can be strings or booleans (matching schema) and mentions list-box multi-select fields (not fully captured in schema type constraints). Does not explain parameters like outputPath or flatten beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fill form fields in a PDF') and specifies supported field types (text, checkbox, dropdown, radio, list-box). It distinguishes itself from sibling tools like pdf_get_form_fields (which reads fields) and pdf_flatten (which only flattens without filling).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It implies usage for filling forms but does not mention prerequisites (e.g., the PDF must have form fields) or when not to use it (e.g., for flattening alone, use pdf_flatten). No comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flatten a PDF's form fields, baking their current values into the page content and removing interactivity. Form-less PDFs are copied unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| outputPath | Yes | Absolute path for the flattened output PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description builds on this by detailing that the tool bakes current values, removes interactivity, and copies form-less PDFs unchanged. This adds concrete behavioral context without contradicting annotations. However, it does not disclose potential permissions or error handling, preventing a top score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences precisely covering the core operation and an edge case. Every sentence adds value with no redundancy, making it ideal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required params, no output schema, no nested objects), the description sufficiently covers the main effect and a key edge case. It does not describe return values or error conditions, but for this simple tool, the provided information is largely adequate. The presence of many siblings suggests a need for more differentiation, but the purpose clarity already helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both filePath and outputPath having clear descriptions in the schema. The tool description adds no additional parameter-level meaning beyond the schema, so a baseline score of 3 is appropriate as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Flatten a PDF's form fields, baking their current values into the page content and removing interactivity.' It uses a specific verb 'flatten' and resource 'PDF's form fields', clearly distinguishing from sibling tools that handle forms differently (e.g., pdf_fill_form fills but may keep interactivity). The added note about form-less PDFs being copied unchanged further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's effect but does not provide explicit guidance on when to use it versus alternatives like pdf_fill_form or pdf_get_form_fields. Given the large set of sibling tools, this omission leaves the agent to infer the appropriate context, resulting in a baseline score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all form fields in a PDF with their names, types, current values, and required status. Returns hasForm: false for PDFs without forms.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the PDF file |
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 behavior for PDFs without forms ('Returns hasForm: false'), which is not in annotations. This provides useful context beyond safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first sentence front-loads the primary action and return details. Every word adds value, and the description is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 output schema) and supportive annotations, the description covers the essential behavior. It explains the return for PDFs without forms. However, it omits potential error cases or file validation, which might be needed for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (filePath described with maxLength). The description adds no additional parameter semantics; it does not mention file path format, file existence requirements, or error handling. Baseline score of 3 is appropriate since schema already covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'form fields in a PDF', and specifies the returned data (names, types, current values, required status). It also mentions a special return case for PDFs without forms, which distinguishes it from sibling tools like pdf_fill_form or pdf_flatten.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool. The description implies usage for inspecting form fields, but does not reference alternatives or prerequisites. Minimal guidance for an agent to decide between this and other PDF tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata from a PDF file including title, author, subject, page count, creation/modification dates, and producer information.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the PDF file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's behavioral burden is lower. It adds value by listing the specific metadata fields returned (title, author, etc.). This goes beyond annotations by specifying output content, which helps the agent understand what to expect. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the action and lists the metadata. Every word earns its place. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, clear annotations, and no output schema, the description is fairly complete. It lists the metadata fields returned. However, it could be slightly improved by noting that the tool does not modify the file (already implied by annotations) or handling missing files (but not required). Overall, sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter 'filePath' is 100%, with a clear schema description: 'Absolute path to the PDF file'. The tool description does not add any additional meaning or constraints beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving metadata from a PDF file, and explicitly lists the specific fields (title, author, subject, page count, dates, producer). This is a specific verb+resource combination that distinguishes it from sibling tools like pdf_extract_text or pdf_get_form_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for read-only metadata retrieval, but does not specify when not to use it (e.g., for text extraction) or mention alternative tools. The sibling tool list provides context but no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge multiple PDF files into one. AcroForm fields are preserved; fields whose names collide across inputs are auto-renamed (namespaced by source). Set flatten:true to bake field values into static content.
| Name | Required | Description | Default |
|---|---|---|---|
| filePaths | Yes | Array of absolute paths to PDF files to merge, in order | |
| outputPath | Yes | Absolute path for the merged output PDF | |
| flatten | No | Flatten the merged form: bake field values into static content and remove interactivity. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies that AcroForm fields are preserved and auto-renamed on collision, and describes the flatten option effect. Annotations indicate idempotentHint true, which is consistent, but the description provides non-obvious details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly states the main purpose, and front-loads the essential behavior. Every sentence adds value without unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema coverage, and no output schema, the description sufficiently covers key behaviors (form field handling, flattening). It provides enough context for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the description adds little new meaning. It repeats the flatten behavior but does not enhance understanding of filePaths or outputPath beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: merging multiple PDF files into one. It uses specific verbs and resources, and the behavior (preserving AcroForm fields, flatten option) distinguishes it from sibling tools like pdf_split or pdf_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool (merging, preserving AcroForm, flatten option) but does not provide explicit guidance on when to use this tool versus alternatives. It lacks comparisons to siblings like pdf_add_page_numbers or pdf_fill_form.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render PDF pages to images so a vision-capable client can read scanned or image-only PDFs. Writes PNG/JPEG files and returns their paths; set inline:true to return image blocks the model can see directly.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| pages | No | Page range to render, e.g. '1-5,8'. Defaults to the first 50 pages. | |
| dpi | No | Render resolution in DPI (36–300). Defaults to 150. | |
| format | No | Output image format. Defaults to png. | |
| inline | No | Return rendered pages as inline image blocks the model can see directly instead of writing files. Max 5 pages; DPI is auto-capped so neither dimension exceeds 1500px. Defaults to false. | |
| outputDir | No | Directory for the output images: an absolute path is recommended; a relative path resolves against the server working directory. The directory must already exist. Defaults to the input PDF's directory. Ignored when inline is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, readOnlyHint=false), the description discloses that the tool writes files and returns paths, and explains inline behavior with max pages and DPI cap. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover the main purpose and a key option (inline). No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and a major variant (inline). It lacks details on return format for non-inline, error conditions, or file naming, but for a rendering tool with good annotations and schema, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds only marginal value for the inline parameter (max pages, DPI cap). The baseline of 3 is appropriate since the schema already documents all parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders PDF pages to images for vision-capable clients, specifying the use case (scanned or image-only PDFs). The verb 'render' and resource 'PDF pages to images' are specific, and the purpose is distinct from sibling tools like pdf_extract_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool ('so a vision-capable client can read scanned or image-only PDFs') and mentions the inline option. However, it does not explicitly exclude scenarios or suggest alternatives among the listed sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reorder pages in a PDF. Specify the new page order as a comma-separated string (e.g. '3,1,2'). Duplicates are allowed. AcroForm fields are preserved. Set flatten:true to bake field values into static content.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| pageOrder | Yes | New page order as comma-separated 1-indexed numbers, e.g. '3,1,2,4' or '1,1,2' (duplicates allowed; up to 2000 pages) | |
| outputPath | Yes | Absolute path for the reordered output PDF | |
| flatten | No | Flatten the reordered form: bake field values into static content and remove interactivity. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations, such as allowing duplicates, preserving AcroForm fields, and explaining the flatten option. This helps the agent understand side effects and capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and provides necessary details without superfluous text. It is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: reordering action, page order format, duplicate allowance, AcroForm preservation, and flatten option. However, it does not explicitly state that the original file is left unchanged, which could be inferred from the output path requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add significant parameter information beyond what the input schema already provides, which includes detailed descriptions for each parameter including format and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reorder pages in a PDF' and provides explicit details about the page order format, distinguishing it from sibling tools like rotate or delete pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly compare to sibling tools or state when to use this tool over others. It implies usage through its purpose statement but lacks guidance on alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rotate pages in a PDF by 90, 180, or 270 degrees. Rotation is additive to any existing rotation. Rotates all pages if no page range is specified.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| pages | No | Page range to rotate, e.g. '1-5' or '1,3,5'. Omit to rotate all pages. | |
| degrees | Yes | Rotation angle: 90, 180, or 270 degrees clockwise | |
| outputPath | Yes | Absolute path for the rotated output PDF |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description correctly states rotation is additive, but annotations claim idempotentHint=true, which is contradictory. Multiple identical calls would produce different results due to additivity, violating idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First covers purpose and key behavior, second covers default. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior, default, and additive nature. Missing potential error conditions or output path considerations, but adequate for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions. Description adds context about additive rotation and default page behavior, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'rotate' and specific resource 'pages in a PDF' with angles. Differentiates well from sibling tools like delete, reorder, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States default behavior when no page range is specified. Lacks explicit when-not-to-use guidance 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.
Search text across a PDF and return matches with a short surrounding snippet and the page number. The query is matched as a literal substring (case-insensitive by default). Searches all pages unless a range is given.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the PDF file | |
| query | Yes | Literal text to find (matched as a substring) | |
| caseSensitive | No | Match case exactly. Defaults to false. | |
| pages | No | Page range, e.g. '1-5'. Defaults to all pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by revealing search behavior: literal substring matching, default case-insensitivity, and return format (snippet and page number). Annotations already indicate safe, read-only, idempotent operation, and the description complements this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the main action and key behaviors. Every sentence adds value, no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's functionality for a simple search operation with 4 parameters. It lacks detail on snippet length or formatting, but given the straightforward nature, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description reiterates parameter details (case-insensitive default, page range). However, it adds context about return values (snippet and page number), which is not in the schema, enhancing understanding despite no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and resource 'PDF', specifying that it returns matches with a snippet and page number. It distinguishes from siblings like pdf_extract_text (which extracts all text) and pdf_to_markdown (which converts format), focusing on targeted search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding specific text in a PDF, including case-insensitivity and page range, but does not explicitly state when to avoid this tool or mention alternatives like pdf_extract_text for extracting all text. The guidance is clear but lacks exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract specific pages from a PDF into a new file. AcroForm fields on the extracted pages are preserved; fields on omitted pages are dropped. Set flatten:true to bake field values into static content.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the source PDF file | |
| pages | Yes | Page range to extract, e.g. '1-5' or '1,3,5' | |
| outputPath | Yes | Absolute path for the output PDF | |
| flatten | No | Flatten the extracted form: bake field values into static content and remove interactivity. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains how AcroForm fields are handled on extracted vs omitted pages and describes the flatten parameter's effect. Annotations only provide idempotentHint, so this info fills gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose. Every word adds value, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: purpose, form behavior, and flatten option. Could mention that the original file is unchanged, but overall sufficient for a tool with moderate complexity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description goes further by explaining the flatten parameter's impact on form fields, adding nuance not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts specific pages into a new PDF, using a specific verb and resource. While it doesn't explicitly distinguish from siblings like pdf_delete_pages, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as pdf_delete_pages or pdf_merge. The description only states what it does, not the context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a PDF to clean, reading-order Markdown for LLM consumption: reconstructs up to 2 content columns (plus full-width title/footer bands), infers headings from font size, and detects bullet/numbered lists. Pages with 3 or more columns fall back to single-column reading order. Tables are emitted as plain reading-order text, NOT reconstructed as Markdown tables. Best on clean, digital (text-based) PDFs; degrades on scanned/image-only PDFs (use pdf_render_pages for those) and very complex layouts. Returns the first 10 pages by default.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the PDF file | |
| pages | No | Page range, e.g. '1-5' or '1,3,5'. Defaults to first 10 pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, destructiveHint, idempotentHint. Description adds details on column reconstruction, heading inference, list detection, table treatment, and page defaults. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single well-structured paragraph front-loading purpose, then details, then limitations. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers most aspects: output format (Markdown), page handling, limitations. Could be more explicit about return type (e.g., string), but good for a tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context: page range format examples and default behavior (first 10 pages). FilePath requirement is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts PDF to Markdown for LLMs, with specific details on column handling, heading inference, list detection, and table behavior. It distinguishes from sibling tools like pdf_render_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states best use case (clean digital PDFs), warns about scanned PDFs and complex layouts, and recommends pdf_render_pages as alternative for scanned PDFs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose, targeting different PDF operations (creation, manipulation, extraction, forms, etc.). Overlaps like multiple creation tools are differentiated by input format (text, markdown, template), so no ambiguity exists.
All tools follow a consistent 'pdf_verb_noun' pattern in snake_case (e.g., pdf_add_page_numbers, pdf_extract_text). The naming is predictable and each verb clearly indicates the action.
With 22 tools, the set covers a broad range of PDF operations without being excessive. Each tool addresses a specific need, and the count is well-suited for a comprehensive PDF toolkit.
The toolkit covers creation, manipulation, extraction, forms, search, comparison, and encryption. Minor gaps exist (e.g., no tool to update metadata, remove encryption, or compress), but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Privacy-first PDF tools over MCP: merge, split, rotate, delete, compress, protect, inspect.
MCP server for Api2Pdf — generate PDFs & images from HTML, URLs or office files; merge, barcodes.
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
Generate PDFs from templates via AI chat. Works with Claude, ChatGPT, Cursor, and any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AryanBV/pdf-toolkit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
