Skip to main content
Glama
Himaan1998Y

pretext-pdf-mcp

by Himaan1998Y
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

pretext-pdf-mcp

npm version npm downloads license CI

MCP server for pretext-pdf — generate professional PDFs from structured JSON in Claude, Cursor, or any AI agent.

No headless browser. No puppeteer. Pure Node.js with embedded fonts and precision text layout.

Live Demo

▶ Open Live Demo — edit JSON, click Generate, see a real PDF in seconds. No install.

▶ Open in StackBlitz — fork and edit the playground code.

4 templates included: GST Invoice · Market Report · Resume/CV · Custom

Related MCP server: PDF Generator API MCP Server

Connect via Smithery

The fastest way — no install, works instantly in any MCP-compatible agent:

https://pretext-pdf.run.tools

Or add via CLI:

smithery mcp add himaan4149-kv55/pretext-pdf

Local Install (Claude Desktop / Cursor / Windsurf)

Option 1: npx (no global install needed)

npx pretext-pdf-mcp

Option 2: Global install

npm install -g pretext-pdf-mcp
pretext-pdf-mcp

Claude Desktop Configuration

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "pretext-pdf": {
      "command": "npx",
      "args": ["-y", "pretext-pdf-mcp"]
    }
  }
}

Config file location:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

Using with Claude Code CLI

Option A — one-liner (user-scoped, persists across projects):

claude mcp add pretext-pdf-mcp -- npx -y pretext-pdf-mcp

Option B — project-scoped .mcp.json (checked into repo, shared with your team):

Create .mcp.json in your project root:

{
  "mcpServers": {
    "pretext-pdf": {
      "command": "npx",
      "args": ["-y", "pretext-pdf-mcp"]
    }
  }
}

Then restart Claude Code (or run /mcp to verify). All 6 tools are available in your session. Type /mcp to confirm the server appears.

HTTP Transport Mode (advanced)

By default the server runs over stdio (MCP standard transport). For HTTP transport:

MCP_TRANSPORT=http MCP_PORT=3000 npx pretext-pdf-mcp

Environment variables:

  • MCP_TRANSPORT — Set to http to enable HTTP transport (default: stdio)

  • MCP_PORT — HTTP listen port when MCP_TRANSPORT=http (default: 3000)

  • MCP_HOST — HTTP listen host (default: 127.0.0.1)

Security note: HTTP transport is intended for trusted local networks only. Do not expose the HTTP port to the public internet without adding an authentication layer.

Known Limitations

  • Italic fonts — Italic markdown (*text*) requires an italic font variant. Inter italic is supported via @fontsource/inter (installed automatically). For other fonts, provide { family, weight, style: 'italic', src } in doc.fonts.

  • QR codes, barcodes, charts — Require optional peer dependencies: qrcode, bwip-js, vega/vega-lite. Install the ones you need.

  • SVG and images — Image URLs must be HTTPS. Private/local IP addresses are blocked (SSRF prevention). File paths require absolute paths.

  • Large documents — No hard page limit, but generation time scales with page count. Documents over 10,000 content elements trigger a performance advisory.

  • CJS consumers — pretext-pdf is ESM-only. If your project uses CommonJS, use dynamic import().

Tools

Tool

Input

Output

generate_pdf

PdfDocument JSON descriptor

Base64 PDF + filename + size

generate_invoice

Invoice data (parties, items, GST, currency)

Base64 PDF

generate_report

Report sections with optional tables and callouts

Base64 PDF

generate_from_markdown

Markdown string

Base64 PDF

validate_document

PdfDocument JSON

Validation result (valid/errors)

list_element_types

none

Markdown reference of all element types

generate_pdf

Full-power access to the pretext-pdf API. Pass any PdfDocument descriptor.

{
  "document": {
    "pageSize": "A4",
    "footer": { "text": "Page {{pageNumber}} of {{totalPages}}", "fontSize": 9 },
    "content": [
      { "type": "heading", "level": 1, "text": "My Document" },
      { "type": "paragraph", "text": "Hello world." }
    ]
  },
  "filename": "my-document"
}

Returns:

{
  "success": true,
  "base64": "<base64-encoded PDF bytes>",
  "filename": "my-document.pdf",
  "size_bytes": 42816
}

generate_invoice

Business-friendly invoice generator. No PDF knowledge needed.

{
  "from": {
    "company": "Antigravity Systems",
    "address": "Gurugram, Haryana",
    "gstin": "06AABCA1234Z1ZK",
    "email": "hello@antigravity.dev"
  },
  "to": {
    "company": "TCS Ltd",
    "address": "Mumbai, Maharashtra",
    "gstin": "27AAACT2727Q1ZW"
  },
  "invoice_number": "INV-2026-001",
  "date": "2026-04-08",
  "due_date": "2026-05-08",
  "currency": "INR",
  "items": [
    {
      "description": "LLM Fine-tuning Pipeline",
      "hsn_code": "998314",
      "quantity": 1,
      "rate": 250000,
      "gst_rate": 18
    },
    {
      "description": "AI Strategy Workshop",
      "quantity": 2,
      "rate": 75000,
      "gst_rate": 18
    }
  ],
  "notes": "Payment due within 30 days. NEFT/IMPS preferred."
}

Returns:

{
  "success": true,
  "base64": "<base64-encoded PDF bytes>",
  "filename": "invoice-INV-2026-001.pdf",
  "size_bytes": 68420
}

Features:

  • Supports INR, USD, EUR, GBP

  • Auto-calculates IGST per line item when gst_rate is set

  • HSN/SAC code column appears automatically when any item has it

  • Company header with from/to details in a 2-column table

  • Professional footer with invoice number and page numbers

generate_report

Multi-section report with optional TOC, tables, and callout boxes.

{
  "title": "Haryana Real Estate Q1 2026",
  "subtitle": "Residential & Commercial Analysis",
  "author": "Antigravity Research",
  "include_toc": true,
  "sections": [
    {
      "heading": "Executive Summary",
      "body": "Strong growth across all micro-markets.\n\nGurugram led with 18% YoY volume growth.",
      "table": {
        "headers": ["Market", "Avg Rs./sqft", "YoY"],
        "rows": [
          ["New Gurugram", "9,800", "+15.6%"],
          ["Sohna Road", "8,400", "+12.1%"]
        ]
      },
      "callout": {
        "style": "warning",
        "text": "Repo rate risk: any hike above 6.75% could suppress volumes 10-15%."
      }
    }
  ]
}

list_element_types

No input. Returns a markdown reference of all 22 element types (paragraph, heading, table, list, image, svg, code, blockquote, callout, toc, form-field, comment, hr, spacer, page-break, rich-paragraph, qr-code, barcode, chart, footnote-def, float-group, and toc-entry) with key properties and examples.

generate_from_markdown

Convert a Markdown string to a PDF without writing any JSON. Supports headings, bold/italic, strikethrough, inline code, links, ordered/unordered lists (up to 3 levels), GFM tables (with column alignment), GFM task lists (☑/☐), blockquotes, fenced code blocks, and horizontal rules. Note: code blocks render as plain indented text — not styled monospace. For styled code blocks or richer layouts, use generate_pdf.

{
  "markdown": "# Hello\n\nThis is a **bold** paragraph.\n\n- Item 1\n- Item 2",
  "filename": "hello",
  "page_size": "A4",
  "font_size": 12
}

Returns:

{
  "success": true,
  "base64": "<base64-encoded PDF bytes>",
  "filename": "hello.pdf",
  "size_bytes": 18432
}

Limits: markdown max 100,000 characters. font_size must be 6–144. page_size one of: A4, Letter, Legal. Default filename: document.

validate_document

Validate a pretext-pdf document schema without rendering it. Use this as a cheap preflight check before calling generate_pdf — catches typos, missing required fields, and unknown props in strict mode.

{
  "document": {
    "pageSize": "A4",
    "content": [{ "type": "heading", "level": 1, "text": "Test" }]
  },
  "strict": true
}

Valid response:

{ "valid": true, "error_count": 0, "warning_count": 0, "errors": [], "warnings": [] }

Invalid response:

{
  "valid": false,
  "error_count": 2,
  "warning_count": 0,
  "errors": [
    {
      "path": "doc.content[0].colour",
      "message": "unknown property. did you mean \"color\"",
      "code": "UNKNOWN_PROPERTY",
      "severity": "error",
      "unknownProp": "colour",
      "suggestion": "color"
    },
    {
      "path": "doc.pageSize",
      "message": "unknown property. did you mean \"pageSize\"",
      "code": "UNKNOWN_PROPERTY",
      "severity": "error",
      "unknownProp": "pageSise",
      "suggestion": "pageSize"
    }
  ],
  "warnings": []
}

Tip: Pass strict: true to catch misspelled props with Levenshtein-nearest suggestions. Default is strict: false — only checks required fields and types.

Decoding the base64 PDF

In Node.js:

const bytes = Buffer.from(result.base64, 'base64')
fs.writeFileSync('output.pdf', bytes)

In TypeScript (browser):

const bytes = Uint8Array.from(atob(result.base64), c => c.charCodeAt(0))
const blob = new Blob([bytes], { type: 'application/pdf' })

In Python:

import base64
pdf_bytes = base64.b64decode(result['base64'])
with open('output.pdf', 'wb') as f:
    f.write(pdf_bytes)

License

MIT — Himanshu Jain

Available Tools

6 tools
generate_from_markdownA

Convert a Markdown string to a PDF. Supports headings, bold/italic, strikethrough, inline code, links, ordered/unordered lists (nested up to 3 levels), GFM tables (with column alignment), GFM task lists (☑/☐), blockquotes, fenced code blocks (rendered as plain indented text — not styled monospace), and horizontal rules. For richer layouts or styled code blocks, use generate_pdf instead. Returns a base64-encoded PDF.

ParametersJSON Schema
NameRequiredDescriptionDefault
markdownYesMarkdown source to convert. Max 100,000 characters.
filenameNoSuggested filename without .pdf extension. Default: document
page_sizeNoPage size. Default: A4. Matches the NamedPageSize union exported by pretext-pdf.
font_sizeNoBody font size in pt. Default: 12

TDQS

A4.7/5.0
Behavior5/5

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

Despite missing annotations, the description fully informs about behavioral traits: it notes that fenced code blocks are rendered as plain indented text (not styled monospace), output is base64-encoded PDF, and implicitly reveals safe read-only behavior. This exceeds expectations for an unannotated 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 concise (three sentences) and front-loaded with purpose. Every sentence earns its place: purpose, supported features, alternative, output format. No redundant information.

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 (many supported Markdown features) and absence of output schema, the description is remarkably complete. It covers input constraints, output format, key behavioral notes (code blocks), and provides a clear alternative.

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 does not add new parameter-specific semantics beyond what the schema already provides, but it does not contradict or omit any necessary details.

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 'Convert a Markdown string to a PDF' with specific verb and resource. It distinguishes itself from sibling tool generate_pdf by specifying that generate_pdf offers richer layouts or styled code blocks, making the purpose unambiguous.

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 advises when to use an alternative: 'For richer layouts or styled code blocks, use generate_pdf instead.' It also lists supported Markdown elements, implying appropriate usage contexts for this tool.

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

generate_invoiceA

Generate a professional invoice PDF. Accepts structured invoice data (from/to parties, line items, optional GST/tax). Returns base64-encoded PDF. Supports INR/USD/EUR/GBP currencies. Currency symbols (₹ $ € £) are guaranteed not to break away from adjacent numbers across line wraps. gst_rate on items creates a tax column — use it for any tax system (GST, VAT, sales tax). Per-item gst_rate is summed as IGST in the totals; CGST/SGST inter-vs-intra-state routing is not currently supported.

ParametersJSON Schema
NameRequiredDescriptionDefault
fromYesIssuing party (your company)
toYesBilling party (client)
invoice_numberNoInvoice identifier e.g. INV-2026-001
dateNoInvoice date ISO format YYYY-MM-DD. Defaults to today.
due_dateNoPayment due date ISO format.
currencyNoCurrency. Default: INR
itemsYesLine items
notesNoAdditional notes or payment terms.
upi_qr_dataNoUPI payment string for QR code, e.g. "upi://pay?pa=merchant@upi&pn=Name&am=1000". When provided, a scannable QR code is embedded in the PDF.
filenameNoSuggested filename without .pdf extension.

TDQS

A4.4/5.0
Behavior4/5

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

Discloses behavioral traits beyond the schema: returns base64 PDF, currency symbols handling, tax column behavior, and IGST limitation. No annotations are present, so the description carries the full burden; it covers key aspects well.

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?

Concise and well-structured: 7 sentences front-loaded with main purpose, then supplementary details. Every sentence adds value without redundancy.

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

Completeness4/5

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

Given the tool's complexity (10 params, nested objects, no output schema), the description covers essential aspects: return format, supported currencies, tax behavior, and UPI QR. It is complete for an agent to use effectively.

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

Parameters4/5

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

Adds meaning beyond input schema by explaining gst_rate usage, common Indian GST slabs, and UPI QR code embedding. With 100% schema coverage, the description enriches parameter understanding.

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 generates a professional invoice PDF from structured data, specifying the return format (base64-encoded PDF) and key features. This distinguishes it from sibling tools like generate_from_markdown or generate_pdf.

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?

Provides good context on when to use (structured invoice data, optional tax, multiple currencies) and notes a limitation (CGST/SGST routing not supported). However, it does not explicitly mention when not to use or compare with siblings.

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

generate_pdfA

Generate a PDF from a custom PdfDocument JSON descriptor. Use this for any layout not covered by generate_invoice or generate_report — e.g. resumes, contracts, certificates, presentations, or any multi-element composition. Returns base64-encoded PDF bytes. Call list_element_types first to see available elements and options.

ParametersJSON Schema
NameRequiredDescriptionDefault
documentYesA PdfDocument config object. Call list_element_types first to see available element shapes for the content array.
filenameNoSuggested filename (without .pdf extension)document

TDQS

A4.6/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. It discloses the return format (base64-encoded PDF bytes) and implies a non-destructive creation operation. However, it does not address authorization, rate limits, or error behavior. Still, key behavioral traits are covered.

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

Conciseness5/5

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

The description is extremely concise: three sentences that efficiently convey purpose, differentiation, output format, and prerequisite. No unnecessary words.

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

Completeness4/5

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

Given the complexity of the nested document parameter and lack of output schema, the description provides essential context (base64 output, sibling tool references, element discovery). It is nearly complete, though error handling details are absent.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by directing to call list_element_types for element shapes, which is critical context not present in the schema. This elevates it beyond the baseline.

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

Purpose5/5

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

The description clearly states the action ('Generate a PDF from a custom PdfDocument JSON descriptor'), provides concrete examples of use cases (resumes, contracts, etc.), and explicitly differentiates from sibling tools (generate_invoice, generate_report).

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 when to use this tool vs alternatives ('Use this for any layout not covered by generate_invoice or generate_report') and advises calling list_element_types first, providing clear guidance on prerequisite and alternative selection.

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

generate_reportA

Generate a professional multi-section report PDF. Features: auto-generated TOC, per-section headings with PDF bookmarks, page-numbered footer, running header, optional tables and callout boxes per section. Returns base64-encoded PDF.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesReport title
subtitleNoReport subtitle or description
authorNoAuthor name
dateNoDate string. Defaults to today.
include_tocNoInclude a Table of Contents page. Default: true
sectionsYesReport sections
filenameNoSuggested filename without .pdf extension.

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the output is a base64-encoded PDF and lists included elements (TOC, headings, bookmarks, footers, tables, callouts). However, it does not mention potential limitations like file size, processing time, or error conditions (e.g., missing content).

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 concise—a single sentence followed by a list of key features. Every element is relevant and directly helps the agent understand what the tool does. 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?

The description covers the return format (base64 PDF) and major output features (TOC, bookmarks, tables). Given the absence of an output schema, this is helpful. However, it could be more complete by mentioning error handling, required page margins, or content size limits to fully prepare the 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?

The input schema has 100% description coverage for all 7 parameters, so the description adds no additional parameter information. The feature list in the description does not elaborate on parameter details beyond what the schema already provides.

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 'Generate a professional multi-section report PDF', specifying the verb and resource. It lists features like TOC, headings, bookmarks, and footers, which distinguish it from sibling tools like generate_invoice, generate_from_markdown, and generate_pdf.

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

Usage Guidelines3/5

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

The description implies usage for multi-section report generation with specific formatting features but does not explicitly state when to use this tool versus alternatives or provide any exclusions. It lacks guidance on scenarios where generate_from_markdown might be preferred.

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

list_element_typesA

Returns a markdown reference of all pretext-pdf element types and their key properties. Use this before calling generate_pdf to understand what elements and options are available.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It states the tool returns a markdown reference but gives no detail about size, side effects, or authentication needs. The behavioral transparency is adequate but minimal for a read-only info 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?

Two succinct sentences that are front-loaded and without filler. Every word adds value.

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

Completeness4/5

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

Given the tool's simplicity (no params, no annotations, no output schema), the description provides sufficient context: what it returns and when to use it. A minor improvement could be explicitly stating the output format, but it is not essential.

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

Parameters4/5

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

The input schema has zero parameters, and the description correctly adds no param info. According to guidelines, 0 parameters yields a baseline of 4, which is appropriate here.

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 that the tool returns a markdown reference of element types and properties, with a specific verb and resource. It distinguishes itself from sibling tools like generate_pdf by indicating its role as a preparatory step.

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 explicitly advises using this tool before generate_pdf to understand available elements, providing clear context. It does not list exclusion scenarios, but the purpose is well-defined enough for an agent to infer when it is appropriate.

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

validate_documentA

Validate a pretext-pdf document schema without rendering it. Returns immediately with all validation errors — use this as a cheap preflight check before calling generate_pdf. Each error includes a structured path, message, and optional typo suggestion.

ParametersJSON Schema
NameRequiredDescriptionDefault
documentYesThe pretext-pdf document to validate (same shape as generate_pdf.document)
strictNoWhen true, also report unknown/misspelled properties (default: false)

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It explains that validation returns immediately with errors, and that errors include structured path, message, and optional typo suggestion. No side effects are relevant.

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

Conciseness5/5

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

Two sentences, no filler. Front-loaded with purpose; efficient and clear.

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 moderate complexity (2 params, nested object, no output schema), description covers validation behavior, error structure, and usage hint. Complete for its role.

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

Parameters4/5

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

Schema coverage is 100% and description adds value: for 'document', it clarifies same shape as generate_pdf.document; for 'strict', it confirms default false and notes typo suggestions. Adds meaning beyond 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 validates a pretext-pdf document schema without rendering, and contrasts it with generate_pdf. It distinguishes itself from siblings by being a cheap preflight check.

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 explicitly recommends using this tool as a preflight check before generate_pdf. While it does not mention when not to use, the context makes the usage clear.

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. 6 tool updatesv1.5.12
    • First observedgenerate_from_markdown
    • First observedgenerate_invoice
    • First observedgenerate_pdf
    • First observedgenerate_report
    • First observedlist_element_types
    • First observedvalidate_document
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

A4.4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: markdown conversion, invoice generation, custom layout PDF, report generation, element type listing, and document validation. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (generate_*, list_*, validate_). The naming is predictable and makes the action and target clear.

Tool Count5/5

With 6 tools, the server is well-scoped, covering the core PDF generation needs (markdown, invoice, report, custom) plus essential helpers for validation and element discovery. Not too many or too few.

Completeness4/5

The tool surface covers the main PDF generation workflows. A minor gap is the lack of a tool for merging PDFs or converting other formats, but the custom generate_pdf tool can likely cover many of those scenarios. Validation and element listing are nice additions.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers