kove

← All posts

PDF generation for AI apps: API, CLI, or MCP

kove is a hosted document API. The HTTP API is the main way in. The CLI is for local and CI, and MCP is for runtime agents. Here is when to pick each.

ai-appsapiclimcppdf

If your app uses AI to produce documents, invoices, reports, contracts, summaries, you need a reliable way to turn that output into a PDF. kove is a hosted document API: you send a JSON document, we render the PDF, and you run none of the infrastructure. The API is the main surface. There are two more, the CLI and MCP, that take the same document for cases where the work happens somewhere else. This post covers all three and when to pick each.

One document, three doors

Whatever surface you use, the document is identical. It is a JSON description of what goes in the PDF:

{
  "page": { "size": "A4" },
  "footer": { "pageNumbers": "Page {page} of {pages}" },
  "body": [
    { "type": "heading", "text": "Quarterly report" },
    { "type": "text", "text": "Revenue grew across all regions." },
    { "type": "table",
      "columns": ["Region", "Q1", "Q2"],
      "rows": [["EU", "$1.2M", "$1.5M"], ["US", "$2.1M", "$2.4M"]] }
  ]
}

Because the document does not change, you can prototype on the CLI, ship on the API, and let an agent drive MCP, all without rewriting anything. Pick the door, not a different house.

API: the main surface

Most apps generate documents from their backend, so the HTTP API is where you will spend most of your time. When the PDF is part of a live product flow, like emailing an invoice after a payment or letting a user download a report, call the API with a Bearer key:

Terminal window
curl -X POST https://api.kove.dev/v1/documents \
  -H "Authorization: Bearer $KOVE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @report.json \
  -o report.pdf

Use the API when:

  • The document is generated by your server in response to a user action.
  • You want managed rendering with nothing to run or scale yourself.
  • You need it to work the same way every time, under load, in production.

This is the hosted path, and it is the point of kove. There is no rendering server in your stack and no headless browser in your deploy. You send JSON, you get a PDF. It is pay-per-use: free to start, then you pay only for the PDFs you make.

The best part is how it gets into your app. kove ships AI-friendly docs: an llms.txt index, an OpenAPI spec, and the simple JSON model above. So you do not have to write the integration by hand. Tell your coding agent “add PDF invoices to my checkout” and it reads the spec, writes the call, wires in the key and the data, and hands you a diff to review. You ship the feature and barely notice there is an external provider behind it.

CLI: local and CI

The CLI runs on a machine you control. Local render is free and unlimited, no account, no card. That makes it the place to build and the place to run batch jobs.

Terminal window
npx kove validate report.json
npx kove render report.json -o report.pdf

Use the CLI when:

  • You are building and want a tight loop with no signup.
  • You have a script, a cron task, or a CI step that makes documents on a machine you control.
  • You want to test the layout of a document before wiring it into your app.

validate checks the JSON without rendering, so a typo fails fast and cheap. render produces the PDF. When you later want managed cloud rendering, npx kove login connects your account, but for local work you do not need it.

MCP: for runtime agents

MCP is the surface for products that are themselves agents at runtime. If your app is an agent, or you use one like Claude Code, add kove once and the agent gets real tools:

Terminal window
claude mcp add kove -- npx @kove/mcp

That gives the agent validate_document, render_document, login, upgrade, and account_status. The agent writes the document, validates it, and renders it by calling tools directly. No shelling out, no glue code.

Use MCP when:

  • Your product is agent-driven and the agent should own the full loop at runtime.
  • You are building on an agent tool already and want PDF output as a native capability.

Note the difference from using an agent to build your integration. A coding agent uses the docs to write a normal API call into your app once. MCP is for an agent that renders documents every time it runs. Most teams want the first. MCP is for when the agent itself is the product.

How to choose

A simple way to decide:

  • Generating documents from your app’s backend? Use the API. It is hosted and pay-per-use, and your coding agent can wire it in for you.
  • Building or scripting on your own machine? Use the CLI. It is free and instant.
  • Shipping a product that is an agent at runtime? Use MCP. The agent renders through native tools.

Many teams use more than one. You prototype a new document type on the CLI for free, ship it through the API in production, and expose it to a runtime agent over MCP, all from the same JSON. Because the document model never changes, moving between surfaces is just choosing where the call happens, not rebuilding the document.

Start with the API. It is the one most apps need, and your agent can add it for you.