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
- 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 public API keys so the agent can self-serve a key, hit the render API end-to-end, and clean up
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:
- User: “Can you generate an invoice for the October project?”
- Claude calls
list_templates→ findsinvoice-v3 - Claude calls
get_templateforinvoice-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_documentto verify the template renders cleanly with that data - (First-time setup only) Claude calls
publish_templateto make the template available to the public render API, thencreate_api_keyto mint a key - Claude calls
POST https://api.pdfs.build/v1/renderwith{ "templateId": "...", "data": { ... } }→ receives the binary PDF - 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 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.