When the MCP server first shipped, the billed render endpoint was deliberately left out — the worry was that an agent in a loop could quietly burn through credits with no human in the loop. In practice that decision turned the agent flow into a half-loop: validate, preview (watermarked), save… then leave MCP and run a curl /api/v1/render to get the actual deliverable. That's friction in the one step that matters most.
What's new
render_template is now an MCP tool. It mirrors POST /api/v1/render with the { templateId, data } body shape — render a user-owned saved template (created via save_template or forked from the library) and get back a real PDF as a base64 resource on the response.
The cost is explicit, both in the tool description (which calls out "1 credit per 10 pages" up front) and in the JSON metadata block returned alongside the PDF: creditsDeducted, creditsRemaining, pageCount, and the artifact ID. An agent that wants to be a good citizen can read those and tell the human exactly what the render cost before continuing.
How to use it
The recommended loop is now:
- Ask the agent to draft DSL and call
validate_dsluntil it's clean. render_dsl_previewto eyeball the layout — free, watermarked, no credits charged.save_templateonce you're confident.render_templatewith real data to produce the deliverable.
Output behaviour matches /api/v1/render exactly: free-plan callers get the standard plan watermark, paid plans render clean. The artifact lands in your /settings/renders history just like a REST-driven render.
What's still REST-only
The markdown endpoint (/api/v1/md) stays REST-only for now. It's billed too but the input shape is fundamentally different — markdown body, frontmatter options — and it doesn't share the author → save → render loop with the DSL pipeline. Different question, separate decision.
Setup hasn't changed: existing MCP clients (Claude Desktop, Claude Code, Cursor) pick up the new tool the next time they list tools. See /docs/mcp for the full tool table.