When render_template arrived, we said the markdown endpoint would stay REST-only — different input shape, separate decision. That decision never got made, and the gap it left was the same one render_template had been added to fix: an agent connected over MCP could check a markdown document with validate_markdown, then had to leave MCP entirely and run a curl /api/v1/md to get the actual PDF.
What's new
render_markdown is now an MCP tool. Pass GitHub-flavored markdown, get back a real PDF as a base64 resource on the response, PDF/A-2A and PDF/UA-1 dual-compliant like every other render.
It takes the same options as POST /api/v1/md — pageSize, fontFamily, fontSize, margins, theme, splitMode, and the document metadata fields (title, author, subject, keywords). Anything you leave out falls back to YAML frontmatter in the markdown itself, then to the defaults.
Billing matches the REST endpoint exactly: 1 credit per 10 pages, free-plan output watermarked, paid plans clean, and the render lands in your /settings/renders history. The cost comes back in the response metadata — creditsDeducted, creditsRemaining, pageCount, artifactId — so an agent can tell you what it just spent.
The recommended loop
validate_markdown— free, catches heading-hierarchy and alt-text problems.- Fix whatever it reports.
render_markdown— produces the deliverable.
There's no free markdown preview step, and that's deliberate rather than an omission. The DSL path has render_dsl_preview because templates need layout iteration; markdown doesn't. validate_markdown is the free pre-flight, and it catches the accessibility problems that are actually worth catching before you pay to render.
Nothing to reconfigure
Existing MCP clients pick the tool up the next time they list tools. The full table is at /docs/mcp.