Skip to content
Back to blog
MCP AI agents integration

Connect Any AI Agent to PDF Generation with MCP

pdfs.build Team

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:

After publishing and minting a key, the agent calls POST /v1/render on the public REST API to produce the final PDF. This means a single agent session can go from “design this invoice” to “here is a download link” without a human touching the dashboard.

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:

  1. User: “Can you generate an invoice for the October project?”
  2. Claude calls list_templates → finds invoice-v3
  3. Claude calls get_template for invoice-v3 → loads the schema, sample data, and template code
  4. Claude maps conversation context to the schema, filling in client name, line items, and dates
  5. Claude calls compile_document to verify the template renders cleanly with that data
  6. (First-time setup only) Claude calls publish_template to make the template available to the public render API, then create_api_key to mint a key
  7. Claude calls POST https://api.pdfs.build/v1/render with { "templateId": "...", "data": { ... } } → receives the binary PDF
  8. 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:

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 still work for the REST API at https://api.pdfs.build/v1/* but are no longer accepted at the MCP endpoint.

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

Back to blog