Skip to main content
Glama
GleidsonFerSanP

PDF Utilities MCP

by GleidsonFerSanP
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

PDF Utilities MCP

A VS Code extension that provides comprehensive PDF manipulation tools for GitHub Copilot Chat via Model Context Protocol (MCP).

Overview

This project combines an MCP server with a VS Code extension to enable AI assistants like GitHub Copilot to work with PDF files through natural language commands. Users can read, create, merge, split, and edit PDFs directly from their chat interface.

Related MCP server: PDF MCP Server

Architecture

pdf-utilities-mcp/
├── src/                   # MCP Server implementation
│   ├── index.ts          # Server entry point and tool registration
│   └── pdf-tools.ts      # PDF manipulation utilities
├── extension/            # VS Code Extension
│   ├── src/
│   │   ├── extension.ts # Extension activation and MCP integration
│   │   └── types.ts     # TypeScript type definitions
│   ├── resources/
│   │   └── instructions/ # Copilot Chat instruction files
│   └── mcp-server/      # Built MCP server (copied from ../dist)
└── dist/                # Compiled MCP server output

Features

  • 📖 Read PDFs: Extract text content with optional page range selection

  • 📊 Get Info: Retrieve metadata (pages, title, author, size, etc.)

  • ✍️ Create PDFs: Generate new PDFs from text with formatting options

  • 🔗 Merge: Combine multiple PDF files into one

  • ✂️ Split: Extract specific pages or ranges

  • 📝 Update Metadata: Modify title, author, subject, keywords

  • 📄 Extract Pages: Save individual pages as separate files

Installation

For Users

Install from VS Code Marketplace:

  1. Open VS Code

  2. Search for "PDF Utilities" in Extensions

  3. Click Install

For Developers

# Clone the repository
git clone https://github.com/GleidsonFerSanP/pdf-utilities-mcp.git
cd pdf-utilities-mcp

# Install MCP server dependencies
npm install

# Build MCP server
npm run build

# Install extension dependencies
cd extension
npm install

# Build extension
npm run compile

# Copy MCP server to extension
cd ..
npm run copy-to-extension

Development

Project Structure

MCP Server ( src/ ):

  • Uses @modelcontextprotocol/sdk for standardized tool interface

  • Implements 7 PDF tools using pdf-lib and pdf-parse

  • Runs as Node.js process via stdio transport

VS Code Extension ( extension/ ):

  • Registers MCP server with VS Code's lm.registerMcpServerDefinitionProvider

  • Provides commands for configuration and server management

  • Includes chat instructions for optimal Copilot integration

Building

# Build MCP server
npm run build

# Build extension
cd extension
npm run compile

# Copy server to extension folder
cd ..
npm run copy-to-extension

Testing

# Test MCP server directly
node dist/index.js

# Package extension for testing
cd extension
npm run package  # Creates .vsix file

# Install .vsix in VS Code for testing
# Extensions > ... > Install from VSIX

Development Workflow

  1. Make changes to MCP server in src/

  2. Run npm run build to compile

  3. Run npm run copy-to-extension to update extension

  4. Reload VS Code window to test changes

  5. Check logs in Output panel > "PDF Utilities"

Publishing

Prerequisites

  1. Create VS Code Publisher account at https://marketplace.visualstudio.com/

  2. Generate Personal Access Token (PAT)

  3. Update extension/.env with your PAT

Publish Steps

# Build everything
npm run build
cd extension
npm run compile
cd ..
npm run copy-to-extension

# Package extension
cd extension
npm run package

# Verify the .vsix file works
# Install it manually in VS Code and test

# Publish to marketplace
npm run publish

Version Management

Update version in both:

  • package.json (root)

  • extension/package.json

Follow semantic versioning: MAJOR. MINOR. PATCH

Configuration

Extension Settings

  • pdfUtilities.autoStart: Auto-start MCP server (default: true)

  • pdfUtilities.logLevel: Logging verbosity (default: info)

  • pdfUtilities.maxPdfSize: Maximum file size in MB (default: 50)

MCP Server Configuration

The MCP server is configured via the extension and doesn't require separate configuration.

API Documentation

Tool: read_pdf

Extract text from PDF file.

Parameters:

  • filePath (string, required): Absolute path to PDF

  • pageRange (string, optional): Pages to extract (e.g., "1-5", "1, 3, 5-10")

Returns:

{
  text: string;
  pages: number;
  info: PDFInfo;
}

Tool: get_pdf_info

Get PDF metadata and information.

Parameters:

  • filePath (string, required): Absolute path to PDF

Returns:

{
  pages: number;
  title?: string;
  author?: string;
  subject?: string;
  creator?: string;
  producer?: string;
  creationDate?: Date;
  modificationDate?: Date;
  fileSize: number;
  filePath: string;
}

Tool: create_pdf

Create new PDF from text content.

Parameters:

  • content (string, required): Text content

  • outputPath (string, required): Save location

  • options (object, optional): Formatting options

    • title, author, subject (string): Metadata

    • fontSize (number): Text size (default: 12)

    • pageSize (string): Page size (default: "A4")

Returns:

{
  success: boolean;
  path: string;
  pages: number;
}

Tool: merge_pdfs

Combine multiple PDFs.

Parameters:

  • filePaths (string[], required): PDFs to merge

  • outputPath (string, required): Output location

Returns:

{
  success: boolean;
  path: string;
  pages: number;
}

Tool: split_pdf

Extract pages to new PDF.

Parameters:

  • filePath (string, required): Source PDF

  • pageRange (string, required): Pages to extract

  • outputPath (string, required): Output location

Returns:

{
  success: boolean;
  path: string;
  pages: number;
}

Tool: update_pdf_metadata

Modify PDF metadata.

Parameters:

  • filePath (string, required): PDF to update

  • metadata (object, required): Fields to update

    • title, author, subject, keywords (string)

  • outputPath (string, optional): Save location (defaults to overwrite)

Returns:

{
  success: boolean;
  path: string;
}

Tool: extract_pages

Extract pages to separate files.

Parameters:

  • filePath (string, required): Source PDF

  • pages (number[], required): Page numbers to extract

  • outputDir (string, required): Output directory

  • prefix (string, optional): Filename prefix (default: "page")

Returns:

{
  success: boolean;
  files: string[];
}

Troubleshooting

MCP Server Not Starting

Check Output panel:

View > Output > Select "PDF Utilities"

Look for initialization messages. If server fails:

  1. Verify mcp-server/index.js exists in extension folder

  2. Run rebuild: npm run build && npm run copy-to-extension

  3. Reload VS Code

Tools Not Available in Copilot

  1. Ensure extension is activated (check Extensions panel)

  2. Verify MCP API is available (requires VS Code 1.85+)

  3. Check that Copilot Chat is enabled

  4. Restart Copilot: Command Palette > "GitHub Copilot: Restart Language Server"

Build Errors

Common issues:

  • TypeScript errors: Run npm install in both root and extension folders

  • Missing dependencies: npm install in correct directory

  • Path issues: Use npm run copy-to-extension to sync files

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if applicable

  5. Submit a pull request

Please follow existing code style and conventions.

License

MIT License - see LICENSE file for details.

Support

Credits

Note: This project requires GitHub Copilot Chat and VS Code 1.85+ with MCP support.

Available Tools

7 tools
create_pdfB

Create a new PDF from text content with optional formatting and metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesText content to include in the PDF
outputPathYesAbsolute path where the PDF will be saved
optionsNoOptional formatting and metadata options

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided, so the description must disclose behavioral details. It does not mention what happens if output path exists, side effects, or any constraints. 'Create' implies writing but lacks depth.

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

Conciseness5/5

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

Single sentence, 13 words, directly states action and scope. No fluff.

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

Completeness2/5

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

For a tool with a nested options object and no output schema or annotations, the description is too minimal. Missing details about output behavior, overwrite policy, and formatting capabilities.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal value beyond schema, just rephrasing 'text content' and noting optional features. No new semantic insight.

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

Purpose5/5

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

The description clearly states it creates a PDF from text content with optional formatting and metadata. This verb-resource combination is distinct from sibling tools that extract, merge, split, read, or update PDFs.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, such as when to use merge_pdfs or update_pdf_metadata. No mention of prerequisites or limitations.

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

extract_pagesB

Extract specific pages from a PDF into separate PDF files.

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesAbsolute path to the source PDF file
pagesYesArray of page numbers to extract (1-based)
outputDirYesDirectory where extracted pages will be saved
prefixNoOptional filename prefix for extracted pages (default: "page")

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided, and the description does not disclose whether the original file is modified, permissions needed, or behavior on errors; minimal disclosure for a tool that writes new files.

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

Conciseness5/5

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

Extremely concise single sentence, front-loaded with the core purpose, no redundant words.

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

Completeness2/5

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

Missing details on output file naming (e.g., prefix usage), handling of invalid page numbers, and any side effects; incomplete for a tool with 4 parameters and no output schema.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3; the description adds no extra meaning beyond the schema for any parameter.

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

Purpose5/5

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

The description clearly states the verb 'Extract', the resource 'specific pages from a PDF', and the outcome 'separate PDF files', distinguishing it from siblings like merge_pdfs or split_pdf.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives such as split_pdf or read_pdf; no exclusions or prerequisites mentioned.

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

get_pdf_infoB

Get metadata and information about a PDF file (pages, title, author, size, etc.).

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesAbsolute path to the PDF file

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool retrieves metadata, lacking details on error handling, permissions, or performance implications. This is insufficient for an informed agent.

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

Conciseness5/5

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

The description is a single sentence that efficiently conveys the tool's purpose and includes key examples. No unnecessary words or repetition.

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

Completeness4/5

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

Given the tool's simplicity (one parameter, no output schema), the description covers the core functionality and expected return values (pages, title, author, size). Minor gaps exist, such as lack of error conditions or format details, but these are not critical for a straightforward metadata retrieval tool.

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

Parameters3/5

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

Schema coverage is 100% (the single parameter 'filePath' is described as 'Absolute path to the PDF file'). The description does not add additional meaning beyond the schema, meeting the baseline expectation.

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

Purpose5/5

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

The description clearly states the verb 'Get' and the resource 'metadata and information about a PDF file', listing specific examples (pages, title, author, size). It sufficiently distinguishes from sibling tools like create_pdf or read_pdf, which serve different purposes.

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It simply describes what it does, 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.

merge_pdfsB

Merge multiple PDF files into a single PDF.

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathsYesArray of absolute paths to PDF files to merge
outputPathYesAbsolute path where the merged PDF will be saved

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as whether the output file is overwritten, file size limits, or required permissions. As a mutating operation that creates a new file, more transparency is needed.

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

Conciseness5/5

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

The description is a single, clear sentence with no unnecessary words. It is perfectly concise and front-loaded with the key action and outcome.

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

Completeness3/5

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

For a simple tool with two well-documented parameters and no output schema, the description is minimally adequate. However, it lacks details about the merge order, overwrite behavior, and return value, which could aid an AI agent.

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

Parameters3/5

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

Schema description coverage is 100%, with both parameters ('filePaths' and 'outputPath') clearly described in the input schema. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

Purpose5/5

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

The description 'Merge multiple PDF files into a single PDF' clearly states the action (merge) and the resource (multiple PDF files into one). It effectively distinguishes from sibling tools like split_pdf, extract_pages, and create_pdf.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, no mention of prerequisites or scenarios where merging is appropriate or inappropriate. The description is too minimal to provide usage context.

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

read_pdfA

Extract text content from a PDF file. Optionally specify page range (e.g., "1-5" or "1,3,5").

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesAbsolute path to the PDF file
pageRangeNoOptional page range (e.g., "1-5", "1,3,5-10")

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only mentions text extraction and optional page range, but omits important details like handling of scanned documents, encrypted files, file not found errors, or output format. This is insufficient for a read operation with no annotations.

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

Conciseness5/5

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

Two concise sentences: first states the core purpose, second adds the optional page range. No redundant words, information is front-loaded and easy to parse.

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

Completeness3/5

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

Given the lack of output schema, the description should clarify return value format (e.g., plain text) and behavior for invalid input (e.g., non-existent file). It is adequate for simple use but misses details that could prevent agent errors.

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

Parameters3/5

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

Schema coverage is 100% with detailed parameter descriptions. The description's mention of page range restates the schema's example without adding new meaning. Since the schema already handles semantics, the description adds minimal value, earning a baseline 3.

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

Purpose5/5

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

The description clearly states 'Extract text content from a PDF file', identifying the verb 'extract' and resource 'text content'. This distinguishes it from sibling tools that create, merge, split, or update PDFs.

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

Usage Guidelines4/5

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

The description indicates optional page range usage, which helps the agent decide to provide a range. Although it doesn't explicitly state when not to use or list alternatives, the sibling tools cover different operations, making the intended use obvious.

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

split_pdfC

Extract specific pages from a PDF into a new file.

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesAbsolute path to the source PDF file
pageRangeYesPage range to extract (e.g., "1-5", "2,4,6-10")
outputPathYesAbsolute path where the extracted PDF will be saved

TDQS

C2.8/5.0
Behavior2/5

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

No annotations provided, and the description lacks details on behavioral traits such as whether the source file is modified, error handling, or overwrite policy. The description is too brief to convey important behavioral information.

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

Conciseness3/5

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

Description is a single sentence, which is concise but lacks structure. It does not front-load key details or use formatting to enhance readability.

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

Completeness2/5

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

Given the tool has no output schema and no annotations, the description should provide more context about return values, side effects, and edge cases. It fails to do so, leaving gaps for an AI agent.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents parameters well. The description adds no additional semantic value beyond what is in the schema.

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

Purpose4/5

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

Description clearly states the action (extract) and resource (PDF pages) and outcome (into a new file). However, it does not differentiate from the sibling tool 'extract_pages', which could cause confusion.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'extract_pages'. No context on prerequisites or preferred scenarios.

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

update_pdf_metadataB

Update metadata (title, author, subject, keywords) of a PDF file.

ParametersJSON Schema
NameRequiredDescriptionDefault
filePathYesAbsolute path to the PDF file
metadataYesMetadata fields to update
outputPathNoOptional output path (defaults to overwriting original)

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description must fully convey behavioral traits. It only says 'update metadata' but does not disclose that the file is overwritten by default (though the outputPath schema parameter mentions this), nor does it mention permissions, side effects, or error scenarios.

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

Conciseness5/5

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

The description is a single sentence with no filler, directly conveying the core purpose and scope. Every word earns its place.

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

Completeness3/5

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

Given the simple operation (updating metadata) and rich schema, the description is adequate but lacks usage context and behavioral details that would help an agent decide when to invoke it. It meets the minimum viable standard.

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

Parameters3/5

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

Schema coverage is 100% with clear parameter descriptions. The main description mentions the metadata fields but adds little beyond the schema. The outputPath default behavior is already in the schema, so the description provides minimal additional value.

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

Purpose5/5

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

The description clearly states the verb 'update', the resource 'PDF file metadata', and lists the specific fields (title, author, subject, keywords). It is distinct from sibling tools like create_pdf, extract_pages, or split_pdf, which perform different operations.

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

Usage Guidelines2/5

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, no prerequisites, and no exclusions. It merely states what the tool does without context.

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

Tool Schema Changelog

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

  1. 7 tool updatesv1.0.0
    • First observedcreate_pdf
    • First observedextract_pages
    • First observedget_pdf_info
    • First observedmerge_pdfs
    • First observedread_pdf
    • First observedsplit_pdf
    • First observedupdate_pdf_metadata
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 7 tools

Disambiguation3/5

Most tools are distinct, but extract_pages and split_pdf have overlapping functionality; both extract specific pages, differing only in output format (separate files vs. single file). This could confuse an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_pdf, merge_pdfs, read_pdf), making them predictable and easy to learn.

Tool Count5/5

With 7 tools, the server is well-scoped for a PDF utility; each tool serves a distinct core operation without being too few or too many.

Completeness3/5

Core operations (create, read, merge, split, metadata) are covered, but common features like content editing (delete/rotate pages) or format conversion are missing, and the extract/split tools seem redundant.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers