Connect Any AI Agent to PDF Generation with MCP

Most AI agent integrations follow the same pattern: you wrap an API in a function, describe it to the model, and hope the JSON it returns matches your schema. It works, but it’s fragile — schema drift, inconsistent field names, and missing error context all become your problem.

The Model Context Protocol (MCP) takes a different approach. It’s a standard that lets language models discover and call tools natively, with rich type information and structured error feedback built in. pdfs.build exposes its entire rendering pipeline as an MCP server — which means any MCP-compatible agent can generate documents without you writing a single line of integration code.

How it works

When your agent connects to the pdfs.build MCP server, it gains access to the full template lifecycle as native tools:

list_templates / get_template — browse templates and read their schema and sample data
create_template — start a new draft template
write_document / write_schema / write_sample_data — author the template code, schema, and example data
compile_document — compile the current template against generated edge-case fixtures and optional custom payloads
render_template — render a saved template without an API key and optionally return an expiring share/download URL
save_template — persist edits as a checkpoint after the compile gate passes
publish_template / unpublish_template — move a draft into the org’s published library; publishing requires the compile gate to pass
create_api_key / list_api_keys / delete_api_key — mint, audit, and revoke REST API keys for external integrations

After saving the template, the agent calls render_template to produce the final PDF. When it passes public_share=true, it receives expiring share/download URLs; expires_in_days customizes the expiry. The render counts toward your monthly PDF render quota, just like app, authenticated form, automation, and REST API renders.

Setting up the MCP connection

In your agent configuration, add the pdfs.build MCP server endpoint:

{
  "mcpServers": {
    "pdfreport": {
      "url": "https://backend.pdfs.build/mcp"
    }
  }
}

On first connection, your MCP client will open a browser tab to authorize access to your pdfs.build account. After that, the agent automatically discovers the available tools and their input schemas.

Example: Claude generating an invoice

Here’s what a Claude conversation with MCP looks like from the agent’s perspective:

User: “Can you generate an invoice for the October project?”
Claude calls list_templates → finds invoice-v3
Claude calls get_template for invoice-v3 → loads the schema, sample data, and template code
Claude maps conversation context to the schema, filling in client name, line items, and dates
Claude calls compile_document to verify the template renders cleanly with that data
Claude calls render_template with { "templateId": "...", "data": { ... } }
The tool returns a rendered document id plus share and PDF download URLs
Claude responds: “Here’s your invoice: [download link]”

The model handles the data mapping. You handle the template design. No glue code in between.

Why this matters for document-heavy workflows

Traditional document generation requires a developer to write mapping logic for every template change. With MCP, the model reads the schema directly and adapts. Update your invoice template to add a new “project code” field, and any connected agent immediately knows it’s available — no deployment required.

This is particularly valuable for:

Finance and ops teams where documents change frequently
Customer-facing agents that generate personalized reports on demand
Internal tools where non-engineers need to trigger document generation

Authorizing your agent

MCP connections use OAuth 2.1 — not API keys. On first connection, your client opens a browser to sign you into pdfs.build and request authorization. The token is stored locally by your client and refreshes automatically. The prs_ API keys work with the organization-scoped REST API at https://api.pdfs.build/v2/* (and the supported legacy v1 API) but are not accepted at the MCP endpoint.

Check the API Reference for the full list of MCP-exposed tools and their schemas.

Back to blog