DEV Community: Arun

I Built 12 MCP Tools for PDF Generation — Here's How Product Engineers Use Them

Arun — Sun, 20 Sep 2026 10:06:46 +0000

Product engineers spend hours writing boilerplate to generate invoices, contracts, and reports. I was one of them. So I built an API that handles the entire pipeline — upload template, fill with data, return PDF — and exposed it as MCP tools so AI agents can call it directly.

The Problem: docxtpl Breaks With Real Templates

You have a Word template for invoices. It has a table with line items. You need to fill it with data from your API.

You reach for docxtpl. You throw in some Jinja2 syntax. And... it breaks.

from docxtpl import DocxTemplate

template = DocxTemplate("invoice.docx")
context = {
    "client": "Acme Corp",
    "items": [
        {"name": "Design", "qty": 10, "rate": 150},
        {"name": "Development", "qty": 20, "rate": 175},
        {"name": "Review", "qty": 5, "rate": 120},
    ]
}
template.render(context)  # Table collapses. XML is garbage.
template.save("invoice-filled.docx")

The table collapses. The PDF is garbage. You Google "docx to pdf python" and find 47 Stack Overflow answers that all say "just use HTML templates."

Here's why it breaks: Word's XML isn't HTML. A table row isn't a <tr> tag. It's <w:tr> wrapped in <w:tbl>, with properties, cell definitions, and spans all entangled. When docxtpl expands a {% for %} loop across rows, it doesn't understand the XML boundaries. It copies text. The row structure breaks. LibreOffice throws an error.

Most devs give up here. They either manually duplicate rows, switch to HTML templates and forget about Word, or accept that DOCX templates only work for flat documents without loops.

I refused to accept any of those options.

The Fix: Upload, Fill, Download

I built a pipeline that handles the entire lifecycle:

.docx upload → validate ZIP → extract schema → expand loops → render → convert to PDF → store

But here's the thing: you don't need to understand any of that. You just need three API calls:

# 1. Upload your template
curl -X POST https://api.docuqueue.com/templates/upload \
  -H "Authorization: Bearer dq_..." \
  -F file=@invoice.docx
# Returns: { "template_id": "tpl_abc123", "fields": ["client", "items"] }

# 2. Fill it with data
curl -X POST https://api.docuqueue.com/templates/tpl_abc123/fill \
  -H "Authorization: Bearer dq_..." \
  -H "Content-Type: application/json" \
  -d '{
    "client": "Acme Corp",
    "items": [
      {"name": "Design", "qty": 10, "rate": 150},
      {"name": "Development", "qty": 20, "rate": 175},
      {"name": "Review", "qty": 5, "rate": 120}
    ]
  }'
# Returns: { "job_id": "job_xyz789", "status": "processing" }

# 3. Download the PDF
curl -X GET https://api.docuqueue.com/jobs/job_xyz789/pdf \
  -H "Authorization: Bearer dq_..." \
  -o invoice-filled.pdf

That's it. The XML manipulation, the loop expansion, the LibreOffice conversion — all handled. You get a PDF.

The MCP Angle: 12 Tools for AI Agents

I exposed this same pipeline as MCP tools. Twelve total, but here are the ones product engineers actually use:

Tool	What It Does	When You'd Use It
`upload_template`	Upload a .docx or .html template	Once, when you have a new template
`get_schema`	See what fields the template expects	Before filling, to validate data
`fill_template`	Fill template with data, get PDF	Every time you generate a document
`preview`	Quick preview without full render	When iterating on template design
`list_templates`	See all your uploaded templates	When you have many templates
`get_status`	Check if a job is done	For async generation
`download_pdf`	Get the finished PDF	After fill completes
`delete_template`	Remove a template	When cleaning up

The workflow for an AI agent looks like this:

Agent: "Generate an invoice for Acme Corp with 3 line items"
  → upload_template(invoice.docx)
  → get_schema(template_id)
  → fill_template(template_id, {client: "Acme Corp", items: [...]})
  → download_pdf(job_id)
  → return PDF to user

The agent doesn't need to know about XML, LibreOffice, or any pipeline internals. It just uploads a template and gets a PDF back.

Authentication: OAuth 2.0 with PKCE

Every tool call goes through OAuth 2.0 with PKCE. No API keys stored in code. Agents authenticate once, get a scoped token, and use it for all operations.

This matters because you don't want an AI agent generating arbitrary documents from arbitrary templates without guardrails. Each token is scoped to the agent's permissions. If you only want it to fill invoices, that's all it can do.

What's Under the Hood

The pipeline handles edge cases you'd hit in production:

ZIP validation. Users upload corrupted files, renamed .doc files, or PDFs with .docx extensions. I check the ZIP structure before touching anything.
Loop expansion. The custom step that makes docxtpl work. Walks the XML tree, finds loop constructs in table rows, clones them to match your data.
Dual storage. Recent previews go into Redis with a 1-hour TTL (instant re-preview). Permanent copies go to Cloudflare R2.
Credit refund on failure. If generation fails, the credit goes back atomically with an audit log. No stale balances.

Try It

If you're building something that needs to generate PDFs from templates, check out DocuQueue. There's a free tier that covers most small use cases.

The MCP tools are available if you want AI agents to interact with the pipeline directly. Upload a template, call the fill tool, get a PDF. That's the whole API.

The DOCX problem isn't solved perfectly. No one has solved it perfectly. But the row expansion trick makes it work reliably for the vast majority of real-world templates. And that's enough to build on.

Found this useful? I'm @arun on here. The code behind DocuQueue is a constant source of "why does this work this way" blog posts. More coming soon.

75% fewer tokens per Claude Code request. Same result.

Arun — Tue, 25 Aug 2026 11:08:55 +0000

I stared at my Anthropic bill. $200. For one month. Of Claude Code.

Not because I was doing anything special. Just... regular coding. But here's the thing nobody tells you:

Claude Code sends 27 tool definitions with every single request.

27 JSON schemas. Every turn. Even if you're just fixing a typo in a CSS file.

I was paying to send GitHub tools, Context tools, IDE tools, agent tools... when all I needed was Read, Edit, and Grep.

So I built a proxy. A dumb, simple proxy that sits between my editor and the API. It reads my message, figures out what tools I actually need, and strips the rest before it reaches the model.

Cost went from $200 to $50. Same code. Same quality.

Here's how.

The Problem Nobody Talks About

Every AI coding tool works the same way. They have a bunch of built-in tools. File reading, bash execution, web search, git operations, context providers, IDE integration.

And they send all of them to the LLM on every request.

Claude Code has 27 tools. Cursor has similar. Windsurf too.

When you say "fix the nav labels in pricing.html", here's what happens:

Your client builds a request with 27 tool schemas
That's ~1,200 tokens of JSON definitions
The LLM reads all 27, picks 1 (usually Edit)
You pay for the other 26 doing nothing

That's like printing a 100-page menu when you're ordering a coffee.

What the Proxy Actually Does

One thing. It filters tool definitions.

Client sends 27 tools
    ↓
Proxy reads your message
    ↓
Proxy figures out what tools you need (6)
    ↓
Proxy forwards only those 6
    ↓
Provider responds normally

That's it. No magic. No LLM calls. Just regex matching and list filtering.

The classification

The proxy looks at your message and matches keywords:

"fix the nav labels in pricing.html"

regex "fix"     → file_edit: +2
regex "change"  → file_edit: +1  
regex "html"    → file_edit: +1

category = file_edit (score: 4)

Then it sends only the tools for that category:

KEEP: Read, Edit, Grep, Glob, Bash, Write
DROP: 21 others (GitHub, IDE, Context7, etc.)

The result

WITHOUT proxy:
  27 tools  ████████████████████████████████  ~1,200 tokens

WITH proxy:
   6 tools  ██████████░░░░░░░░░░░░░░░░░░░░░░  ~300 tokens

Saved: ~900 tokens per request (75%)

Same model. Same quality. Just fewer schemas.

How to Use It

# Clone
git clone https://github.com/dvcoolarun/dynamic-tool-proxy
cd dynamic-tool-proxy

# Install
pip install fastapi httpx uvicorn

# Run
python3 standalone_proxy.py

Then point your editor at it:

# Claude Code
ANTHROPIC_BASE_URL=http://localhost:8090 claude

# Or set it permanently
export ANTHROPIC_BASE_URL=http://localhost:8090

That's it. No API keys. No cloud accounts. No config files.

The proxy listens on port 8090. Your editor thinks it's talking to Anthropic. The proxy strips the tools and forwards the request.

What Categories It Knows

The proxy classifies your message into one of 7 categories:

Category	Tools Sent	When It Triggers
file_edit	Read, Edit, Grep, Glob, Bash, Write	"fix", "change", "edit", file extensions
search	Read, Grep, Glob, ListDirectory	"find", "search", "where is"
git	Bash, Read, Grep, Glob	"commit", "push", "branch", "git"
debug	Read, Grep, Bash, Glob	"error", "bug", "why", "broken"
web	WebFetch, WebSearch, Read	"url", "http", "website"
arch	Read, Grep, Glob, Bash, Agent	"refactor", "structure", "design"
full	All tools	Ambiguous messages (fallback)

Ambiguous messages get all tools. No quality loss. Just in case.

The Numbers

I tracked it for a week. Here's what I saw:

Metric	Before	After	Savings
Tokens per request	1,200	300	75%
Requests per day	100	100	—
Tokens saved per day	—	90,000	—
Monthly cost saved	—	—	$150

At 100 requests per day, that's 2.7 million tokens per month you're not paying for.

Works With Everything

Clients: Claude Code, Cursor, Windsurf, Cline, OpenCode, anything that uses Anthropic format.

Providers: Anthropic API, AWS Bedrock, Google Vertex, OpenAI-compatible, anything that accepts Anthropic format.

You don't need a specific provider. Point it at whatever you're already using.

Why Not Just Use RTK?

RTK (if you're using it) solves a different problem:

	Dynamic Tool Proxy	RTK
What it filters	Tool definitions (schemas)	Tool outputs (results)
When it filters	Before request sends	After tool runs
Savings	~12k tokens per request	Varies by output size

They're complementary. Use both for maximum savings.

What I Learned

1. Most developers don't check their token usage

They see the bill and accept it. They don't realize they're paying to send unused schemas to the model.

2. The biggest win is boring

It's just filtering a list. No LLM calls. No complex logic. Just "do you need this tool? no? remove it."

3. Local-first wins for developer tools

Developers want control. They want to see what's happening. They don't want another SaaS account with another API key.

4. Regex is enough

I thought I'd need LLM classification. I don't. Regex catches 90% of cases. Ambiguous messages fall back to full tool set. No quality loss.

Try It

GitHub: https://github.com/dvcoolarun/dynamic-tool-proxy

MIT license. Free forever. Your data stays local.

Star it if this saves you money.

Questions?

Drop a comment. I'll answer every one.

Edit: Added streaming support. The proxy now passes through SSE streams unchanged.