MCP server for document generation with Runstamp

Runstamp's MCP server exposes a single generate_document tool that accepts a JSON object and returns a PPTX, DOCX, PDF, or XLSX file. One tool call, one JSON schema, one document. This is fundamentally different from other document MCP servers, which expose 30–50 imperative tools that the AI must call sequentially — add_slide(), add_text(), add_chart() — to build a document piece by piece.

What does the MCP document generation landscape look like in 2026?

The Model Context Protocol has enabled a growing ecosystem of document generation tools. According to PulseMCP's server directory, there are now 15+ MCP servers

for PowerPoint alone. The landscape splits into three categories.

Imperative PPTX servers expose individual tools for each slide operation. According to Office-PowerPoint-MCP-Server, the most mature open-source option, version 2.0 provides 32 tools organized into 11 modules — presentation management, content creation, structural operations, professional templates, charts, connectors, transitions, and more. It uses python-pptx under the hood and runs via uvx. Building a 10-slide presentation requires roughly 30–50 sequential tool calls.

Commercial MCP servers like Plus AI offer template-based generation with professional designs, SOC 2 Type II compliance, and integration with Google Slides. According to Plus AI's documentation, users report that it is "the only PowerPoint API we tested that can create native PowerPoint files using our template."

Template-based multi-format servers like Carbone MCP and mcp-ms-office-documents merge JSON data into pre-designed templates. These produce PPTX, DOCX, XLSX, and email files. According to the mcp-ms-office-documents README, it runs in Docker and generates "real Office files on demand" from templates with placeholder syntax.

Runstamp's MCP server is none of these. It is a declarative, single-tool, multi-format server — the AI produces one JSON object, and one tool call produces one complete document in any supported format.

Why is the imperative tool call a problem?

When an AI agent builds a presentation using imperative MCP tools, the conversation looks like this:

// tool call 1
create_presentation()           → presentation_id

// tool call 2
add_slide(layout_index: 0)      → slide_index: 0

// tool call 3
add_text(slide: 0, text: "Q3 Report", x: 1, y: 1)

// tool call 4
add_text(slide: 0, text: "Confidential", x: 1, y: 5)

// tool call 5
add_slide(layout_index: 1)      → slide_index: 1

// tool call 6
add_chart(slide: 1, type: "bar", ...)

// ... 24 more tool calls ...

// tool call 30
save_presentation(path: "report.pptx")

This pattern has three problems:

• Latency. Each tool call is a round-trip between the LLM and the MCP server. A 30-call sequence adds significant wall-clock time — especially when the LLM needs to reason about the result of each call before making the next one.
• Error propagation. If tool call #18 fails (invalid chart data, wrong slide index), the AI must diagnose the error from the tool's response, decide whether to retry or adjust, and continue the sequence. State management across 30 calls is fragile.
• No holistic planning. The AI commits to the document structure incrementally. It cannot look at the complete document, realize slide 3 should come before slide 2, and rearrange — it already called add_slide() in the wrong order. With a JSON schema, the AI can plan the entire document, review it, and adjust before a single tool call is made.

How does Runstamp's JSON-in, document-out approach work?

Runstamp's MCP server exposes two tools:

• generate_document — accepts a JSON schema and a format string ("pptx", "docx", "pdf", "xlsx"), returns the generated file
• get_schema_reference — returns the JSON schema documentation so the AI knows the available element types and properties

A complete document generation takes exactly 1 tool call. The AI produces the JSON schema as structured output, calls generate_document, and receives the file. No state management, no sequential dependencies, no partial failure recovery.

1. Setup: Claude Desktop

npm install -g @runstamp/mcp-server

Add the server to your Claude Desktop configuration:

{
  "mcpServers": {
    "paperjsx": {
      "command": "npx",
      "args": ["@runstamp/mcp-server"],
      "env": {
        "RUNSTAMP_LICENSE_KEY": "your-license-key"
      }
    }
  }
}

The lite PPTX, DOCX, PDF, and XLSX engines work without a paid license key. Set RUNSTAMP_LICENSE_KEY when you use paid Pro features. Restart Claude Desktop after saving the config file. You should see "paperjsx" appear in the MCP server list with two tools: generate_document and get_schema_reference.

2. Setup: Cursor

Cursor supports MCP servers via its settings panel.

{
  "mcpServers": {
    "paperjsx": {
      "command": "npx",
      "args": ["@runstamp/mcp-server"],
      "env": {
        "RUNSTAMP_LICENSE_KEY": "your-license-key"
      }
    }
  }
}

In Cursor, document generation integrates naturally into coding workflows. Ask Cursor to "generate a PPTX from the test results in coverage.json" or "create a PDF invoice from the order record in the database" — the agent reads your project files, assembles the JSON schema, and generates the document in one step.

Example prompts and outputs

Prompt: "create a 5-slide investor deck about our Q3 results"

Claude reads the available data (from context, files, or prior conversation), produces a JSON schema with 5 slides (title, problem, traction, financials, ask), calls generate_document with format: "pptx", and returns the file. The entire interaction is one user message, one LLM response with structured output, and one tool call.

Prompt: "generate a PDF invoice for order #4521"

The agent queries the order data (from a connected database MCP, a file, or context), assembles a JSON schema with company header, line items table, and total, calls generate_document with format: "pdf", and returns the invoice.

Prompt: "export the dashboard data as an Excel file with charts"

The agent structures the dashboard data into the JSON schema's sheet/chart/table format, calls generate_document with format: "xlsx", and produces an Excel file with native editable charts — not images. Recipients can click the charts and modify the data in Excel.

In every case, the AI's job is to produce a JSON object. It never needs to learn library-specific APIs, manage slide indices, handle file I/O, or orchestrate sequential state changes. JSON is the native output format for LLMs — they produce it reliably through function calling and structured outputs.

How do MCP servers for document generation compare?

The critical difference is not feature count — it is the interaction model. Imperative servers ask the AI to be a programmer, making sequential API calls with state management. Declarative servers ask the AI to be a data producer, outputting one structured object. LLMs are better at the latter.

According to our analysis of PPTX repair dialog causes, AI-generated raw OOXML consistently triggers PowerPoint's repair dialog (OpenAI Codex issue #16315). The imperative MCP approach mitigates this by using python-pptx or PptxGenJS as intermediaries. Runstamp's approach eliminates it entirely — the AI never produces OOXML, only JSON.