Skip to main content
Glama
mcp-z

MCP PDF

by mcp-z
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

@mcp-z/mcp-pdf

MCP server for creative PDF generation with full emoji, Unicode, and offline support

Common uses

  • Generate PDFs from text or layouts

  • Render PDF pages as images

  • Measure text before layout

Related MCP server: Yakpdf MCP Server

Transports

MCP supports stdio and HTTP.

Stdio

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

HTTP

{
  "mcpServers": {
    "pdf": {
      "type": "http",
      "url": "http://localhost:9010/mcp",
      "start": {
        "command": "npx",
        "args": ["-y", "@mcp-z/mcp-pdf", "--port=9010"]
      }
    }
  }
}

start is an extension used by npx @mcp-z/cli up to launch HTTP servers for you.

Authentication

No OAuth or API keys required.

How to use

# List tools
mcp-z inspect --servers pdf --tools

# Create a simple PDF
mcp-z call pdf pdf-document '{"content":["Hello from MCP"]}'

Available tools

pdf-resume

Generate professional resumes from JSON Resume format.

Parameters:

  • filename (string, optional) - Filename for the PDF (defaults to "resume.pdf")

  • resume (object, required) - JSON Resume schema

  • sections (object, optional) - Section ordering and field templates

  • layout (object, optional) - Spatial arrangement (single-column or two-column)

  • styling (object, optional) - Typography and spacing options

  • font (string, optional) - Custom font

  • pageSize (string, optional) - Page size (default: "LETTER")

  • backgroundColor (string, optional) - Page background color

Resume schema sections:

  • basics - Name, contact, summary, location

  • work - Work experience with highlights

  • education - Degrees and institutions

  • projects - Personal/professional projects

  • skills - Skills grouped by category

  • awards, certificates, languages, volunteer, publications, interests, references

Section configuration

Control which sections appear and in what order using sections.sections:

await client.callTool('pdf-resume', {
  resume: { /* JSON Resume data */ },
  sections: {
    sections: [
      { source: 'basics', render: 'header' },
      { source: 'basics.summary', title: 'Summary' },
      { source: 'work', title: 'Experience' },
      { source: 'skills', title: 'Skills' },
      { source: 'education', title: 'Education' }
    ]
  }
});

Section config properties:

  • source (string, required) - Path to data in resume schema (e.g., basics, work, meta.customField)

  • render (string, optional) - Built-in renderer. Use header explicitly or to force a renderer

  • title (string, optional) - Section heading (omit for no title)

  • template (string, optional) - LiquidJS template for custom rendering

Available renderers:

  • header - Name + contact line from basics (never auto-inferred)

  • entry-list - Arrays with position/institution/organization

  • keyword-list - Arrays with keywords

  • language-list - Arrays with language

  • credential-list - Arrays with awarder/issuer/publisher

  • reference-list - Arrays with reference

  • text - String or string array

Example: custom section order with meta fields

await client.callTool('pdf-resume', {
  resume: {
    basics: { name: 'Jane Doe', email: 'jane@example.com' },
    work: [{ /* ... */ }],
    meta: { valueProp: 'Full-stack engineer with 10+ years experience...' }
  },
  sections: {
    sections: [
      { source: 'basics', render: 'header' },
      { source: 'meta.valueProp', title: 'Value Proposition' },
      { source: 'work', title: 'Experience' }
    ]
  }
});

Field templates

Field templates use LiquidJS syntax to customize how fields are rendered.

Available field templates:

  • location - {{ city }}{% if region %}, {{ region }}{% endif %}

  • dateRange - {{ start | date: 'MMM YYYY' }} - {{ end | date: 'MMM YYYY' | default: 'Present' }}

  • degree - {{ studyType }}{% if area %}, {{ area }}{% endif %}

  • credential - {{ title | default: name }}{% if awarder %}, {{ awarder }}{% endif %}

  • language - {{ language }}{% if fluency %} ({{ fluency }}){% endif %}

  • skill - {{ name }}: {{ keywords | join: ', ' }}

  • contactLine - {{ items | join: ' | ' }}

Date format tokens:

  • YYYY, YY, MMMM, MMM, MM, M, DD, D

Available filters:

  • date - Format a date string

  • default - Fallback for empty values

  • tenure - Calculate duration

  • join - Join array elements

Example: French resume

await client.callTool('pdf-resume', {
  filename: 'cv-francais.pdf',
  resume: { /* JSON Resume data */ },
  sections: {
    fieldTemplates: {
      dateRange: "{{ start | date: 'MM/YYYY' }} - {{ end | date: 'MM/YYYY' | default: 'Present' }}",
      location: '{{ city }}'
    }
  }
});

Example: verbose date format

await client.callTool('pdf-resume', {
  filename: 'resume.pdf',
  resume: { /* JSON Resume data */ },
  sections: {
    fieldTemplates: {
      dateRange: "{{ start | date: 'MMMM YYYY' }} to {{ end | date: 'MMMM YYYY' | default: 'Present' }}"
    }
  }
});

Two-column resume layout

await client.callTool('pdf-resume', {
  filename: 'two-column-resume.pdf',
  resume: {
    basics: {
      name: 'Jane Doe',
      label: 'Product Designer',
      email: 'jane@example.com'
    },
    work: [{
      name: 'Design Studio',
      position: 'Lead Designer',
      startDate: '2019-03',
      highlights: ['Redesigned product UI', 'Increased conversion by 25%']
    }],
    skills: [
      { name: 'Design', keywords: ['Figma', 'Sketch', 'Adobe XD'] },
      { name: 'Frontend', keywords: ['HTML', 'CSS', 'React'] }
    ],
    languages: [
      { language: 'English', fluency: 'Native' },
      { language: 'Spanish', fluency: 'Intermediate' }
    ]
  },
  layout: {
    style: 'two-column',
    gap: 30,
    columns: {
      left: { width: '30%', sections: ['skills', 'languages'] },
      right: { width: '70%', sections: ['work'] }
    }
  }
});

Layout options:

  • style - "single-column" (default) or "two-column"

  • gap - Space between columns in points (default: 30)

  • columns.left.width - Left column width (percentage or points)

  • columns.left.sections - Section source paths for left column

  • columns.right.width - Right column width

  • columns.right.sections - Section source paths for right column

pdf-layout

Create a PDF with precise positioning and Yoga flexbox layout.

Parameters:

  • filename (string, optional) - Filename for the PDF (defaults to "document.pdf")

  • title (string, optional) - Document metadata

  • author (string, optional) - Document metadata

  • pageSetup (object, optional) - Page configuration

  • content (array, required) - Content items

  • layout (object, optional) - Layout options

Page setup:

pageSetup: {
  size: [612, 792],
  margins: { top: 72, bottom: 72, left: 72, right: 72 },
  backgroundColor: '#FFFFFF'
}

Content types:

Text and headings:

{
  type: 'text',
  text: 'Content here',
  fontSize: 12,
  bold: true,
  color: '#000000',
  align: 'left',
  x: 100,
  y: 200,
  oblique: 15,
  characterSpacing: 1,
  moveDown: 1,
  underline: true,
  strike: true
}

Shapes:

{ type: 'rect', x: 50, y: 50, width: 200, height: 100, fillColor: '#FF0000', strokeColor: '#000000', lineWidth: 2 }
{ type: 'circle', x: 300, y: 400, radius: 50, fillColor: '#00FF00', strokeColor: '#000000', lineWidth: 1 }
{ type: 'line', x1: 100, y1: 100, x2: 500, y2: 100, strokeColor: '#0000FF', lineWidth: 2 }

Images and pages:

{ type: 'image', imagePath: '/path/to/image.png', width: 200, height: 150, x: 100, y: 200 }
{ type: 'pageBreak' }

Flexbox layout engine

Use type: 'group' to create flexbox containers:

{
  type: 'group',
  direction: 'row',
  gap: 20,
  flex: 1,
  justify: 'center',
  alignItems: 'center',
  align: 'center',
  width: 300,
  height: 200,
  padding: 15,
  background: '#f5f5f5',
  border: { color: '#333', width: 1 },
  children: [
    { type: 'text', text: 'Child 1' },
    { type: 'text', text: 'Child 2' }
  ]
}

Common layout patterns:

Two equal columns:

{
  type: 'group',
  direction: 'row',
  gap: 20,
  children: [
    { type: 'group', flex: 1, children: [{ type: 'text', text: 'Left' }] },
    { type: 'group', flex: 1, children: [{ type: 'text', text: 'Right' }] }
  ]
}

Three columns with proportions (1:2:1):

{
  type: 'group',
  direction: 'row',
  gap: 15,
  children: [
    { type: 'group', flex: 1, children: [/* ... */] },
    { type: 'group', flex: 2, children: [/* ... */] },
    { type: 'group', flex: 1, children: [/* ... */] }
  ]
}

Centered card:

{
  type: 'group',
  width: 300,
  align: 'center',
  border: { color: '#333', width: 2 },
  padding: 20,
  children: [
    { type: 'heading', text: 'Card Title', align: 'center' },
    { type: 'text', text: 'Card content here' }
  ]
}

Space between items:

{
  type: 'group',
  direction: 'row',
  justify: 'space-between',
  children: [
    { type: 'text', text: 'Left' },
    { type: 'text', text: 'Right' }
  ]
}

Mixed positioning:

await client.callTool('pdf-layout', {
  layout: { overflow: 'auto' },
  content: [
    { type: 'heading', text: 'TITLE', x: 54, y: 50 },
    {
      type: 'group',
      direction: 'row',
      gap: 20,
      x: 54,
      y: 100,
      children: [
        { type: 'group', flex: 1, children: [/* ... */] },
        { type: 'group', flex: 1, children: [/* ... */] }
      ]
    },
    { type: 'text', text: 'Footer', x: 54, y: 700 }
  ]
});

Complete flyer example:

await client.callTool('pdf-layout', {
  pageSetup: { backgroundColor: '#fffef5' },
  content: [
    { type: 'heading', text: 'SUMMER FESTIVAL 2024', align: 'center', fontSize: 28, y: 50 },
    { type: 'text', text: 'July 15-17 | Central Park', align: 'center', y: 90 },
    {
      type: 'group',
      direction: 'row',
      gap: 20,
      x: 54,
      y: 130,
      children: [
        {
          type: 'group',
          flex: 1,
          border: { color: '#2196f3', width: 2 },
          padding: 15,
          children: [
            { type: 'heading', text: 'MUSIC', align: 'center', fontSize: 18 },
            { type: 'text', text: 'Live bands all weekend' },
            { type: 'text', text: '- Main Stage' },
            { type: 'text', text: '- Acoustic Tent' }
          ]
        },
        {
          type: 'group',
          flex: 1,
          border: { color: '#4caf50', width: 2 },
          padding: 15,
          children: [
            { type: 'heading', text: 'FOOD', align: 'center', fontSize: 18 },
            { type: 'text', text: '50+ local vendors' },
            { type: 'text', text: '- Food Court' },
            { type: 'text', text: '- Craft Beers' }
          ]
        }
      ]
    },
    {
      type: 'group',
      width: 300,
      align: 'center',
      y: 400,
      border: { color: '#ff9800', width: 2 },
      padding: 15,
      background: '#fff8e1',
      children: [
        { type: 'heading', text: 'TICKETS', align: 'center', fontSize: 16 },
        { type: 'text', text: 'Early Bird: $25', align: 'center' },
        { type: 'text', text: 'At Door: $35', align: 'center' }
      ]
    }
  ]
});

Emoji and Unicode support

Color emoji render as inline images. Unicode text is supported across major scripts.

{
  "basics": {
    "name": "John Doe",
    "summary": "Developer passionate about clean code"
  }
}

pdf-document

Create a flowing PDF document with automatic pagination.

pdf-image

Render PDF pages to PNG images for previews or export.

text-measure

Measure text width and height before layout.

Tools

  1. pdf-document

  2. pdf-image

  3. pdf-layout

  4. pdf-resume

  5. text-measure

External resources

None.

Prompts

  1. resource-fetching

Resources

  • PDFKit Documentation

  • JSON Resume Schema

  • JSON Resume Editor

Documentation

API Docs

Available Tools

5 tools
pdf-documentCreate PDF DocumentA

Create a flowing PDF document with automatic pagination.

Best for: Reports, articles, letters, contracts, and documents with sequential content.

Content flows naturally from top to bottom. Pages break automatically when content exceeds page height. Use "pageBreak" to force page breaks, "divider" for horizontal rules, and "spacer" for vertical spacing.

Supported content types:

  • text: Body text with optional formatting (bold, italic, color, alignment)

  • heading: Section headings (larger font, bold by default)

  • image: Inline images that flow with content

  • divider: Horizontal line separators

  • spacer: Vertical whitespace

  • pageBreak: Force new page

Default margins: Varies by page size (e.g., 72pt/1" for Letter, ~56pt for A4).

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameNoOptional logical filename (metadata only). Storage uses UUID. Defaults to "document.pdf".
titleNoDocument title metadata
authorNoDocument author metadata
fontNoFont strategy (default: auto). Built-ins: Helvetica, Times-Roman, Courier. Use a path or URL for Unicode.
pageSetupNoPage configuration including size, margins, and background color.
contentYesDocument content in flow order

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining key behavioral traits: 'Content flows naturally from top to bottom. Pages break automatically when content exceeds page height,' describing default margins that vary by page size, and listing supported content types with their purposes. It doesn't mention error conditions, performance characteristics, or output format details, but provides substantial operational context 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.

Conciseness4/5

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

The description is well-structured and appropriately sized. It starts with the core purpose, then provides usage guidance, explains key behaviors, lists content types, and ends with margin defaults. Most sentences earn their place, though the content type listing could be more concise. The information is front-loaded with the most important details first.

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 complexity (6 parameters with nested objects) and the presence of an output schema (which means return values don't need explanation), the description provides good contextual completeness. It covers the tool's purpose, appropriate use cases, key behaviors, and content semantics. With no annotations, it could benefit from mentioning error conditions or performance limits, but it's largely complete for guiding usage.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some value by explaining the purpose of content types like 'pageBreak', 'divider', and 'spacer', and mentioning default margin behavior. However, it doesn't provide significant additional semantic meaning beyond what's already in the comprehensive schema descriptions.

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

Purpose5/5

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

The description clearly states the tool creates a 'flowing PDF document with automatic pagination' and specifies it's 'best for: Reports, articles, letters, contracts, and documents with sequential content.' This distinguishes it from sibling tools like pdf-image (likely for image manipulation), pdf-layout (likely for fixed layouts), and pdf-resume (likely specialized for resumes). The description goes beyond the name/title by explaining the flowing nature and target use cases.

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

Usage Guidelines4/5

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

The description provides clear context about when to use this tool ('Best for: Reports, articles, letters, contracts, and documents with sequential content') and mentions the text-measure tool for precise dimensions. However, it doesn't explicitly state when NOT to use this tool versus alternatives like pdf-layout or pdf-resume, nor does it provide exclusion criteria or prerequisites for usage.

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

pdf-imageConvert PDF to ImageA

Generate PNG image(s) from PDF pages.

Use this to visually verify PDF output without opening external applications.

Pages Options:

  • Single page: pages: 1 or pages: 3

  • Multiple pages: pages: [1, 3, 5]

  • All pages: pages: "all"

  • Default: page 1 only

Viewport Scale Recommendations:

  • 0.25 (thumbnail): ~150px wide, smallest file (~15-30KB). Use for quick verification.

  • 0.5 (preview): ~300px wide, good balance (~40-80KB). Recommended default.

  • 1.0 (full): ~612px wide, detailed view (~150-300KB). Use when details matter.

Lower scales produce smaller files, reducing context usage when sharing images.

ParametersJSON Schema
NameRequiredDescriptionDefault
pdfPathYesAbsolute path to the PDF file
pagesNoPages to render: single number (e.g., 1), array (e.g., [1, 3, 5]), or "all". Default: 1
viewportScaleNoScale factor for the image. Recommended: 0.25 (thumbnail, ~150px wide, smallest), 0.5 (preview, ~300px wide, good balance), 1.0 (full size, ~612px wide). Default: 0.5

Output Schema

ParametersJSON Schema
NameRequiredDescription
imagesYesArray of generated images
totalPagesYesTotal pages rendered

TDQS

A4.8/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining output characteristics (PNG images), file size implications, and context usage considerations. However, it doesn't mention potential limitations like maximum PDF size, processing time, or error conditions, which would be helpful for a mutation tool.

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 perfectly structured and front-loaded with the core purpose, followed by organized sections for pages options and viewport scale recommendations. Every sentence earns its place by providing essential guidance without redundancy. The bullet points and bold formatting enhance readability without adding fluff.

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

Completeness5/5

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

Given the tool's complexity (conversion with multiple parameters) and the presence of an output schema, the description provides complete context. It covers the transformation purpose, parameter semantics with practical examples, usage scenarios, and performance considerations. The output schema will handle return values, so the description appropriately focuses on input guidance and behavioral context.

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

Parameters5/5

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

Despite 100% schema description coverage, the description adds significant value beyond the schema. It provides concrete examples for the 'pages' parameter (single page, multiple pages, all pages), detailed recommendations for 'viewportScale' with pixel dimensions and file sizes, and practical guidance on when to use different scales. This transforms technical parameters into actionable decisions.

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

Purpose5/5

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

The description clearly states the tool's purpose with specific verbs ('Generate PNG image(s) from PDF pages') and distinguishes it from sibling tools by focusing on visual verification rather than document analysis or text measurement. It goes beyond the title by specifying the output format (PNG) and the transformation process.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool ('Use this to visually verify PDF output without opening external applications') and provides clear alternatives through viewport scale recommendations for different use cases (thumbnail for quick verification, preview as default, full for detailed views). It effectively guides the agent on selecting appropriate parameters based on context.

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

pdf-layoutCreate PDF LayoutA

Create a PDF with precise positioning using Yoga flexbox layout.

Best for: Dashboards, slides, certificates, flyers, and designs requiring exact placement.

All items are positioned absolutely on specific pages. Use the "page" property to target different pages (e.g., page: 2 for multi-slide presentations). Pages are created as needed.

Use groups for flexbox containers - they support direction, gap, justify, alignItems, and alignment properties for sophisticated layouts.

Default margins: 0 (full canvas access for precise positioning).

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameNoOptional logical filename (metadata only). Storage uses UUID. Defaults to "document.pdf".
titleNoDocument title metadata
authorNoDocument author metadata
fontNoFont strategy (default: auto). Built-ins: Helvetica, Times-Roman, Courier. Use a path or URL for Unicode.
layoutNoLayout configuration for overflow handling
pageSetupNoPage configuration including size, margins, and background color.
contentYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does well: explains pages are created as needed, default margins (0 for full canvas), positioning strategies (absolute vs relative), and group functionality for flexbox containers. Could improve by mentioning output format or error handling, but covers key behavioral aspects 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.

Conciseness5/5

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

Perfectly structured with front-loaded purpose, usage guidelines, key features (page targeting, groups, default margins) in 5 focused sentences. Zero wasted words - every sentence provides essential information about when and how to use the tool effectively.

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 complexity (7 parameters, nested objects) and no annotations, the description does well covering purpose, use cases, key behaviors, and flexbox capabilities. With an output schema present, it doesn't need to explain return values. Could mention error conditions or performance considerations, but provides solid foundation for agent understanding.

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 high (86%), so baseline is 3. The description adds some value by explaining groups support 'direction, gap, justify, alignItems, and alignment properties for sophisticated layouts' and mentions 'page' property for multi-page targeting. However, it doesn't significantly enhance understanding beyond the well-documented schema parameters.

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 'Create a PDF with precise positioning using Yoga flexbox layout' - specific verb (create) + resource (PDF) + method (Yoga flexbox). It distinguishes from siblings by emphasizing precise positioning and flexbox layout, unlike pdf-document (general), pdf-image (image-focused), pdf-resume (resume-specific), and text-measure (measurement only).

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

Usage Guidelines5/5

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

Explicitly states 'Best for: Dashboards, slides, certificates, flyers, and designs requiring exact placement' - clear when-to-use guidance. Implicitly distinguishes from siblings by focusing on layout-intensive designs rather than general documents (pdf-document), image handling (pdf-image), or resume generation (pdf-resume).

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

pdf-resumeGenerate Resume PDFB

Generate a professional resume PDF from JSON Resume format. Supports layout customization, date/locale formatting, styling, fonts, and automatic page breaks.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameNoOptional logical filename (metadata only). Storage uses UUID. Defaults to "resume.pdf".
resumeYesResume data in JSON Resume format
fontNoFont for the PDF. Defaults to "auto" (system font detection). Built-ins are limited to ASCII; provide a path or URL for full Unicode.
pageSizeNoPage size preset (default: "LETTER"). Use "A4" for international standard.
backgroundColorNoPage background color (hex like "#fffff0" or named color like "ivory"). Default: white.
sectionsNoSections configuration for section ordering and field templates
layoutNoSpatial arrangement of sections. Omit for single-column (default). Use style: "two-column" with columns config for sidebar layouts.
stylingNoTypography and styling options

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions output generation and features but fails to describe critical behaviors such as error handling, performance characteristics (e.g., processing time), or side effects (e.g., file storage implications). For a complex tool with 8 parameters, this is a significant gap.

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

Conciseness4/5

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

The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured by separating key features into bullet points for better readability.

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 tool's complexity (8 parameters, nested objects) and the presence of an output schema, the description is minimally adequate. However, without annotations and with no guidance on usage or behavioral traits, it leaves significant gaps for an agent to understand when and how to invoke this tool effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by listing high-level features like 'layout customization' and 'styling', which loosely map to parameters but do not provide additional semantic context beyond what the schema offers.

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 specific action ('Generate a professional resume PDF') and the input format ('from JSON Resume format'), distinguishing it from sibling tools like pdf-document or pdf-image. It also mentions key capabilities like layout customization and styling, which helps differentiate its purpose.

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 like pdf-document or pdf-layout. It lists features but does not indicate prerequisites, constraints, or typical scenarios for usage, leaving the agent to infer context from tool names alone.

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

text-measureMeasure Text DimensionsA

Measure text width and height before rendering.

Returns exact dimensions based on font, font size, and text content. Use this to:

  • Calculate text width to set proper container sizes

  • Determine if text will fit in a given space

  • Plan multi-line layouts by specifying width constraint

Width is measured as single-line natural width. Height accounts for text wrapping when width is specified.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemsYesArray of text items to measure
fontNoFont specification (default: auto). Built-ins: Helvetica, Times-Roman, Courier. Use a path or URL for custom fonts.

Output Schema

ParametersJSON Schema
NameRequiredDescription
fontYesFont used for measurements
measurementsYes

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by explaining key behaviors: 'Returns exact dimensions', 'Width is measured as single-line natural width', and 'Height accounts for text wrapping when width is specified'. It doesn't mention performance characteristics or error conditions, but covers the core functionality adequately.

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

Conciseness5/5

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

The description is well-structured and front-loaded with the core purpose. Every sentence earns its place: the opening statement defines the tool, bullet points provide usage guidelines, and the final sentence clarifies measurement behavior. No wasted words.

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

Completeness5/5

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

Given the tool's moderate complexity, 100% schema description coverage, and the presence of an output schema, the description is complete enough. It explains what the tool does, when to use it, and key behavioral aspects without needing to detail return values (handled by 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 description coverage is 100%, so the baseline is 3. The description adds some context about 'font, font size, and text content' and mentions 'width constraint' for multi-line layouts, but doesn't provide additional parameter semantics beyond what's already documented in the schema.

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

Purpose5/5

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

The description clearly states the tool's purpose with specific verbs ('measure text width and height before rendering') and resources ('text dimensions based on font, font size, and text content'). It distinguishes itself from sibling tools by focusing on measurement rather than document/image creation or layout generation.

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

Usage Guidelines5/5

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

The description provides explicit usage scenarios with bullet points: 'Calculate text width to set proper container sizes', 'Determine if text will fit in a given space', and 'Plan multi-line layouts by specifying width constraint'. These give clear guidance on when to use this tool versus alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv1.0.0
    • Removedcreate-pdf
    • Removedcreate-simple-pdf
    • Removedgenerate-resume-pdf
    • Addedpdf-document
    • Addedpdf-image
    • Addedpdf-layout
    • Addedpdf-resume
    • Addedtext-measure
  2. 3 tool updates
    • First observedcreate-pdf
    • First observedcreate-simple-pdf
    • First observedgenerate-resume-pdf
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: pdf-document creates flowing documents, pdf-image generates PNGs from PDFs, pdf-layout handles precise positioning, pdf-resume builds resumes from JSON, and text-measure calculates text dimensions. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tool names follow a consistent hyphenated prefix pattern (pdf- or text-) with descriptive nouns, making them predictable and readable. The naming is uniform across the set without any deviations in style.

Tool Count5/5

With 5 tools, the server is well-scoped for PDF generation and manipulation, covering core needs like document creation, layout, image export, resume generation, and text measurement. Each tool earns its place without being excessive or insufficient.

Completeness4/5

The tool set covers key PDF operations: creation (pdf-document, pdf-layout, pdf-resume), conversion (pdf-image), and utility (text-measure). Minor gaps exist, such as no explicit tools for editing existing PDFs or merging files, but agents can work around this with the provided tools.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • PDF-Tools MCP Server

    Theorhd
    A
    license
    A
    quality
    D
    maintenance
    Enables PDF generation from HTML, text, and Markdown content with customizable formatting options. Provides secure cross-platform PDF creation tools that automatically save to user directories like Downloads, Documents, or Desktop.
    4
    89
    MIT

  • rendoc

    yoryocoruxo-ai
    A
    license
    A
    quality
    C
    maintenance
    Generate professional PDFs from Claude, Cursor, and other AI tools. Create invoices, contracts, reports, and certificates from templates or inline HTML markup.
    7
    59
    1
    MIT

  • pdfnative-mcp

    Nizoka
    A
    license
    A
    quality
    A
    maintenance
    Enterprise-grade PDF engine for AI agents. Pure TypeScript, zero-dependency, and local-first. Allows agents to generate ISO-compliant PDF/A documents, handle digital signatures (PKCS#7), and process high-performance layouts (800+ pages in seconds).
    28
    435
    2
    MIT

Latest Blog Posts

MCP directory API

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

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

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