Carbone MCP
OfficialThe Carbone MCP Server enables AI assistants to automate document generation, conversion, and template management. Here's what you can do:
Convert Documents: Transform files between 100+ format combinations (DOCX → PDF, XLSX → CSV, HTML → PNG, MD → PDF, etc.) using LibreOffice, OnlyOffice, or Chromium engines — no template required.
Generate Documents from Templates: Merge JSON data into templates using
{d.field}tags to produce dynamic documents with loops, conditionals, localization, currency conversion, and batch generation.Advanced PDF Features: Apply watermarks, password protection, PDF/A compliance, and page range exports.
Batch Generation: Create hundreds of documents in a single request, optionally bundled as a ZIP archive, with async webhook support.
Manage Templates: Upload, version, categorize, tag, search, update metadata, download, and delete reusable templates (DOCX, XLSX, PPTX, HTML, PDF, etc.).
Browse Your Library: List templates with filtering by ID, category, tag, or fuzzy search; retrieve all available categories and tags across your account.
Localization: Support multi-language rendering, timezone handling, and currency conversion with exchange rates.
Monitor API Health: Check Carbone API status and version, and retrieve a full summary of supported formats, features, and tool usage examples.
Supports converting Markdown documents into professional formats like PDF using the Carbone conversion engine.
Utilizes OnlyOffice as a specialized conversion engine to ensure high-fidelity transformations for complex document formats.
Carbone MCP Server
Official Carbone MCP server — Turn AI assistants into document automation experts. Generate professional PDFs, invoices, reports, and more using natural language.
Give Claude, ChatGPT, and other AI assistants the power to:
🔄 Document Conversion — 100+ format combinations (PDF, DOCX, XLSX, PNG, HTML, CSV…)
📄 Template Engine — Generate documents from JSON data with
{d.field}tags📚 Template Library — Upload, version, categorize, and manage reusable templates
🎨 PDF Customization — Fill PDF forms, add watermarks, passwords, encryption, multiple converter engines (LibreOffice, OnlyOffice, Chromium, Carbone ICE)
🌍 Localization — Multi-language support, currency conversion, timezone handling
⚡ Batch Generation — Create hundreds of documents in one request (async via webhook)
Installation
Get your free API key at account.carbone.io.
stdio — Claude Desktop, VS Code, Cursor, Claude Code, and more
All stdio-compatible MCP clients use the same config:
{
"mcpServers": {
"carbone": {
"command": "npx",
"args": ["-y", "carbone-mcp"],
"env": {
"CARBONE_API_KEY": "your_api_key_here"
}
}
}
}Client | Config file |
Claude Desktop (macOS) |
|
Claude Desktop (Windows) |
|
Cursor (global) |
|
Cursor (project) |
|
Claude Code |
|
VS Code uses
{ "mcp": { "servers": { ... } } }instead of{ "mcpServers": { ... } }— the inner config block is identical.
After adding the config, restart your client and try: "What can Carbone do?"
HTTP — mcp.carbone.io (no local installation)
Connect directly to the hosted endpoint. Supported by VS Code, Cursor, Claude Code, and other clients that support streamable HTTP transport.
{
"mcp": {
"servers": {
"carbone": {
"type": "streamable-http",
"url": "https://mcp.carbone.io",
"headers": {
"Authorization": "Bearer your_api_key_here"
}
}
}
}
}Authentication: The HTTP endpoint currently requires a Carbone API key passed as a Bearer token in the
Authorizationheader. OAuth2 support (for Claude Desktop, Mistral, ChatGPT, Gemini, and other clients) is planned for a future release.Cursor uses
{ "mcpServers": { ... } }instead of{ "mcp": { "servers": { ... } } }— the inner config block is identical.Claude Desktop does not support HTTP Bearer token authentication — use the stdio option above instead.
Docker — self-hosted HTTP server
docker run -d -p 3000:3000 \
-e MCP_TRANSPORT=http \
-e CARBONE_API_KEY=your_api_key_here \
carbone/carbone-mcpConnect your MCP client to http://your-host:3000 using the HTTP config above (replace the URL).
Docker Compose — see compose.yml:
CARBONE_API_KEY=your_key docker compose up -dClaude Desktop with Docker (stdio) — Claude Desktop does not support HTTP transport; use the stdio mode instead:
{
"mcpServers": {
"carbone": {
"command": "docker",
"args": ["run", "-i", "--rm",
"-e", "CARBONE_API_KEY=your_api_key_here",
"-e", "MCP_TRANSPORT=stdio",
"carbone/carbone-mcp"]
}
}
}On-Premise — self-hosted Carbone instance
If you run Carbone on-premise, point the MCP server at your instance — no API key required:
# Docker (HTTP)
docker run -d -p 3000:3000 \
-e CARBONE_BASE_URL=https://your-carbone-server.com \
carbone/carbone-mcp
# stdio
CARBONE_BASE_URL=https://your-carbone-server.com npx carbone-mcpRelated MCP server: docx-forge-mcp
Environment Variables
Required (stdio mode, cloud API):
CARBONE_API_KEY— Your Carbone API key (get one free →). Not required whenCARBONE_BASE_URLpoints to your own on-premise server, or when running in HTTP mode (clients supply their own key viaAuthorization: Bearer).
Variable | Default | Description |
|
| Override for self-hosted or staging environments. When set to a custom URL, |
|
| Request timeout in milliseconds (max: 60000) |
|
| Maximum size (bytes) for a resolved input file — path, URL, or base64 (100 MB default) |
|
| Transport mode: |
|
| HTTP server port (only used when |
|
| HTTP endpoint path (only used when |
|
| Maximum request body size in bytes (60 MB default, matching Carbone Cloud limit) |
|
| HTTP mode only — require |
|
| Allow user-supplied URLs (templates, |
Available Tools
Document Operations
Tool | Description | Docs |
| Convert documents between 100+ formats without storing a template | |
| Generate documents from templates by merging with JSON data |
Template Management
Tool | Description | Docs |
| Browse your template library with filtering by category or search (tags are returned per template but not filterable server-side) | |
| List all template categories in your account | |
| List all tags used across your templates | |
| Store reusable templates with versioning, categorization, and metadata | |
| Rename, categorize, tag, deploy, or expire template versions | |
| Soft-delete templates (marked for removal, gone after ~24h) | |
| Download original template files (DOCX, XLSX, PDF, etc.) |
Discovery
Tool | Description | Docs |
| Check Carbone API health and current version | |
| View all supported formats, features, and examples |
📖 Full API Reference → — Detailed parameters, schemas, and examples
Output & File Delivery
By default, a generated or converted file is returned based on its type and transport:
Output | stdio (local clients) | HTTP (remote / self-hosted) |
Text — HTML, TXT, CSV, MD, XML | inline text | inline text |
Inline images — PNG, JPG, GIF, WEBP | inline image | inline image |
Everything else — PDF, Office, ZIP, SVG… | saved to a temp file, path returned | returned as a download attachment |
Three optional parameters on convert_document and render_document (and outputPath / asAttachment on download_template) override this:
Parameter | Effect |
| stdio only — save the output to this local path instead of returning it inline (rejected in HTTP mode) |
| return the bytes as a downloadable attachment for any format, instead of inline |
| return Carbone's public one-time download URL instead of the file — short-lived and consumed by the first download, so hand it to the user rather than fetching it yourself (works in stdio and HTTP) |
Claude Desktop: it cannot render inline binary attachments (it mishandles them as images). For PDFs and Office files, rely on the default stdio temp-file path, or use
returnLinkto get a download URL.
Common Use Cases
📄 Document Conversion
"Convert this Word document to PDF: /path/to/contract.docx"
"Turn my Excel spreadsheet into CSV format"
"Convert this HTML page to a PNG image"
"Convert my Markdown README to PDF"
"Convert this PPTX to PNG — use OnlyOffice for best fidelity"
"Convert this 500-page Word report to PDF — use the ICE converter, it's much faster"
"Rasterize this PDF to PNG images — one per page"💼 Finance & Invoicing
"Generate an invoice using template T123 with: {customer: 'Acme Corp', total: 1500, items: [...]}"
"Generate invoices from the data in /data/invoices.json"
"Create 500 invoices from my billing data and bundle them in a ZIP"
"Generate a French invoice for my Paris client — use EUR currency and fr-fr locale"
"Render this monthly report for each client in clients.json and ZIP them all"
"Generate invoice-{d.id}.pdf for each row in my sales data"⚖️ Legal & Compliance
"Add a CONFIDENTIAL watermark to this contract before sending it"
"Convert this NDA to PDF/A format for long-term archiving"
"Generate a password-protected PDF — open password: 'secret123'"
"Create signed offer letters for each candidate using this DOCX template"
"Generate a compliance report with a DRAFT watermark, 20% opacity, rotated -45°"👥 HR & People Operations
"Create personalized onboarding documents for all 50 new employees in this JSON"
"Generate an employment contract for each person in new-hires.json"
"Build payslips for every employee in my payroll export"
"Create training certificates for everyone who passed this month"
"Fill out the performance review template with each employee's data"🌍 Localization & Multi-Language
"Generate this invoice in French, German, and Spanish from the same template"
"Render the report with timezone America/New_York so dates show in Eastern time"
"Convert all prices from EUR to USD using today's exchange rates"
"Generate the contract in fr-fr locale so numbers use European formatting"🔐 PDF Security & Advanced Options
"Convert this DOCX to a password-protected PDF"
"Add a semi-transparent DRAFT watermark to every page"
"Generate a PDF/A-1b compliant version of this document for archiving"
"Export only pages 1–5 of this presentation as a PDF"
"Convert each slide of this PPTX to a separate PDF page"📚 Template Management
"Upload this invoice template and tag it 'sales' and 'finance'"
"What templates do I have in the 'contracts' category?"
"Show me all templates tagged 'hr'"
"Download template T456 so I can edit it locally"
"Deploy version V789 as the active version without deleting the others"
"Schedule this old template for deletion in 30 days"Debugging
Using MCP Inspector
Test and debug the server interactively:
npx @modelcontextprotocol/inspector npx carbone-mcpOr from a local build:
npx @modelcontextprotocol/inspector node dist/index.jsOpen http://localhost:5173 to view all tools, test calls, and inspect request/response JSON — no AI inference needed.
View Server Logs
# macOS — Claude Desktop logs
tail -f ~/Library/Logs/Claude/mcp*.log
# Windows
Get-Content "$env:APPDATA\Claude\logs\mcp*.log" -Wait -Tail 50Look for:
✅
Carbone MCP Server v1.x.x started (stdio)❌ Any error messages or stack traces
Health Check (HTTP mode only)
When running in HTTP mode, the server exposes a health endpoint:
curl http://localhost:3000/health{
"mcp": { "version": "1.2.2" },
"carbone": { "version": "5.x.x" }
}The carbone field shows backend connectivity:
{ "version": "..." }— reachable and authenticated{ "error": "unauthorized", "message": "..." }— reachable but no/invalid API key{ "error": "unreachable", "message": "..." }— network error, timeout, or unexpected response
Security
⚠️ File and URL inputs (SSRF / local files)
Tools accept a local path, an HTTPS URL, or base64 for file / template and the by-reference JSON params (data, complement, …). Two guards apply:
URLs are resolved and refused when they point at loopback, private (RFC1918), link-local (incl. cloud metadata
169.254.169.254), CGNAT or reserved addresses — and every redirect hop is re-checked. SetCARBONE_ALLOW_PRIVATE_NETWORK=trueonly on a trusted deployment that needs internal template hosts.Local paths are readable in stdio only, where the server already runs as you. In HTTP mode they are refused, so a remote caller can never make the server read its own filesystem.
⚠️ Sharing a server-level API key (HTTP mode)
If you set CARBONE_API_KEY on an HTTP server and leave CARBONE_REQUIRE_CLIENT_AUTH_HEADER=false (the default), requests without a Bearer key fall back to that key — anyone who can reach the port can spend that Carbone account. Set it to true to require each client to bring its own key, or only expose the port on a trusted network. (Not applicable when no server key is set, e.g. on-premise Carbone without authentication.)
⚠️ Prompt Injection Connecting an AI assistant to any external service carries inherent risks. A malicious document or template could contain instructions that trick the AI into performing unintended actions (e.g. exfiltrating data, deleting templates). Always review what your AI client is about to do before confirming tool calls.
⚠️ API Key Protection
Never commit
CARBONE_API_KEYto version controlUse environment variables or a secret manager
Rotate API keys regularly at account.carbone.io
⚠️ Template Safety
Only upload templates from trusted sources
Review templates before deploying them
Use template versioning for easy rollback
⚠️ Data Privacy
Carbone does not store your document data after rendering
Use
CARBONE_BASE_URLto point to a self-hosted instance for maximum controlSee Privacy Policy for details
Template Syntax
Design templates in Word, Excel, LibreOffice, or HTML with {d.field} tags:
Dear {d.customer.name},
Your invoice total is {d.total:formatC(EUR)}.
Items:
{d.items[i].description} {d.items[i].quantity}x {d.items[i].price:formatC(EUR)}
{d.items[i+1]}Guides & best practices:
Carbone Skill — Universal Carbone Templating syntax reference for AI tools (download .skill · GitHub)
Supported Output Formats
Category | Formats |
Documents | PDF, DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, RTF, EPUB |
Images | PNG, JPG, WEBP, SVG, TIFF, BMP, GIF |
Web / Text | HTML, TXT, CSV, MD, XML |
Full conversion matrix: carbone.io/documentation
Contributing
We welcome contributions:
🐛 Report bugs via GitHub Issues
💡 Request features or suggest improvements
📝 Improve documentation
🧪 Add tests to increase coverage
🔧 Submit pull requests with bug fixes or enhancements
See CONTRIBUTING.md for guidelines.
Development
npm run dev # Run with tsx (no build needed)
npm run build # Compile TypeScript → dist/
npm test # Run the test suite (integration tests run only with CARBONE_TEST_API_KEY)
npm run test:watch # Watch mode
npm run test:integration # Real API tests (requires CARBONE_TEST_API_KEY)
npm run test:coverage # Coverage reportSupport
🤖 MCP Documentation: carbone.io/documentation/developer/ai/mcp.html
📚 API Documentation: carbone.io/documentation/developer/http-api/introduction.html
📚 Templating Documentation: carbone.io/documentation/design/overview/getting-started.html
🐛 Bug Reports: GitHub Issues
💬 Live Chat: carbone.io (bottom-right widget)
📧 Enterprise: contact@carbone.io
📋 OpenAPI specification: carbone.OpenAPI.yml
License
Apache 2.0 — see LICENSE
Available Tools
11 toolsconvert_documentConvert DocumentARead-onlyIdempotentInspect
Convert any document to another format without storing a template. Supports 100+ input/output format combinations: Office documents, PDFs, images, web pages, spreadsheets, and more. The source file can be a local path, a URL, or a base64 string. Carbone tags are PRESERVED, not resolved: converting a template keeps every {d.field} intact, so this is also how you proof a template in another format (DOCX template → PDF, or DOCX → ODT while it stays a template). Use render_document instead when you need data injection ({d.field} tags resolved), translations, or batch generation. Common conversions: DOCX → PDF (file: "report.docx", convertTo: "pdf"; add converter: "I" for the fastest DOCX→PDF path), XLSX → PDF (file: "data.xlsx", convertTo: "pdf"), PPTX → PDF (file: "slides.pptx", convertTo: "pdf", converter: "O" for best fidelity), HTML → PDF (file: "page.html", convertTo: "pdf", converter: "C" for full CSS/JS rendering), DOCX → HTML (file: "doc.docx", convertTo: "html"), XLSX → CSV (file: "sheet.xlsx", convertTo: "csv"), PDF → PNG (file: "doc.pdf", convertTo: "png"), PPTX → PNG (first slide as image), MD → PDF (file: "readme.md", convertTo: "pdf").
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | The document to convert. Three input forms are accepted: (1) Local file path — absolute or relative, e.g. "/home/user/report.docx" or "./invoice.xlsx". (2) HTTPS URL — the file is downloaded automatically, e.g. "https://example.com/file.pptx". (3) Base64-encoded string — the raw file content encoded as base64. Supported input formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, XML, SVG, IDML, Markdown (MD), TXT, CSV, RTF, PDF, PNG and JPG. Carbone reads XML-based and text-based documents only, so the legacy BINARY Office formats DOC, XLS and PPT are REJECTED as input — Carbone can produce them as output but cannot read them. Re-save such a file as DOCX/XLSX/PPTX first. Full conversion matrix: https://carbone.io/documentation/developer/http-api/generate-reports.md | |
| convertTo | Yes | Target output format. Documents : "pdf", "docx", "xlsx", "pptx", "odt", "ods", "odp", "odg", "rtf", "epub", plus the legacy "doc", "xls", "ppt" (output only — Carbone writes them but cannot read them back). Web/text : "html", "xhtml", "txt", "csv", "md", "xml", "idml". Images : "png", "jpg", "jpeg", "webp", "svg", "tiff", "bmp", "gif". Archive : "zip" (batch output). Simple usage: "pdf". Advanced usage: { "formatName": "pdf", "formatOptions": { "EncryptFile": true, "DocumentOpenPassword": "secret" } }. | |
| converter | No | Converter engine. Only relevant when convertTo is "pdf" (or an image format rasterised from a document). "L" — LibreOffice (default): best all-round engine for DOCX, XLSX, PPTX, ODT, ODS, ODP. "O" — OnlyOffice: highest fidelity rendering for Microsoft Office formats (DOCX, XLSX, PPTX). "C" — Chromium: best for HTML, CSS, JavaScript — full browser rendering. "I" — Carbone ICE (Instant Converter Engine, Carbone 5.14.0+): DOCX → PDF ONLY, no third-party converter — up to 60x faster than LibreOffice on a 1000-page DOCX (3x on a one-page document). Any other input or output format is REJECTED — use another converter for those. PDF options: only Watermarks are applied. EncryptFile, DocumentOpenPassword, RestrictPermissions and the other security options are SILENTLY IGNORED — the PDF comes back readable by anyone, with no error — so NEVER pick "I" when the request needs a password or restricted permissions; use "L" for those. Also unsupported: WEBP and EMF/WMF images, table of contents, SmartArt, complex charts, footnotes/endnotes, comments, tracked changes, form fields, equations, bookmarks and links; a missing font falls back to Noto Sans. If omitted, LibreOffice is used by default. | |
| outputPath | No | Optional local file path to save the converted document to (e.g. "/home/user/out.pdf" or "~/out.pdf"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the document inline — ideal for large files. | |
| reportName | No | Filename (WITHOUT extension) for the converted document, returned in the Content-Disposition header. Carbone appends the extension matching convertTo, so do not include one — "report.pdf" yields "report.pdf.pdf". Examples: "contract", "2026-invoice". Unlike render_document, Carbone tags are NOT resolved here (conversion does not run templating), so pass a literal name rather than a pattern like "{d.id}" — a pattern would come back verbatim. Ignored when returnLink is set, which returns a download URL rather than a named file. | |
| returnLink | No | If true, generate the document and return a public download URL instead of the file contents. The link is SHORT-LIVED and ONE-TIME — Carbone deletes the file after the first download — so it is meant for the end user to download once (do not fetch it programmatically). Works in stdio and HTTP. Mutually exclusive with outputPath and asAttachment. | |
| hardRefresh | No | Forces Carbone to run the converter even when the output format already matches the input format. Only useful for PDF: converting PDF → PDF to APPLY formatOptions (watermark, password, PDF/A, page range). Without it Carbone may pass the file straight through and none of those options take effect. Leave unset for any format-changing conversion (DOCX → PDF, XLSX → CSV, …), where the converter runs anyway. | |
| asAttachment | No | If true, return the document as a downloadable file attachment (a base64 EmbeddedResource), for any format. Default delivery: text and png/jpg/gif/webp are returned inline; other binary outputs (PDF, Office, …) are saved to a temp file in stdio mode (path returned), or returned as an attachment in HTTP mode. Ignored when outputPath or returnLink is set. | |
| egressAuthorization | No | Value for the Authorization header Carbone adds to its OUTBOUND (egress) requests during conversion — e.g. when a Chromium HTML→PDF conversion fetches a protected external image or stylesheet. For example "Bearer abc123" makes Carbone send `authorization: Bearer abc123` to those hosts. Only the authorization header can be customised; max 512 characters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint, openWorldHint, and idempotentHint. The description adds significant behavioral detail: it clarifies that tags are NOT resolved, describes the ICE engine's limitations (e.g., silently ignoring password options), explains returnLink's short-lived one-time nature, and notes outputPath behavior. This goes well beyond the annotations and is transparent about side effects and caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although lengthy, every sentence carries unique value. The structure is logical: general purpose → input forms → format lists → converter details → parameter walkthrough. It front-loads the core intent and uses bullet-like formatting within prose to keep information scannable. No redundancy or filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters including nested objects and enums), the description covers all necessary aspects: supported input/output formats, converter engine trade-offs, security warnings, edge cases (like ICE ignoring PDF options), and delivery mechanisms. It even points to a full conversion matrix URL. There is no missing information a user would need to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a detailed description. The description adds depth: it explains the three input forms for 'file' (path, URL, base64), the meaning of each converter enum value, the formatOptions examples for PDF and images, and the reportName extension pitfall. This substantially enriches the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Convert any document to another format without storing a template.' It specifies the verb (convert), the resource (document), and the scope (format transformation). It also distinguishes itself from the sibling render_document by noting that Carbone tags are preserved, not resolved, which makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with render_document: 'Use render_document instead when you need data injection, translations, or batch generation.' It also provides guidance on converter engine selection (L, O, C, I) and notes when hardRefresh is needed (PDF→PDF with formatOptions). This leaves no ambiguity about when to choose this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_templateDelete TemplateADestructiveIdempotentInspect
Delete a stored Carbone template. This is a soft delete: the template is marked for garbage collection and removed after a delay (default 24 hours). You can delete by Template ID (removes all versions) or by Version ID (removes only that specific version). For immediate or scheduled deletion, use update_template_metadata with expireAt = 42000000000 (NOW) or a future Unix timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| templateId | Yes | Template ID (64-bit) or Version ID (SHA-256) to delete. Template ID — deletes the template record and all its versions. Version ID — deletes only that specific version, leaving other versions intact. Both formats are returned by upload_template and list_templates. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds crucial details: it is a soft delete with a 24-hour garbage collection delay, and explains the two deletion modes (template vs version). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences. First sentence states the action and soft-delete nature. Second sentence provides the alternative usage. No unnecessary words, well-front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers all essential aspects: operation, behavior (soft delete, delay), two input modes, and an explicit alternative for different timing needs. It is complete and does not leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds meaning beyond the schema by explaining the effect of each ID type: 'removes all versions' vs 'removes only that specific version', and notes that both formats are returned by other tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a stored Carbone template' with a specific verb and resource. It distinguishes between deleting by Template ID (removes all versions) and Version ID (removes specific version), setting it apart from sibling tools like update_template_metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: for soft deletion with default delay. It explicitly names an alternative for immediate or scheduled deletion ('use update_template_metadata with expireAt'), but does not explicitly state when not to use this tool beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
download_templateDownload TemplateARead-onlyIdempotentInspect
Download the original source file of a stored Carbone template (e.g. the DOCX, XLSX, PPTX, or HTML file that was uploaded). Use this to inspect, edit, or back up a template. Pass a Template ID to download the currently deployed version, or a Version ID to download a specific version. Set sample:true to fetch the JSON sample dataset stored with the template instead of the template file itself.
| Name | Required | Description | Default |
|---|---|---|---|
| sample | No | If true, download the JSON SAMPLE DATASET saved with the template (the "sample" array passed to upload_template) instead of the template file. Returns JSON of the form [{ "data": {...}, "complement": {...}, "translations": {...}, "enum": {...} }]. Use it to recover the example data a template expects — handy before calling render_document against an unfamiliar template. Errors if the template was uploaded without a sample. | |
| outputPath | No | Optional local file path to save the template file to (e.g. "/home/user/out.pdf" or "~/out.pdf"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the document inline — ideal for large files. | |
| templateId | Yes | Template ID (64-bit) or Version ID (SHA-256) to download. Template ID — downloads the currently deployed version of the template. Version ID — downloads that exact version regardless of deployment status. Both formats are returned by upload_template and list_templates. | |
| asAttachment | No | If true, return the template as a downloadable file attachment (base64 resource) instead of inline text/image. Useful in HTTP mode where outputPath is unavailable. Default: false. Ignored when outputPath is set. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds valuable behavioral context beyond that: the distinction between template and version IDs, the side effect of outputPath writing to disk, the asAttachment behavior, and the behavior when sample:true is set (errors if no sample exists). This exceeds what annotations provide and helps the agent anticipate outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first sentence names the purpose and file types, the second covers the version/sample options. Every clause earns its place—no fluff, no repetition of schema fields. The core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and rich annotations, the description covers all key behavioral variations: template vs version selection, sample download, outputPath side effects, and asAttachment fallback. Nothing an agent needs to correctly invoke this tool is missing—including error conditions for missing samples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds marginal value by restating the template/version distinction in prose, but it does not introduce new semantics beyond the schema. Per the rubric, a baseline of 3 is appropriate when the schema carries the full parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Download the original source file of a stored Carbone template' and lists the file types (DOCX, XLSX, PPTX, HTML). It clearly distinguishes from siblings like render_document (which generates outputs) and upload_template (which creates templates). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: 'Use this to inspect, edit, or back up a template.' It differentiates between downloading the deployed version vs a specific version, and explains the sample option. However, it does not explicitly name alternative tools or state when NOT to use this tool, leaving some inference to the agent. Still, the guidance is specific and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_api_statusAPI StatusARead-onlyIdempotentInspect
Check Carbone API health and version. Returns the current API version and a status message. Useful for verifying connectivity and confirming which Carbone version is active.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | Status message returned by the API. |
| version | Yes | The running Carbone API version. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that it returns 'the current API version and a status message', providing behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three concise, front-loaded sentences with no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health-check tool with no parameters and an output schema, the description covers purpose, return value, and use case completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description appropriately omits parameter details as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and the resource 'Carbone API health and version', clearly distinguishing it from sibling tools that deal with templates and documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is 'useful for verifying connectivity and confirming which Carbone version is active', providing clear usage context. It does not explicitly mention when not to use, but the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_capabilitiesCapabilitiesARead-onlyIdempotentInspect
Returns a summary of all Carbone capabilities: supported formats, features, tool usage examples, and links to full documentation. Call this first if you are unsure what Carbone can do.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds context about the content of the summary and usage prioritization, but no additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage guidance. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers the tool's purpose and usage guidance well. It mentions links to documentation but does not describe the return format; however, for a simple discovery tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema_description_coverage is 100% (trivially). The description adds no parameter info since none are needed. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a summary of Carbone capabilities, listing specific content like supported formats, features, examples, and links. This distinguishes it from siblings that perform specific operations (e.g., convert_document, render_document).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Call this first if you are unsure what Carbone can do.' It implies when to use, though no explicit when-not-to-use or alternatives are mentioned. Clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesList CategoriesARead-onlyIdempotentInspect
List all template categories currently in use in your Carbone account. Categories act like folders for organising templates (e.g. "invoices", "legal", "hr"). Use the returned names as the category filter in list_templates or upload_template.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| categories | Yes | Template category names in use. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context by explaining categories act as folders and providing examples (e.g., 'invoices'), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste. Front-loaded with the main action, then contextual usage. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description is complete: it explains what the tool does, why categories matter, and how to use the output. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description naturally has no parameter info. The schema coverage is 100%, meeting the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and resource 'categories', clearly stating it lists all template categories in use. It distinguishes from siblings like list_tags and list_templates by specifying 'categories' and noting their role as folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states how to use the returned names: as a category filter in list_templates or upload_template. While it doesn't mention when not to use it, this context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tagsList TagsARead-onlyIdempotentInspect
List all tags currently used across templates in your Carbone account. Tags are free-form labels attached to templates (e.g. "sales", "billing", "v2"). Note: the Carbone API does not support filtering list_templates by tag — use this tool to discover available tags, then call list_templates and filter the results manually.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| tags | Yes | Template tag names in use. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint; the description adds valuable context about tags being free-form and the filtering limitation, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a note; every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and good annotations, the description fully covers the tool's purpose, usage, and limitations. It also directs to the appropriate sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% (vacuous). Baseline is 4; no extra information needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists all tags used in templates, distinguishing this from related tools like list_categories and list_templates. Includes examples of tags and specifies the scope ('across templates').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool to discover tags, then call list_templates and filter manually because the API does not support filtering by tag. Provides a clear workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesList TemplatesARead-onlyIdempotentInspect
List stored Carbone templates with filtering, search, and pagination. Filter by Template ID, Version ID, category, or upload origin. Use includeVersions to see the full version history of each template. Supports cursor-based pagination for large collections. Note: filtering by tags is not supported by the Carbone API — use list_tags to discover tags, then filter results manually. Note: templates uploaded with versioning disabled appear with id = null and are identified only by their versionId — pass that versionId where a Template ID is expected (e.g. delete_template, download_template).
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Filter by Template ID (64-bit format). Cannot be a Version ID. | |
| limit | No | Maximum number of results to return, between 1 and 100. Default: 100. Use cursor to page beyond that. | |
| cursor | No | Pagination cursor from the previous response nextCursor field. Use to fetch the next page. | |
| origin | No | Filter by upload origin. 0 = API, 1 = Carbone Studio, 2 = Salesforce, 3 = Odoo, 4 = HubSpot. Templates created through this MCP are origin 0. | |
| search | No | Fuzzy search in template names, or exact match on Template ID / Version ID. | |
| category | No | Filter by category (e.g. "invoices", "legal"). | |
| versionId | No | Filter by Version ID (SHA-256 format). | |
| includeVersions | No | If true, returns all versions for each template. Default: false (only deployed version). |
Output Schema
| Name | Required | Description |
|---|---|---|
| hasMore | Yes | Whether more results are available via the cursor. |
| templates | Yes | The matching templates (all fields). |
| nextCursor | No | Cursor to pass to the next list_templates call. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely valuable behavioral context beyond that: cursor-based pagination mechanics, the tags API limitation, and the critical edge case that templates uploaded with versioning disabled appear with id = null and must be addressed via versionId in tools like delete_template and download_template. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six sentences, front-loaded with the core purpose before any caveats. Each sentence carries a distinct fact—scope, filter dimensions, includeVersions behavior, pagination, tags limitation, and the null-id edge case—so there is no filler. Slightly long, but the two 'Note:' caveats convey non-obvious API behavior and earn their space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with zero required params, the description covers the essential decisions: which filters exist, how to paginate large collections, when to include versions, what the API cannot do (tag filtering), and how to identify versioning-disabled templates, including cross-tool remediation. An output schema exists, so return-value shape is covered elsewhere. The only minor gap is filter-combination semantics (e.g., whether search and category compose), which is left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, setting a baseline of 3. The description rises above that by aggregating the filter dimensions ('Filter by Template ID, Version ID, category, or upload origin'), giving usage guidance for includeVersions ('full version history of each template'), and framing limit/cursor as a strategy for large collections. It adds selection and combination context the schema's individual parameter docs do not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List stored Carbone templates with filtering, search, and pagination' — a specific verb, resource, and capability set. It clearly distinguishes itself from siblings like list_categories and list_tags by targeting templates specifically, and it elaborates the title's bare 'List Templates' with scope ('stored') and operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operational context: filters (Template ID, Version ID, category, origin), cursor pagination for large collections, and when to use includeVersions. It also provides an explicit exclusion—'filtering by tags is not supported by the Carbone API — use list_tags to discover tags, then filter results manually'—which routes the agent to the correct sibling. It doesn't systematically address all sibling alternatives, but the guidance is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_documentGenerate DocumentARead-onlyIdempotentInspect
Generate a document by merging a Carbone template with JSON data. Two modes: (1) pass templateId to use a previously uploaded template; (2) pass template (file path, URL, or base64) to upload and render in a single request without storing a template. Supports output format conversion, multilingual rendering, currency conversion, batch generation, and advanced PDF options (watermark, password, PDF/A). Async mode: pass webhookUrl to render asynchronously — Carbone will POST the renderId to your URL when the document is ready. Async mode is required when using batch generation (batchSplitBy).
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | JSON data merged into the template — an object, or a top-level array (accessed with {d[i].field}). Access fields with {d.fieldName} tags. Nested objects: {d.customer.name}. Array loops: {d.items[i].description} … {d.items[i+1]}. Conditionals: {d.status == "active" ? "Yes" : "No"}. Optional — if omitted, defaults to an empty object {} so the template is simply converted (tags resolve to empty). Useful to convert a stored template by templateId without data injection. Instead of inlining a large dataset, you may pass a STRING reference to the JSON: a local file path (e.g. "/data/invoices.json"), an HTTPS URL, or a base64-encoded JSON string — it is read and parsed server-side. | |
| enum | No | Enumeration map used with the :convEnum(TYPE) formatter to translate code values into human-readable labels. Define one key per enum type; each value is an object mapping code → label. Example: { "STATUS": { "1": "Active", "2": "Inactive", "3": "Pending" }, "ROLE": { "A": "Admin", "U": "User" } }. Template usage: {d.status:convEnum(STATUS)}, {d.role:convEnum(ROLE)}. May instead be passed by reference as a string — a local file path (e.g. "/data/invoices.json"), an HTTPS URL, or a base64-encoded JSON string. Documentation: https://carbone.io/documentation.html#convenum-type- | |
| lang | No | Locale of the generated document. Affects three things: (1) {t(key)} translation tags — selects the matching translation from the translations map. (2) :formatN number formatter — applies locale-specific thousand/decimal separators. (3) :formatC currency formatter — applies locale-specific currency symbols and formatting. Format: BCP-47 lowercase, e.g. "fr-fr", "en-us", "de-de", "es-es", "pt-br", "zh-cn", "ja-jp". Full list: https://github.com/carboneio/carbone/blob/master/formatters/_locale.js | |
| keepTags | No | If true, SKIP templating entirely and leave every Carbone tag in the document exactly as written — {d.customer} comes out as the literal text "{d.customer}", formatters included. Use it to proof a stored template in another format (e.g. render templateId to PDF to check the tag layout), or to convert a template between formats while it stays a template. Mutually exclusive with data — passing both is rejected, because data would have nothing to fill. Note the difference from omitting data: no data renders the template with an EMPTY dataset, so every tag resolves to an empty string; keepTags leaves the tags themselves in place. Requires Carbone 5.9.0+ (carbone-version: 5). | |
| template | No | Inline template for one-shot render without storing a template first. Three input forms are accepted: (1) Local file path — absolute or relative, e.g. "/home/user/report.docx" or "./invoice.xlsx". (2) HTTPS URL — the file is downloaded automatically, e.g. "https://example.com/file.pptx". (3) Base64-encoded string — the raw file content encoded as base64. The template is uploaded and rendered in a single API request — no Template ID is returned. Use this for ephemeral renders; use upload_template + templateId when you need to reuse the template. Supported formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, IDML, XML, Markdown (MD), PDF, and more. Mutually exclusive with templateId — provide exactly one, never both. | |
| timezone | No | IANA timezone used to convert dates in the rendered document. Default: "Europe/Paris". Applied when templates use the :formatD formatter, e.g. {d.date:formatD(YYYY-MM-DD HH:mm)}. Common values: "UTC", "America/New_York", "America/Los_Angeles", "Europe/London", "Europe/Paris", "Europe/Berlin", "Asia/Tokyo", "Asia/Shanghai", "Australia/Sydney". Full list (TZ identifier column): https://en.wikipedia.org/wiki/List_of_tz_database_time_zones | |
| convertTo | No | Output format. If omitted, the output matches the template format. Documents : "pdf", "docx", "xlsx", "pptx", "odt", "ods", "odp", "odg", "rtf", "epub". Web/text : "html", "xhtml", "txt", "csv", "md", "xml", "idml". Images : "png", "jpg", "jpeg", "webp", "svg", "tiff", "bmp", "gif". Archive : "zip" (use with batchSplitBy for batch output). Simple usage: "pdf". Advanced usage: { "formatName": "pdf", "formatOptions": { ... } } for PDF-specific options. | |
| converter | No | Converter engine. Only relevant when convertTo is "pdf" (or an image rasterised from a document). "L" — LibreOffice (default): best all-round engine for DOCX, XLSX, PPTX, ODT, ODS, ODP. "O" — OnlyOffice: highest fidelity for Microsoft Office formats (DOCX, XLSX, PPTX). "C" — Chromium: best for HTML/CSS/JS templates — full browser rendering. "I" — Carbone ICE (Instant Converter Engine, Carbone 5.14.0+): DOCX → PDF ONLY, no third-party converter — up to 60x faster than LibreOffice on a 1000-page DOCX (3x on a one-page document). Any other input or output format is REJECTED — use another converter for those. PDF options: only Watermarks are applied. EncryptFile, DocumentOpenPassword, RestrictPermissions and the other security options are SILENTLY IGNORED — the PDF comes back readable by anyone, with no error — so NEVER pick "I" when the request needs a password or restricted permissions; use "L" for those. Also unsupported: WEBP and EMF/WMF images, table of contents, SmartArt, complex charts, footnotes/endnotes, comments, tracked changes, form fields, equations, bookmarks and links; a missing font falls back to Noto Sans. If omitted, LibreOffice is used by default. | |
| complement | No | Extra data object accessible in templates with {c.field} tags (as opposed to {d.field} for main data). Useful for static or shared values that should not be mixed into the main dataset: company info, logo URLs, footer text, configuration constants. Example: { "company": "Acme Corp", "address": "123 Main St", "vatNumber": "FR12345" }. Like data, may instead be passed by reference as a string — a local file path (e.g. "/data/invoices.json"), an HTTPS URL, or a base64-encoded JSON string. | |
| outputPath | No | Optional local file path to save the generated document to (e.g. "/home/user/out.pdf" or "~/out.pdf"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the document inline — ideal for large files. Ignored for async/webhook renders (no document is returned inline). | |
| reportName | No | Filename (WITHOUT extension) for the generated document, returned in the Content-Disposition header. Carbone automatically appends the extension that matches convertTo, so do not include one — passing "invoice.pdf" yields "invoice.pdf.pdf". Supports Carbone tags resolved against the data at render time. Examples: "invoice" (static), "{d.type}-{d.id}" (dynamic), "{d.client}-{d.date:formatD(YYYY-MM)}". | |
| returnLink | No | If true, generate the document and return a public download URL instead of the file contents. The link is SHORT-LIVED and ONE-TIME — Carbone deletes the file after the first download — so it is meant for the end user to download once (do not fetch it programmatically). Works in stdio and HTTP. Mutually exclusive with outputPath, asAttachment, and webhookUrl (async). | |
| templateId | No | The ID of a previously uploaded template to render. Two ID formats are accepted: (1) Template ID (64-bit) — stable identifier shared across versions; Carbone automatically uses the deployed version. (2) Version ID (SHA-256) — pins rendering to a specific version regardless of deployment status. Both are returned by upload_template. Mutually exclusive with template — provide exactly one, never both. | |
| webhookUrl | No | Webhook URL to enable asynchronous rendering. When provided, Carbone returns immediately and POSTs { "success": true, "data": { "renderId": "..." } } to this URL when the document is ready. The default render timeout is extended to 5 minutes on Carbone Cloud (vs 60 s for synchronous requests). Download the document with GET /render/:renderId once the webhook is received. Required when using batchSplitBy (batch generation is always asynchronous). Example: "https://your-server.com/carbone-webhook". | |
| batchOutput | No | How the batch result is packaged. Defaults to "zip". "zip" — every generated document is bundled into a single ZIP archive (use batchReportName to name each entry). "pdf" — all documents are CONCATENATED into one continuous PDF instead of being zipped; this requires convertTo to be "pdf" as well. Must be used together with batchSplitBy. | |
| hardRefresh | No | If true, Carbone recomputes pagination and refreshes the table of contents after rendering. Requires convertTo to be defined. Use this for DOCX/ODT templates that contain a TOC field or cross-references that need updating after data injection. | |
| variableStr | No | Carbone alias expressions evaluated once before rendering, available everywhere in the template. Used to pre-compute reusable values or shorten repetitive paths. Syntax: "{#aliasName = expression}". Example: "{#fullName = d.firstName + \" \" + d.lastName}{#total = d.price * d.qty}". Aliases are then used in the template as {#fullName}, {#total}. Documentation: https://carbone.io/documentation.html#alias | |
| asAttachment | No | If true, return the document as a downloadable file attachment (a base64 EmbeddedResource), for any format. Default delivery: text and png/jpg/gif/webp are returned inline; other binary outputs (PDF, Office, …) are saved to a temp file in stdio mode (path returned), or returned as an attachment in HTTP mode. Ignored when outputPath or returnLink is set. | |
| batchSplitBy | No | JSON path to the array in your data that drives batch generation. One document is generated per element of the array. Two forms: "d" when data itself IS the array (one report per top-level element), or "d.arrayName" to split on a child array. Example: "d.invoices" — produces one PDF per item in data.invoices. Example: "d.employees" — produces one contract per employee. Carbone Cloud allows 1 to 100 objects per batch (on-premise follows the nbReportMaxPerBatch setting). Batch is ALWAYS asynchronous — webhookUrl is required. Pair with batchOutput to choose ZIP or a single concatenated PDF, and batchReportName to name each document. | |
| translations | No | Translation map for multilingual documents. Requires "lang" to be set to select the active locale. Top-level keys are BCP-47 locale codes; values are key → translated-string maps. Template usage: {t(greeting)} is replaced by the matching string for the active locale. Example: { "fr-fr": { "greeting": "Bonjour", "total": "Total" }, "en-us": { "greeting": "Hello", "total": "Total" } }. These dictionaries get large, so you may instead pass a string reference — a local file path (e.g. "/data/invoices.json"), an HTTPS URL, or a base64-encoded JSON string. Documentation: https://carbone.io/documentation.html#translations | |
| currencyRates | No | Exchange rate table used by :formatC for currency conversion. Keys are ISO 4217 currency codes; values are rates relative to a common base. The base currency should have rate 1. Example: { "EUR": 1, "USD": 1.08, "GBP": 0.86, "JPY": 160.5 }. May instead be passed by reference as a string — a local file path (e.g. "/data/invoices.json"), an HTTPS URL, or a base64-encoded JSON string. | |
| currencySource | No | ISO 4217 currency code of the monetary amounts in the JSON data. Used by the :formatC formatter as the conversion source. Must be set together with currencyTarget and currencyRates. Example: "EUR" if all prices in your data are in euros. | |
| currencyTarget | No | ISO 4217 currency code of the output document. The :formatC formatter converts amounts from currencySource to this currency using currencyRates. Must be set together with currencySource and currencyRates. Example: "USD" to display prices in US dollars. Documentation: https://carbone.io/documentation.html#formatc-precisionorformat- | |
| webhookHeaders | No | Custom headers Carbone will include when POSTing to your webhookUrl. Pass plain header names as keys — the prefix "carbone-webhook-header-" is added automatically before sending to Carbone, and Carbone forwards the original header names to your webhook endpoint. Example: { "authorization": "my-secret", "custom-id": "12345", "custom-name": "Jane Doe" } — Carbone will call your URL with headers: authorization: my-secret, custom-id: 12345, custom-name: Jane Doe. Requires webhookUrl to be set. | |
| batchReportName | No | Filename pattern for each individual document inside the batch ZIP. Supports Carbone tags. Tags are resolved against the item's data (relative path) or the full dataset (absolute path). Examples: "invoice-{d.id}.pdf", "{d.client.name}-{d.date}.docx". Carbone sanitises the result — path separators, "..", Windows-forbidden and control characters each become an underscore — and appends an index to duplicates ("report_1.pdf", "report_2.pdf"), so a pattern that resolves to the same name for several items will not silently drop documents. Only meaningful with batchOutput: "zip"; a concatenated "pdf" batch is a single file. Must be used together with batchSplitBy. | |
| egressAuthorization | No | Value for the Authorization header Carbone adds to its OUTBOUND (egress) requests while rendering — fetching external images ({d.imageUrl}), external PDFs (:appendFile / :attachFile), and calling webhooks. For example "Bearer abc123" or "my-secret" makes Carbone send `authorization: <value>` to those hosts. Only the authorization header can be customised; max 512 characters. For webhook calls specifically, webhookHeaders.authorization (if set) overrides this value. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate read-only, open-world, and idempotent behavior, but the description adds substantial behavioral context: one-shot template upload stores nothing, async rendering POSTs renderId to a webhook, batch generation is always asynchronous, and returnLink is short-lived and one-time. It also discloses side effects like local file writing via outputPath and silent password-ignoring behavior of the ICE converter, all without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences long, front-loaded with the core purpose and two modes, then lists capabilities and the async requirement. Every sentence adds distinct information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 26 parameters and no output schema, the description covers the essential selection and invocation criteria: two modes, the async/batch relationship, and the main capability set. The exhaustive parameter descriptions in the schema fill in all remaining details, so nothing critical is missing for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description doesn't add per-parameter specifics beyond the schema. It summarizes capability areas like conversion, multilingual rendering, currency conversion, and PDF options, but those are already elaborated in each parameter's description. No additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Generate a document') with an exact mechanism ('merging a Carbone template with JSON data'). It clearly distinguishes two operation modes (templateId vs template) and differentiates from upload_template by noting the one-shot mode stores no template. The title 'Generate Document' aligns perfectly with the described behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use templateId ('previously uploaded template') versus template ('without storing a template'), and names upload_template + templateId as the alternative for reusable templates. It also states that async mode is required for batch generation. However, it doesn't explicitly contrast with the sibling convert_document for pure format-conversion use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_template_metadataUpdate Template MetadataBIdempotentInspect
Update the metadata of a stored template: name, comment, category, tags, deployment timestamp, or expiration. Use deployedAt to activate a specific version for rendering. Use expireAt to schedule or trigger immediate deletion.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Move this version under a DIFFERENT Template ID, re-parenting it so both share a version history. Pass the destination Template ID (64-bit). Leave unset to keep the version where it is — this does not rename anything, use name for that. | |
| name | No | New display name. | |
| tags | No | New list of tags — replaces existing tags entirely. | |
| comment | No | New free-text comment. | |
| category | No | New category. | |
| expireAt | No | Unix timestamp (seconds) at which this template will be automatically deleted. Use 42000000000 to delete immediately. | |
| deployedAt | No | Unix timestamp (seconds) to set as the deployment time for this version. Carbone picks the version with the most recent deployedAt when rendering. Use 42000000000 to deploy immediately (special "NOW" value). | |
| templateId | Yes | Template ID (64-bit) or Version ID (SHA-256) to update. Using a Template ID updates the metadata shared by all versions. Using a Version ID updates only that specific version. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is transparent about side effects, disclosing that expireAt 'can trigger immediate deletion' and that deployedAt affects which version Carbone renders. That said, these disclosures conflict with the annotations: destructiveHint=false, while the tool describes how to trigger immediate, permanent deletion of a template. The annotations signal 'safe, non-destructive update' while the description openly exercises a destructive path, forcing an agent to distrust one signal or the other.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with zero filler. The first sentence front-loads the metadata list and the next two highlight the two behaviorally significant fields. It earns a 4 rather than 5 because the 'deployment/expiration' phrasing under-sells the genuinely surprising bits (re-parenting, immediate deletion) that the description itself later references.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the medium complexity of an 8-parameter, 1-required tool with no output schema and no enums, the definition feels mostly complete: units, sentinels, and replace-vs-merge semantics are all covered. However, the description never surfaces the 'id' re-parenting parameter, and the capacity to delete or permanently alter version history is easy to miss. It's adequate for an agent that reads the schema—but that's the schema doing heavy lifting, not the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter descriptions are rich: they document the special 'NOW' value (42000000000), time units (Unix seconds), and the difference between Template ID and Version ID. The tool description adds only marginal cross-cutting value, reminding the reader that deployedAt 'activates' and expireAt schedules deletion, but most of this is restated in the schema. With the schema carrying the load, this is a solid baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Update the metadata of a stored template') and enumerates the exact fields involved (name, comment, category, tags, deployment timestamp, expiration). The two follow-up imperative sentences about deployedAt and expireAt add behavior the field list alone wouldn't convey. It stops short of 5 because it doesn't explicitly distinguish itself from the sibling tools (e.g., upload_template, delete_template) and omits the re-parenting behavior of 'id' entirely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit parameter-level directives ('Use deployedAt to activate a specific version for rendering. Use expireAt to schedule or trigger immediate deletion.') which guide one aspect of usage well. However, there is no guidance on when this tool should be preferred over template- or document-level alternatives, no exclusions, and no prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_templateUpload TemplateAInspect
Upload and store a reusable Carbone template. Once uploaded, use render_document with the returned Template ID to generate documents from it. Supports versioning: multiple versions can live under a single stable Template ID, with deployedAt controlling which version is active. Accepted formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, IDML, XML, Markdown, PDF, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Existing Template ID (64-bit format) to add this upload to its version history. If omitted, a new Template ID is generated. Providing a Version ID (SHA-256) is not allowed and will cause an error. | |
| name | Yes | Display name for the template (e.g. "Invoice Template", "NDA Contract"). | |
| tags | No | Tags for searchability and filtering (e.g. ["sales", "billing", "v2"]). | |
| sample | No | Sample input data attached to the template for testing in Carbone Studio. Each item must include data, complement, translations, and enum objects. | |
| comment | No | Free-text comment to describe the template version or its purpose. | |
| category | No | Group templates into folders/categories (e.g. "invoices", "legal", "hr"). | |
| expireAt | No | UTC Unix timestamp (seconds) at which this template will be automatically deleted. Use 42000000000 to delete immediately (special "NOW" sentinel value). | |
| template | Yes | The template file. Three input forms are accepted: (1) Local file path — absolute or relative, e.g. "/home/user/report.docx" or "./invoice.xlsx". (2) HTTPS URL — the file is downloaded automatically, e.g. "https://example.com/file.pptx". (3) Base64-encoded string — the raw file content encoded as base64. Supported formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, IDML, XML, Markdown (MD), PDF, and more. Full list: https://carbone.io/documentation/developer/http-api/generate-reports.md | |
| deployedAt | No | UTC Unix timestamp (seconds) to set as the deployment time for this version. Carbone uses the version with the most recent deployedAt when rendering via Template ID. Use 42000000000 to deploy immediately (special "NOW" sentinel value). | |
| versioning | No | Enable template versioning (default: true). When true, a stable Template ID is generated and multiple versions can be managed under it. When false, behaves as legacy mode and returns only a templateId (SHA-256 hash). |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | Stable Template ID (when versioning is enabled). |
| name | Yes | Template display name. |
| size | No | Template size in bytes. |
| type | No | Detected template file type. |
| versionId | No | Version ID (SHA-256) of this uploaded version. |
| templateId | No | Template ID returned in legacy/non-versioned mode. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint false and idempotentHint false, indicating a mutating, non-idempotent operation. The description adds behavioral context by explaining versioning behavior (multiple versions under a single ID, deployedAt controls active version) and the accepted formats. This goes beyond the schema's parameter descriptions and adds value for invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and workflow, then add versioning and format details without redundancy. Every sentence adds distinct information, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema with 100% coverage and an output schema, the description covers the essential workflow and versioning concept. It could mention the three accepted input forms (file path, URL, base64) but those are detailed in the schema's template parameter. Overall, nothing critical is missing for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description itself does not elaborate on parameters beyond what the schema provides; it mentions versioning and formats already covered in schema property descriptions. No extra semantic details are provided in the description itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads and stores a reusable Carbone template, and distinguishes it from render_document by specifying that the returned Template ID is used for rendering. It also mentions versioning, which sets it apart from metadata-only tools like update_template_metadata. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: 'Once uploaded, use render_document with the returned Template ID.' It also hints at versioning usage with deployedAt controlling active version. However, it does not explicitly contrast with alternatives like list_templates or update_template_metadata, so it lacks full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
v1.6.0- Changed
convert_document8 fields changed- changed
Input schema / properties / convertTo / anyOfPrevious value: -[ - { - "enum": [ - "pdf", - "docx", - "xlsx", - "pptx", - "odt", - "ods", - "odp", - "odg", - "html", - "xhtml", - "txt", - "csv", - "md", - "xml", - "rtf", - "png", - "jpg", - "jpeg", - "webp", - "svg", - "tiff", - "bmp", - "gif", - "zip", - "idml", - "epub", - "cdr" - ], - "type": "string" - }, - { - "properties": { - "formatName": { - "description": "Target format name.", - "enum": [ - "pdf", - "docx", - "xlsx", - "pptx", - "odt", - "ods", - "odp", - "odg", - "html", - "xhtml", - "txt", - "csv", - "md", - "xml", - "rtf", - "png", - "jpg", - "jpeg", - "webp", - "svg", - "tiff", - "bmp", - "gif", - "zip", - "idml", - "epub", - "cdr" - ], - "type": "string" - }, - "formatOptions": { - "additionalProperties": {}, - "description": "Advanced format options object. Examples by format: PDF — { \"EncryptFile\": true, \"DocumentOpenPassword\": \"secret\", \"DocumentPermissionPassword\": \"owner\" } password-protect; PDF — { \"Watermarks\": [{ \"text\": \"DRAFT\", \"opacity\": 0.2, \"rotation\": -45, \"fontsize\": 60 }] } up to 5 watermarks; PDF — { \"SelectPdfVersion\": 1 } PDF/A-1b compliance (use 2 for PDF/A-2, 3 for PDF/A-3); PDF — { \"PageRange\": \"1-3,5\" } export specific pages only; PDF — { \"ConvertSlideshow\": true } convert each slide to a separate PDF page; Images (PNG/JPG/WEBP) — { \"Quality\": 90 } set compression quality 0-100; Images — { \"density\": 150 } set DPI for rasterisation (default 96); CSV — { \"fieldSeparator\": \";\" } custom column separator.", - "propertyNames": { - "type": "string" - }, - "type": "object" - } - }, - "required": [ - "formatName" - ], - "type": "object" - } -]New value: +[ + { + "enum": [ + "pdf", + "docx", + "doc", + "xlsx", + "xls", + "pptx", + "ppt", + "odt", + "ods", + "odp", + "odg", + "html", + "xhtml", + "txt", + "csv", + "md", + "xml", + "rtf", + "png", + "jpg", + "jpeg", + "webp", + "svg", + "tiff", + "bmp", + "gif", + "zip", + "idml", + "epub", + "cdr" + ], + "type": "string" + }, + { + "properties": { + "formatName": { + "description": "Target format name.", + "enum": [ + "pdf", + "docx", + "doc", + "xlsx", + "xls", + "pptx", + "ppt", + "odt", + "ods", + "odp", + "odg", + "html", + "xhtml", + "txt", + "csv", + "md", + "xml", + "rtf", + "png", + "jpg", + "jpeg", + "webp", + "svg", + "tiff", + "bmp", + "gif", + "zip", + "idml", + "epub", + "cdr" + ], + "type": "string" + }, + "formatOptions": { + "additionalProperties": {}, + "description": "Advanced format options object. Examples by format: PDF — { \"EncryptFile\": true, \"DocumentOpenPassword\": \"secret\", \"DocumentPermissionPassword\": \"owner\" } password-protect; PDF — { \"Watermarks\": [{ \"text\": \"DRAFT\", \"opacity\": 0.2, \"rotation\": -45, \"fontsize\": 60 }] } up to 5 watermarks; PDF — { \"SelectPdfVersion\": 1 } PDF/A-1b compliance (use 2 for PDF/A-2, 3 for PDF/A-3); PDF — { \"PageRange\": \"1-3,5\" } export specific pages only; PDF — { \"ConvertSlideshow\": true } convert each slide to a separate PDF page; Images (PNG/JPG/WEBP) — { \"Quality\": 90 } set compression quality 0-100; Images — { \"density\": 150 } set DPI for rasterisation (default 96); CSV — { \"fieldSeparator\": \";\" } custom column separator.", + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "required": [ + "formatName" + ], + "type": "object" + } +] - changed
Input schema / properties / convertTo / descriptionPrevious value: -"Target output format. Documents : \"pdf\", \"docx\", \"xlsx\", \"pptx\", \"odt\", \"ods\", \"odp\", \"odg\", \"rtf\", \"epub\". Web/text : \"html\", \"xhtml\", \"txt\", \"csv\", \"md\", \"xml\", \"idml\". Images : \"png\", \"jpg\", \"jpeg\", \"webp\", \"svg\", \"tiff\", \"bmp\", \"gif\". Archive : \"zip\" (batch output). Simple usage: \"pdf\". Advanced usage: { \"formatName\": \"pdf\", \"formatOptions\": { \"EncryptFile\": true, \"DocumentOpenPassword\": \"secret\" } }."New value: +"Target output format. Documents : \"pdf\", \"docx\", \"xlsx\", \"pptx\", \"odt\", \"ods\", \"odp\", \"odg\", \"rtf\", \"epub\", plus the legacy \"doc\", \"xls\", \"ppt\" (output only — Carbone writes them but cannot read them back). Web/text : \"html\", \"xhtml\", \"txt\", \"csv\", \"md\", \"xml\", \"idml\". Images : \"png\", \"jpg\", \"jpeg\", \"webp\", \"svg\", \"tiff\", \"bmp\", \"gif\". Archive : \"zip\" (batch output). Simple usage: \"pdf\". Advanced usage: { \"formatName\": \"pdf\", \"formatOptions\": { \"EncryptFile\": true, \"DocumentOpenPassword\": \"secret\" } }." - changed
Input schema / properties / converter / descriptionPrevious value: -"Converter engine. Only relevant when convertTo is \"pdf\" (or an image format rasterised from a document). \"L\" — LibreOffice (default): best all-round engine for DOCX, XLSX, PPTX, ODT, ODS, ODP. \"O\" — OnlyOffice: highest fidelity rendering for Microsoft Office formats (DOCX, XLSX, PPTX). \"C\" — Chromium: best for HTML, CSS, JavaScript — full browser rendering. If omitted, LibreOffice is used by default."New value: +"Converter engine. Only relevant when convertTo is \"pdf\" (or an image format rasterised from a document). \"L\" — LibreOffice (default): best all-round engine for DOCX, XLSX, PPTX, ODT, ODS, ODP. \"O\" — OnlyOffice: highest fidelity rendering for Microsoft Office formats (DOCX, XLSX, PPTX). \"C\" — Chromium: best for HTML, CSS, JavaScript — full browser rendering. \"I\" — Carbone ICE (Instant Converter Engine, Carbone 5.14.0+): DOCX → PDF ONLY, no third-party converter — up to 60x faster than LibreOffice on a 1000-page DOCX (3x on a one-page document). Any other input or output format is REJECTED — use another converter for those. PDF options: only Watermarks are applied. EncryptFile, DocumentOpenPassword, RestrictPermissions and the other security options are SILENTLY IGNORED — the PDF comes back readable by anyone, with no error — so NEVER pick \"I\" when the request needs a password or restricted permissions; use \"L\" for those. Also unsupported: WEBP and EMF/WMF images, table of contents, SmartArt, complex charts, footnotes/endnotes, comments, tracked changes, form fields, equations, bookmarks and links; a missing font falls back to Noto Sans. If omitted, LibreOffice is used by default." - changed
Input schema / properties / converter / enumPrevious value: -[ - "L", - "C", - "O" -]New value: +[ + "L", + "C", + "O", + "I" +] - changed
Input schema / properties / file / descriptionPrevious value: -"The document to convert. Three input forms are accepted: (1) Local file path — absolute or relative, e.g. \"/home/user/report.docx\" or \"./invoice.xlsx\". (2) HTTPS URL — the file is downloaded automatically, e.g. \"https://example.com/file.pptx\". (3) Base64-encoded string — the raw file content encoded as base64. Supported input formats include: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, XML, IDML, Markdown (MD), PDF, TXT, CSV, PNG, JPG, SVG, and more. Full conversion matrix: https://carbone.io/documentation/developer/http-api/generate-reports.md"New value: +"The document to convert. Three input forms are accepted: (1) Local file path — absolute or relative, e.g. \"/home/user/report.docx\" or \"./invoice.xlsx\". (2) HTTPS URL — the file is downloaded automatically, e.g. \"https://example.com/file.pptx\". (3) Base64-encoded string — the raw file content encoded as base64. Supported input formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, XML, SVG, IDML, Markdown (MD), TXT, CSV, RTF, PDF, PNG and JPG. Carbone reads XML-based and text-based documents only, so the legacy BINARY Office formats DOC, XLS and PPT are REJECTED as input — Carbone can produce them as output but cannot read them. Re-save such a file as DOCX/XLSX/PPTX first. Full conversion matrix: https://carbone.io/documentation/developer/http-api/generate-reports.md" - added
Input schema / properties / hardRefreshAdded value: +{ + "description": "Forces Carbone to run the converter even when the output format already matches the input format. Only useful for PDF: converting PDF → PDF to APPLY formatOptions (watermark, password, PDF/A, page range). Without it Carbone may pass the file straight through and none of those options take effect. Leave unset for any format-changing conversion (DOCX → PDF, XLSX → CSV, …), where the converter runs anyway.", + "type": "boolean" +} - changed
Input schema / properties / outputPath / descriptionPrevious value: -"Optional local file path to save the converted document to (e.g. \"/home/user/out.pdf\" or \"~/out.pdf\"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the document inline — ideal for large files. Local (stdio) mode only; rejected in HTTP mode."New value: +"Optional local file path to save the converted document to (e.g. \"/home/user/out.pdf\" or \"~/out.pdf\"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the document inline — ideal for large files." - added
Input schema / properties / reportNameAdded value: +{ + "description": "Filename (WITHOUT extension) for the converted document, returned in the Content-Disposition header. Carbone appends the extension matching convertTo, so do not include one — \"report.pdf\" yields \"report.pdf.pdf\". Examples: \"contract\", \"2026-invoice\". Unlike render_document, Carbone tags are NOT resolved here (conversion does not run templating), so pass a literal name rather than a pattern like \"{d.id}\" — a pattern would come back verbatim. Ignored when returnLink is set, which returns a download URL rather than a named file.", + "type": "string" +}
- Changed
download_template2 fields changed- changed
Input schema / properties / outputPath / descriptionPrevious value: -"Optional local file path to save the template file to (e.g. \"/home/user/template.docx\" or \"~/template.docx\"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the file inline. Local (stdio) mode only; rejected in HTTP mode."New value: +"Optional local file path to save the template file to (e.g. \"/home/user/out.pdf\" or \"~/out.pdf\"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the document inline — ideal for large files." - added
Input schema / properties / sampleAdded value: +{ + "description": "If true, download the JSON SAMPLE DATASET saved with the template (the \"sample\" array passed to upload_template) instead of the template file. Returns JSON of the form [{ \"data\": {...}, \"complement\": {...}, \"translations\": {...}, \"enum\": {...} }]. Use it to recover the example data a template expects — handy before calling render_document against an unfamiliar template. Errors if the template was uploaded without a sample.", + "type": "boolean" +}
- Changed
list_templates2 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return. Must be between 1 and 100 (Carbone API limit). Default: 100."New value: +"Maximum number of results to return, between 1 and 100. Default: 100. Use cursor to page beyond that." - changed
Input schema / properties / origin / descriptionPrevious value: -"Filter by upload origin. 0 = uploaded via API, 1 = uploaded via Carbone Studio."New value: +"Filter by upload origin. 0 = API, 1 = Carbone Studio, 2 = Salesforce, 3 = Odoo, 4 = HubSpot. Templates created through this MCP are origin 0."
- Changed
render_document15 fields changed- changed
Input schema / properties / batchOutput / descriptionPrevious value: -"Container format for the batch result. Use \"zip\" to receive all generated documents as a single ZIP archive. Must be used together with batchSplitBy."New value: +"How the batch result is packaged. Defaults to \"zip\". \"zip\" — every generated document is bundled into a single ZIP archive (use batchReportName to name each entry). \"pdf\" — all documents are CONCATENATED into one continuous PDF instead of being zipped; this requires convertTo to be \"pdf\" as well. Must be used together with batchSplitBy." - added
Input schema / properties / batchOutput / enumAdded value: +[ + "zip", + "pdf" +] - changed
Input schema / properties / batchReportName / descriptionPrevious value: -"Filename pattern for each individual document inside the batch ZIP. Supports Carbone tags. Tags are resolved against the item's data (relative path) or the full dataset (absolute path). Examples: \"invoice-{d.id}.pdf\", \"{d.client.name}-{d.date}.docx\". Must be used together with batchSplitBy."New value: +"Filename pattern for each individual document inside the batch ZIP. Supports Carbone tags. Tags are resolved against the item's data (relative path) or the full dataset (absolute path). Examples: \"invoice-{d.id}.pdf\", \"{d.client.name}-{d.date}.docx\". Carbone sanitises the result — path separators, \"..\", Windows-forbidden and control characters each become an underscore — and appends an index to duplicates (\"report_1.pdf\", \"report_2.pdf\"), so a pattern that resolves to the same name for several items will not silently drop documents. Only meaningful with batchOutput: \"zip\"; a concatenated \"pdf\" batch is a single file. Must be used together with batchSplitBy." - changed
Input schema / properties / batchSplitBy / descriptionPrevious value: -"JSON path to the array in your data that drives batch generation. One document is generated per element of the array; all documents are bundled together. Use batchOutput: \"zip\" to receive a single ZIP archive. Use batchReportName to customise each filename inside the ZIP. Example: \"d.invoices\" — produces one PDF per item in data.invoices. Example: \"d.employees\" — produces one contract per employee."New value: +"JSON path to the array in your data that drives batch generation. One document is generated per element of the array. Two forms: \"d\" when data itself IS the array (one report per top-level element), or \"d.arrayName\" to split on a child array. Example: \"d.invoices\" — produces one PDF per item in data.invoices. Example: \"d.employees\" — produces one contract per employee. Carbone Cloud allows 1 to 100 objects per batch (on-premise follows the nbReportMaxPerBatch setting). Batch is ALWAYS asynchronous — webhookUrl is required. Pair with batchOutput to choose ZIP or a single concatenated PDF, and batchReportName to name each document." - changed
Input schema / properties / complement / descriptionPrevious value: -"Extra data object accessible in templates with {c.field} tags (as opposed to {d.field} for main data). Useful for static or shared values that should not be mixed into the main dataset: company info, logo URLs, footer text, configuration constants. Example: { \"company\": \"Acme Corp\", \"address\": \"123 Main St\", \"vatNumber\": \"FR12345\" }. Like data, may instead be passed by reference as a string — a local path, HTTPS URL, or base64 to a JSON file."New value: +"Extra data object accessible in templates with {c.field} tags (as opposed to {d.field} for main data). Useful for static or shared values that should not be mixed into the main dataset: company info, logo URLs, footer text, configuration constants. Example: { \"company\": \"Acme Corp\", \"address\": \"123 Main St\", \"vatNumber\": \"FR12345\" }. Like data, may instead be passed by reference as a string — a local file path (e.g. \"/data/invoices.json\"), an HTTPS URL, or a base64-encoded JSON string." - changed
Input schema / properties / convertTo / anyOfPrevious value: -[ - { - "enum": [ - "pdf", - "docx", - "xlsx", - "pptx", - "odt", - "ods", - "odp", - "odg", - "html", - "xhtml", - "txt", - "csv", - "md", - "xml", - "rtf", - "png", - "jpg", - "jpeg", - "webp", - "svg", - "tiff", - "bmp", - "gif", - "zip", - "idml", - "epub", - "cdr" - ], - "type": "string" - }, - { - "properties": { - "formatName": { - "description": "Target format name.", - "enum": [ - "pdf", - "docx", - "xlsx", - "pptx", - "odt", - "ods", - "odp", - "odg", - "html", - "xhtml", - "txt", - "csv", - "md", - "xml", - "rtf", - "png", - "jpg", - "jpeg", - "webp", - "svg", - "tiff", - "bmp", - "gif", - "zip", - "idml", - "epub", - "cdr" - ], - "type": "string" - }, - "formatOptions": { - "additionalProperties": {}, - "description": "Advanced format options object. Examples by format: PDF — { \"EncryptFile\": true, \"DocumentOpenPassword\": \"secret\", \"DocumentPermissionPassword\": \"owner\" } password-protect; PDF — { \"Watermarks\": [{ \"text\": \"DRAFT\", \"opacity\": 0.2, \"rotation\": -45, \"fontsize\": 60 }] } up to 5 watermarks; PDF — { \"SelectPdfVersion\": 1 } PDF/A-1b compliance (use 2 for PDF/A-2, 3 for PDF/A-3); PDF — { \"PageRange\": \"1-3,5\" } export specific pages only; PDF — { \"ConvertSlideshow\": true } convert each slide to a separate PDF page; Images (PNG/JPG/WEBP) — { \"Quality\": 90 } compression quality 0-100; Images — { \"density\": 150 } DPI for rasterisation (default 96); CSV — { \"fieldSeparator\": \";\" } custom column separator.", - "propertyNames": { - "type": "string" - }, - "type": "object" - } - }, - "required": [ - "formatName" - ], - "type": "object" - } -]New value: +[ + { + "enum": [ + "pdf", + "docx", + "doc", + "xlsx", + "xls", + "pptx", + "ppt", + "odt", + "ods", + "odp", + "odg", + "html", + "xhtml", + "txt", + "csv", + "md", + "xml", + "rtf", + "png", + "jpg", + "jpeg", + "webp", + "svg", + "tiff", + "bmp", + "gif", + "zip", + "idml", + "epub", + "cdr" + ], + "type": "string" + }, + { + "properties": { + "formatName": { + "description": "Target format name.", + "enum": [ + "pdf", + "docx", + "doc", + "xlsx", + "xls", + "pptx", + "ppt", + "odt", + "ods", + "odp", + "odg", + "html", + "xhtml", + "txt", + "csv", + "md", + "xml", + "rtf", + "png", + "jpg", + "jpeg", + "webp", + "svg", + "tiff", + "bmp", + "gif", + "zip", + "idml", + "epub", + "cdr" + ], + "type": "string" + }, + "formatOptions": { + "additionalProperties": {}, + "description": "Advanced format options object. Examples by format: PDF — { \"EncryptFile\": true, \"DocumentOpenPassword\": \"secret\", \"DocumentPermissionPassword\": \"owner\" } password-protect; PDF — { \"Watermarks\": [{ \"text\": \"DRAFT\", \"opacity\": 0.2, \"rotation\": -45, \"fontsize\": 60 }] } up to 5 watermarks; PDF — { \"SelectPdfVersion\": 1 } PDF/A-1b compliance (use 2 for PDF/A-2, 3 for PDF/A-3); PDF — { \"PageRange\": \"1-3,5\" } export specific pages only; PDF — { \"ConvertSlideshow\": true } convert each slide to a separate PDF page; Images (PNG/JPG/WEBP) — { \"Quality\": 90 } compression quality 0-100; Images — { \"density\": 150 } DPI for rasterisation (default 96); CSV — { \"fieldSeparator\": \";\" } custom column separator.", + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "required": [ + "formatName" + ], + "type": "object" + } +] - changed
Input schema / properties / converter / descriptionPrevious value: -"Converter engine. Only relevant when convertTo is \"pdf\" (or an image rasterised from a document). \"L\" — LibreOffice (default): best all-round engine for DOCX, XLSX, PPTX, ODT, ODS, ODP. \"O\" — OnlyOffice: highest fidelity for Microsoft Office formats (DOCX, XLSX, PPTX). \"C\" — Chromium: best for HTML/CSS/JS templates — full browser rendering. If omitted, LibreOffice is used by default."New value: +"Converter engine. Only relevant when convertTo is \"pdf\" (or an image rasterised from a document). \"L\" — LibreOffice (default): best all-round engine for DOCX, XLSX, PPTX, ODT, ODS, ODP. \"O\" — OnlyOffice: highest fidelity for Microsoft Office formats (DOCX, XLSX, PPTX). \"C\" — Chromium: best for HTML/CSS/JS templates — full browser rendering. \"I\" — Carbone ICE (Instant Converter Engine, Carbone 5.14.0+): DOCX → PDF ONLY, no third-party converter — up to 60x faster than LibreOffice on a 1000-page DOCX (3x on a one-page document). Any other input or output format is REJECTED — use another converter for those. PDF options: only Watermarks are applied. EncryptFile, DocumentOpenPassword, RestrictPermissions and the other security options are SILENTLY IGNORED — the PDF comes back readable by anyone, with no error — so NEVER pick \"I\" when the request needs a password or restricted permissions; use \"L\" for those. Also unsupported: WEBP and EMF/WMF images, table of contents, SmartArt, complex charts, footnotes/endnotes, comments, tracked changes, form fields, equations, bookmarks and links; a missing font falls back to Noto Sans. If omitted, LibreOffice is used by default." - changed
Input schema / properties / converter / enumPrevious value: -[ - "L", - "C", - "O" -]New value: +[ + "L", + "C", + "O", + "I" +] - changed
Input schema / properties / currencyRates / descriptionPrevious value: -"Exchange rate table used by :formatC for currency conversion. Keys are ISO 4217 currency codes; values are rates relative to a common base. The base currency should have rate 1. Example: { \"EUR\": 1, \"USD\": 1.08, \"GBP\": 0.86, \"JPY\": 160.5 }. May instead be passed by reference as a string — a local path, HTTPS URL, or base64 to a JSON file."New value: +"Exchange rate table used by :formatC for currency conversion. Keys are ISO 4217 currency codes; values are rates relative to a common base. The base currency should have rate 1. Example: { \"EUR\": 1, \"USD\": 1.08, \"GBP\": 0.86, \"JPY\": 160.5 }. May instead be passed by reference as a string — a local file path (e.g. \"/data/invoices.json\"), an HTTPS URL, or a base64-encoded JSON string." - changed
Input schema / properties / data / descriptionPrevious value: -"JSON data merged into the template — an object, or a top-level array (accessed with {d[i].field}). Access fields with {d.fieldName} tags. Nested objects: {d.customer.name}. Array loops: {d.items[i].description} … {d.items[i+1]}. Conditionals: {d.status == \"active\" ? \"Yes\" : \"No\"}. Optional — if omitted, defaults to an empty object {} so the template is simply converted (tags resolve to empty). Useful to convert a stored template by templateId without data injection. Instead of inlining a large dataset, you may pass a STRING reference to the JSON: a local file path (e.g. \"/data/invoices.json\"), an HTTPS URL, or a base64-encoded JSON string — it is read and parsed server-side. Local paths resolve in stdio (local) mode only; URLs and base64 work in both transports."New value: +"JSON data merged into the template — an object, or a top-level array (accessed with {d[i].field}). Access fields with {d.fieldName} tags. Nested objects: {d.customer.name}. Array loops: {d.items[i].description} … {d.items[i+1]}. Conditionals: {d.status == \"active\" ? \"Yes\" : \"No\"}. Optional — if omitted, defaults to an empty object {} so the template is simply converted (tags resolve to empty). Useful to convert a stored template by templateId without data injection. Instead of inlining a large dataset, you may pass a STRING reference to the JSON: a local file path (e.g. \"/data/invoices.json\"), an HTTPS URL, or a base64-encoded JSON string — it is read and parsed server-side." - changed
Input schema / properties / enum / descriptionPrevious value: -"Enumeration map used with the :convEnum(TYPE) formatter to translate code values into human-readable labels. Define one key per enum type; each value is an object mapping code → label. Example: { \"STATUS\": { \"1\": \"Active\", \"2\": \"Inactive\", \"3\": \"Pending\" }, \"ROLE\": { \"A\": \"Admin\", \"U\": \"User\" } }. Template usage: {d.status:convEnum(STATUS)}, {d.role:convEnum(ROLE)}. May instead be passed by reference as a string — a local path, HTTPS URL, or base64 to a JSON file. Documentation: https://carbone.io/documentation.html#convenum-type-"New value: +"Enumeration map used with the :convEnum(TYPE) formatter to translate code values into human-readable labels. Define one key per enum type; each value is an object mapping code → label. Example: { \"STATUS\": { \"1\": \"Active\", \"2\": \"Inactive\", \"3\": \"Pending\" }, \"ROLE\": { \"A\": \"Admin\", \"U\": \"User\" } }. Template usage: {d.status:convEnum(STATUS)}, {d.role:convEnum(ROLE)}. May instead be passed by reference as a string — a local file path (e.g. \"/data/invoices.json\"), an HTTPS URL, or a base64-encoded JSON string. Documentation: https://carbone.io/documentation.html#convenum-type-" - added
Input schema / properties / keepTagsAdded value: +{ + "description": "If true, SKIP templating entirely and leave every Carbone tag in the document exactly as written — {d.customer} comes out as the literal text \"{d.customer}\", formatters included. Use it to proof a stored template in another format (e.g. render templateId to PDF to check the tag layout), or to convert a template between formats while it stays a template. Mutually exclusive with data — passing both is rejected, because data would have nothing to fill. Note the difference from omitting data: no data renders the template with an EMPTY dataset, so every tag resolves to an empty string; keepTags leaves the tags themselves in place. Requires Carbone 5.9.0+ (carbone-version: 5).", + "type": "boolean" +} - changed
Input schema / properties / outputPath / descriptionPrevious value: -"Optional local file path to save the generated document to (e.g. \"/home/user/out.pdf\" or \"~/out.pdf\"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the document inline — ideal for large files. Local (stdio) mode only; rejected in HTTP mode. Ignored for async/webhook renders (no document is returned inline)."New value: +"Optional local file path to save the generated document to (e.g. \"/home/user/out.pdf\" or \"~/out.pdf\"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the document inline — ideal for large files. Ignored for async/webhook renders (no document is returned inline)." - changed
Input schema / properties / template / descriptionPrevious value: -"Inline template for one-shot render without storing a template first. Accepts a local file path (e.g. /home/user/invoice.docx), a URL (https://example.com/template.docx), or a base64-encoded string. The template is uploaded and rendered in a single API request — no Template ID is returned. Use this for ephemeral renders; use upload_template + templateId when you need to reuse the template. Supported formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, IDML, XML, Markdown (MD), PDF, and more. Mutually exclusive with templateId — provide exactly one, never both."New value: +"Inline template for one-shot render without storing a template first. Three input forms are accepted: (1) Local file path — absolute or relative, e.g. \"/home/user/report.docx\" or \"./invoice.xlsx\". (2) HTTPS URL — the file is downloaded automatically, e.g. \"https://example.com/file.pptx\". (3) Base64-encoded string — the raw file content encoded as base64. The template is uploaded and rendered in a single API request — no Template ID is returned. Use this for ephemeral renders; use upload_template + templateId when you need to reuse the template. Supported formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, IDML, XML, Markdown (MD), PDF, and more. Mutually exclusive with templateId — provide exactly one, never both." - changed
Input schema / properties / translations / descriptionPrevious value: -"Translation map for multilingual documents. Requires \"lang\" to be set to select the active locale. Top-level keys are BCP-47 locale codes; values are key → translated-string maps. Template usage: {t(greeting)} is replaced by the matching string for the active locale. Example: { \"fr-fr\": { \"greeting\": \"Bonjour\", \"total\": \"Total\" }, \"en-us\": { \"greeting\": \"Hello\", \"total\": \"Total\" } }. These dictionaries get large, so you may instead pass a string reference — a local path, HTTPS URL, or base64 to a JSON file. Documentation: https://carbone.io/documentation.html#translations"New value: +"Translation map for multilingual documents. Requires \"lang\" to be set to select the active locale. Top-level keys are BCP-47 locale codes; values are key → translated-string maps. Template usage: {t(greeting)} is replaced by the matching string for the active locale. Example: { \"fr-fr\": { \"greeting\": \"Bonjour\", \"total\": \"Total\" }, \"en-us\": { \"greeting\": \"Hello\", \"total\": \"Total\" } }. These dictionaries get large, so you may instead pass a string reference — a local file path (e.g. \"/data/invoices.json\"), an HTTPS URL, or a base64-encoded JSON string. Documentation: https://carbone.io/documentation.html#translations"
- Changed
update_template_metadata1 field changed- added
Input schema / properties / idAdded value: +{ + "description": "Move this version under a DIFFERENT Template ID, re-parenting it so both share a version history. Pass the destination Template ID (64-bit). Leave unset to keep the version where it is — this does not rename anything, use name for that.", + "type": "string" +}
- Changed
upload_template1 field changed- changed
Input schema / properties / template / descriptionPrevious value: -"The template file. Accepts a local file path (e.g. /home/user/invoice.docx), a URL (https://example.com/template.docx), or a base64-encoded string. Supported formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, IDML, XML, Markdown (MD), PDF, and more. Full list: https://carbone.io/documentation/developer/http-api/generate-reports.md"New value: +"The template file. Three input forms are accepted: (1) Local file path — absolute or relative, e.g. \"/home/user/report.docx\" or \"./invoice.xlsx\". (2) HTTPS URL — the file is downloaded automatically, e.g. \"https://example.com/file.pptx\". (3) Base64-encoded string — the raw file content encoded as base64. Supported formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, IDML, XML, Markdown (MD), PDF, and more. Full list: https://carbone.io/documentation/developer/http-api/generate-reports.md"
2 tool updates
v1.4.0- Changed
convert_document1 field changed- added
Input schema / properties / egressAuthorizationAdded value: +{ + "description": "Value for the Authorization header Carbone adds to its OUTBOUND (egress) requests during conversion — e.g. when a Chromium HTML→PDF conversion fetches a protected external image or stylesheet. For example \"Bearer abc123\" makes Carbone send `authorization: Bearer abc123` to those hosts. Only the authorization header can be customised; max 512 characters.", + "maxLength": 512, + "type": "string" +}
- Changed
render_document3 fields changed- changed
Input schema / properties / data / descriptionPrevious value: -"JSON data merged into the template — an object, or a top-level array (accessed with {d[i].field}). Access fields with {d.fieldName} tags. Nested objects: {d.customer.name}. Array loops: {d.items[i].description} … {d.items[i+1]}. Conditionals: {d.status == \"active\" ? \"Yes\" : \"No\"}. For pure document conversion without data injection, pass {}. Instead of inlining a large dataset, you may pass a STRING reference to the JSON: a local file path (e.g. \"/data/invoices.json\"), an HTTPS URL, or a base64-encoded JSON string — it is read and parsed server-side. Local paths resolve in stdio (local) mode only; URLs and base64 work in both transports."New value: +"JSON data merged into the template — an object, or a top-level array (accessed with {d[i].field}). Access fields with {d.fieldName} tags. Nested objects: {d.customer.name}. Array loops: {d.items[i].description} … {d.items[i+1]}. Conditionals: {d.status == \"active\" ? \"Yes\" : \"No\"}. Optional — if omitted, defaults to an empty object {} so the template is simply converted (tags resolve to empty). Useful to convert a stored template by templateId without data injection. Instead of inlining a large dataset, you may pass a STRING reference to the JSON: a local file path (e.g. \"/data/invoices.json\"), an HTTPS URL, or a base64-encoded JSON string — it is read and parsed server-side. Local paths resolve in stdio (local) mode only; URLs and base64 work in both transports." - added
Input schema / properties / egressAuthorizationAdded value: +{ + "description": "Value for the Authorization header Carbone adds to its OUTBOUND (egress) requests while rendering — fetching external images ({d.imageUrl}), external PDFs (:appendFile / :attachFile), and calling webhooks. For example \"Bearer abc123\" or \"my-secret\" makes Carbone send `authorization: <value>` to those hosts. Only the authorization header can be customised; max 512 characters. For webhook calls specifically, webhookHeaders.authorization (if set) overrides this value.", + "maxLength": 512, + "type": "string" +} - removed
Input schema / requiredRemoved value: -[ - "data" -]
8 tool updates
v1.2.2- Changed
convert_document5 fields changed- added
Input schema / properties / asAttachmentAdded value: +{ + "description": "If true, return the document as a downloadable file attachment (a base64 EmbeddedResource), for any format. Default delivery: text and png/jpg/gif/webp are returned inline; other binary outputs (PDF, Office, …) are saved to a temp file in stdio mode (path returned), or returned as an attachment in HTTP mode. Ignored when outputPath or returnLink is set.", + "type": "boolean" +} - changed
Input schema / properties / convertTo / anyOfPrevious value: -[ - { - "enum": [ - "pdf", - "docx", - "xlsx", - "pptx", - "odt", - "ods", - "odp", - "odg", - "html", - "xhtml", - "txt", - "csv", - "md", - "xml", - "rtf", - "png", - "jpg", - "jpeg", - "webp", - "svg", - "tiff", - "bmp", - "gif", - "zip", - "idml", - "epub" - ], - "type": "string" - }, - { - "properties": { - "formatName": { - "description": "Target format name.", - "enum": [ - "pdf", - "docx", - "xlsx", - "pptx", - "odt", - "ods", - "odp", - "odg", - "html", - "xhtml", - "txt", - "csv", - "md", - "xml", - "rtf", - "png", - "jpg", - "jpeg", - "webp", - "svg", - "tiff", - "bmp", - "gif", - "zip", - "idml", - "epub" - ], - "type": "string" - }, - "formatOptions": { - "additionalProperties": {}, - "description": "Advanced format options object. Examples by format: PDF — { \"EncryptFile\": true, \"DocumentOpenPassword\": \"secret\", \"DocumentPermissionPassword\": \"owner\" } password-protect; PDF — { \"Watermarks\": [{ \"text\": \"DRAFT\", \"opacity\": 0.2, \"rotation\": -45, \"fontsize\": 60 }] } up to 5 watermarks; PDF — { \"SelectPdfVersion\": 1 } PDF/A-1b compliance (use 2 for PDF/A-2, 3 for PDF/A-3); PDF — { \"PageRange\": \"1-3,5\" } export specific pages only; PDF — { \"ConvertSlideshow\": true } convert each slide to a separate PDF page; Images (PNG/JPG/WEBP) — { \"Quality\": 90 } set compression quality 0-100; Images — { \"density\": 150 } set DPI for rasterisation (default 96); CSV — { \"fieldSeparator\": \";\" } custom column separator.", - "propertyNames": { - "type": "string" - }, - "type": "object" - } - }, - "required": [ - "formatName" - ], - "type": "object" - } -]New value: +[ + { + "enum": [ + "pdf", + "docx", + "xlsx", + "pptx", + "odt", + "ods", + "odp", + "odg", + "html", + "xhtml", + "txt", + "csv", + "md", + "xml", + "rtf", + "png", + "jpg", + "jpeg", + "webp", + "svg", + "tiff", + "bmp", + "gif", + "zip", + "idml", + "epub", + "cdr" + ], + "type": "string" + }, + { + "properties": { + "formatName": { + "description": "Target format name.", + "enum": [ + "pdf", + "docx", + "xlsx", + "pptx", + "odt", + "ods", + "odp", + "odg", + "html", + "xhtml", + "txt", + "csv", + "md", + "xml", + "rtf", + "png", + "jpg", + "jpeg", + "webp", + "svg", + "tiff", + "bmp", + "gif", + "zip", + "idml", + "epub", + "cdr" + ], + "type": "string" + }, + "formatOptions": { + "additionalProperties": {}, + "description": "Advanced format options object. Examples by format: PDF — { \"EncryptFile\": true, \"DocumentOpenPassword\": \"secret\", \"DocumentPermissionPassword\": \"owner\" } password-protect; PDF — { \"Watermarks\": [{ \"text\": \"DRAFT\", \"opacity\": 0.2, \"rotation\": -45, \"fontsize\": 60 }] } up to 5 watermarks; PDF — { \"SelectPdfVersion\": 1 } PDF/A-1b compliance (use 2 for PDF/A-2, 3 for PDF/A-3); PDF — { \"PageRange\": \"1-3,5\" } export specific pages only; PDF — { \"ConvertSlideshow\": true } convert each slide to a separate PDF page; Images (PNG/JPG/WEBP) — { \"Quality\": 90 } set compression quality 0-100; Images — { \"density\": 150 } set DPI for rasterisation (default 96); CSV — { \"fieldSeparator\": \";\" } custom column separator.", + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "required": [ + "formatName" + ], + "type": "object" + } +] - changed
Input schema / properties / file / descriptionPrevious value: -"The document to convert. Three input forms are accepted: (1) Local file path — absolute or relative, e.g. \"/home/user/report.docx\" or \"./invoice.xlsx\". (2) HTTPS URL — the file is downloaded automatically, e.g. \"https://example.com/file.pptx\". (3) Base64-encoded string — the raw file content encoded as base64. Supported input formats include: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, XML, IDML, Markdown (MD), PDF, TXT, CSV, PNG, JPG, SVG, and more. Full conversion matrix: https://carbone.io/documentation/developer/http-api/generate-reports.html#output-file-type"New value: +"The document to convert. Three input forms are accepted: (1) Local file path — absolute or relative, e.g. \"/home/user/report.docx\" or \"./invoice.xlsx\". (2) HTTPS URL — the file is downloaded automatically, e.g. \"https://example.com/file.pptx\". (3) Base64-encoded string — the raw file content encoded as base64. Supported input formats include: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, XML, IDML, Markdown (MD), PDF, TXT, CSV, PNG, JPG, SVG, and more. Full conversion matrix: https://carbone.io/documentation/developer/http-api/generate-reports.md" - added
Input schema / properties / outputPathAdded value: +{ + "description": "Optional local file path to save the converted document to (e.g. \"/home/user/out.pdf\" or \"~/out.pdf\"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the document inline — ideal for large files. Local (stdio) mode only; rejected in HTTP mode.", + "type": "string" +} - added
Input schema / properties / returnLinkAdded value: +{ + "description": "If true, generate the document and return a public download URL instead of the file contents. The link is SHORT-LIVED and ONE-TIME — Carbone deletes the file after the first download — so it is meant for the end user to download once (do not fetch it programmatically). Works in stdio and HTTP. Mutually exclusive with outputPath and asAttachment.", + "type": "boolean" +}
- Changed
download_template2 fields changed- added
Input schema / properties / asAttachmentAdded value: +{ + "description": "If true, return the template as a downloadable file attachment (base64 resource) instead of inline text/image. Useful in HTTP mode where outputPath is unavailable. Default: false. Ignored when outputPath is set.", + "type": "boolean" +} - added
Input schema / properties / outputPathAdded value: +{ + "description": "Optional local file path to save the template file to (e.g. \"/home/user/template.docx\" or \"~/template.docx\"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the file inline. Local (stdio) mode only; rejected in HTTP mode.", + "type": "string" +}
- Changed
get_api_status1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "message": { + "description": "Status message returned by the API.", + "type": "string" + }, + "version": { + "description": "The running Carbone API version.", + "type": "string" + } + }, + "required": [ + "version", + "message" + ], + "type": "object" +}
- Changed
list_categories1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "categories": { + "description": "Template category names in use.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "categories" + ], + "type": "object" +}
- Changed
list_tags1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "tags": { + "description": "Template tag names in use.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "tags" + ], + "type": "object" +}
- Changed
list_templates5 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results to return (default: 100)."New value: +"Maximum number of results to return. Must be between 1 and 100 (Carbone API limit). Default: 100." - removed
Input schema / properties / limit / exclusiveMinimumRemoved value: -0 - changed
Input schema / properties / limit / maximumPrevious value: -9007199254740991New value: +100 - added
Input schema / properties / limit / minimumAdded value: +1 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "hasMore": { + "description": "Whether more results are available via the cursor.", + "type": "boolean" + }, + "nextCursor": { + "description": "Cursor to pass to the next list_templates call.", + "type": "string" + }, + "templates": { + "description": "The matching templates (all fields).", + "items": { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "templates", + "hasMore" + ], + "type": "object" +}
- Changed
render_document30 fields changed- added
Input schema / properties / asAttachmentAdded value: +{ + "description": "If true, return the document as a downloadable file attachment (a base64 EmbeddedResource), for any format. Default delivery: text and png/jpg/gif/webp are returned inline; other binary outputs (PDF, Office, …) are saved to a temp file in stdio mode (path returned), or returned as an attachment in HTTP mode. Ignored when outputPath or returnLink is set.", + "type": "boolean" +} - removed
Input schema / properties / complement / additionalPropertiesRemoved value: -{} - added
Input schema / properties / complement / anyOfAdded value: +[ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "string" + } +] - changed
Input schema / properties / complement / descriptionPrevious value: -"Extra data object accessible in templates with {c.field} tags (as opposed to {d.field} for main data). Useful for static or shared values that should not be mixed into the main dataset: company info, logo URLs, footer text, configuration constants. Example: { \"company\": \"Acme Corp\", \"address\": \"123 Main St\", \"vatNumber\": \"FR12345\" }"New value: +"Extra data object accessible in templates with {c.field} tags (as opposed to {d.field} for main data). Useful for static or shared values that should not be mixed into the main dataset: company info, logo URLs, footer text, configuration constants. Example: { \"company\": \"Acme Corp\", \"address\": \"123 Main St\", \"vatNumber\": \"FR12345\" }. Like data, may instead be passed by reference as a string — a local path, HTTPS URL, or base64 to a JSON file." - removed
Input schema / properties / complement / propertyNamesRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / complement / typeRemoved value: -"object" - changed
Input schema / properties / convertTo / anyOfPrevious value: -[ - { - "enum": [ - "pdf", - "docx", - "xlsx", - "pptx", - "odt", - "ods", - "odp", - "odg", - "html", - "xhtml", - "txt", - "csv", - "md", - "xml", - "rtf", - "png", - "jpg", - "jpeg", - "webp", - "svg", - "tiff", - "bmp", - "gif", - "zip", - "idml", - "epub" - ], - "type": "string" - }, - { - "properties": { - "formatName": { - "description": "Target format name.", - "enum": [ - "pdf", - "docx", - "xlsx", - "pptx", - "odt", - "ods", - "odp", - "odg", - "html", - "xhtml", - "txt", - "csv", - "md", - "xml", - "rtf", - "png", - "jpg", - "jpeg", - "webp", - "svg", - "tiff", - "bmp", - "gif", - "zip", - "idml", - "epub" - ], - "type": "string" - }, - "formatOptions": { - "additionalProperties": {}, - "description": "Advanced format options object. Examples by format: PDF — { \"EncryptFile\": true, \"DocumentOpenPassword\": \"secret\", \"DocumentPermissionPassword\": \"owner\" } password-protect; PDF — { \"Watermarks\": [{ \"text\": \"DRAFT\", \"opacity\": 0.2, \"rotation\": -45, \"fontsize\": 60 }] } up to 5 watermarks; PDF — { \"SelectPdfVersion\": 1 } PDF/A-1b compliance (use 2 for PDF/A-2, 3 for PDF/A-3); PDF — { \"PageRange\": \"1-3,5\" } export specific pages only; PDF — { \"ConvertSlideshow\": true } convert each slide to a separate PDF page; Images (PNG/JPG/WEBP) — { \"Quality\": 90 } compression quality 0-100; Images — { \"density\": 150 } DPI for rasterisation (default 96); CSV — { \"fieldSeparator\": \";\" } custom column separator.", - "propertyNames": { - "type": "string" - }, - "type": "object" - } - }, - "required": [ - "formatName" - ], - "type": "object" - } -]New value: +[ + { + "enum": [ + "pdf", + "docx", + "xlsx", + "pptx", + "odt", + "ods", + "odp", + "odg", + "html", + "xhtml", + "txt", + "csv", + "md", + "xml", + "rtf", + "png", + "jpg", + "jpeg", + "webp", + "svg", + "tiff", + "bmp", + "gif", + "zip", + "idml", + "epub", + "cdr" + ], + "type": "string" + }, + { + "properties": { + "formatName": { + "description": "Target format name.", + "enum": [ + "pdf", + "docx", + "xlsx", + "pptx", + "odt", + "ods", + "odp", + "odg", + "html", + "xhtml", + "txt", + "csv", + "md", + "xml", + "rtf", + "png", + "jpg", + "jpeg", + "webp", + "svg", + "tiff", + "bmp", + "gif", + "zip", + "idml", + "epub", + "cdr" + ], + "type": "string" + }, + "formatOptions": { + "additionalProperties": {}, + "description": "Advanced format options object. Examples by format: PDF — { \"EncryptFile\": true, \"DocumentOpenPassword\": \"secret\", \"DocumentPermissionPassword\": \"owner\" } password-protect; PDF — { \"Watermarks\": [{ \"text\": \"DRAFT\", \"opacity\": 0.2, \"rotation\": -45, \"fontsize\": 60 }] } up to 5 watermarks; PDF — { \"SelectPdfVersion\": 1 } PDF/A-1b compliance (use 2 for PDF/A-2, 3 for PDF/A-3); PDF — { \"PageRange\": \"1-3,5\" } export specific pages only; PDF — { \"ConvertSlideshow\": true } convert each slide to a separate PDF page; Images (PNG/JPG/WEBP) — { \"Quality\": 90 } compression quality 0-100; Images — { \"density\": 150 } DPI for rasterisation (default 96); CSV — { \"fieldSeparator\": \";\" } custom column separator.", + "propertyNames": { + "type": "string" + }, + "type": "object" + } + }, + "required": [ + "formatName" + ], + "type": "object" + } +] - removed
Input schema / properties / currencyRates / additionalPropertiesRemoved value: -{ - "type": "number" -} - added
Input schema / properties / currencyRates / anyOfAdded value: +[ + { + "additionalProperties": { + "type": "number" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "string" + } +] - changed
Input schema / properties / currencyRates / descriptionPrevious value: -"Exchange rate table used by :formatC for currency conversion. Keys are ISO 4217 currency codes; values are rates relative to a common base. The base currency should have rate 1. Example: { \"EUR\": 1, \"USD\": 1.08, \"GBP\": 0.86, \"JPY\": 160.5 }."New value: +"Exchange rate table used by :formatC for currency conversion. Keys are ISO 4217 currency codes; values are rates relative to a common base. The base currency should have rate 1. Example: { \"EUR\": 1, \"USD\": 1.08, \"GBP\": 0.86, \"JPY\": 160.5 }. May instead be passed by reference as a string — a local path, HTTPS URL, or base64 to a JSON file." - removed
Input schema / properties / currencyRates / propertyNamesRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / currencyRates / typeRemoved value: -"object" - removed
Input schema / properties / data / additionalPropertiesRemoved value: -{} - added
Input schema / properties / data / anyOfAdded value: +[ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "items": {}, + "type": "array" + }, + { + "type": "string" + } +] - changed
Input schema / properties / data / descriptionPrevious value: -"JSON data merged into the template. Access fields with {d.fieldName} tags. Nested objects: {d.customer.name}. Array loops: {d.items[i].description} … {d.items[i+1]}. Conditionals: {d.status == \"active\" ? \"Yes\" : \"No\"}. For pure document conversion without data injection, pass {}."New value: +"JSON data merged into the template — an object, or a top-level array (accessed with {d[i].field}). Access fields with {d.fieldName} tags. Nested objects: {d.customer.name}. Array loops: {d.items[i].description} … {d.items[i+1]}. Conditionals: {d.status == \"active\" ? \"Yes\" : \"No\"}. For pure document conversion without data injection, pass {}. Instead of inlining a large dataset, you may pass a STRING reference to the JSON: a local file path (e.g. \"/data/invoices.json\"), an HTTPS URL, or a base64-encoded JSON string — it is read and parsed server-side. Local paths resolve in stdio (local) mode only; URLs and base64 work in both transports." - removed
Input schema / properties / data / propertyNamesRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / data / typeRemoved value: -"object" - removed
Input schema / properties / enum / additionalPropertiesRemoved value: -{} - added
Input schema / properties / enum / anyOfAdded value: +[ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "string" + } +] - changed
Input schema / properties / enum / descriptionPrevious value: -"Enumeration map used with the :convEnum(TYPE) formatter to translate code values into human-readable labels. Define one key per enum type; each value is an object mapping code → label. Example: { \"STATUS\": { \"1\": \"Active\", \"2\": \"Inactive\", \"3\": \"Pending\" }, \"ROLE\": { \"A\": \"Admin\", \"U\": \"User\" } }. Template usage: {d.status:convEnum(STATUS)}, {d.role:convEnum(ROLE)}. Documentation: https://carbone.io/documentation.html#convenum-type-"New value: +"Enumeration map used with the :convEnum(TYPE) formatter to translate code values into human-readable labels. Define one key per enum type; each value is an object mapping code → label. Example: { \"STATUS\": { \"1\": \"Active\", \"2\": \"Inactive\", \"3\": \"Pending\" }, \"ROLE\": { \"A\": \"Admin\", \"U\": \"User\" } }. Template usage: {d.status:convEnum(STATUS)}, {d.role:convEnum(ROLE)}. May instead be passed by reference as a string — a local path, HTTPS URL, or base64 to a JSON file. Documentation: https://carbone.io/documentation.html#convenum-type-" - removed
Input schema / properties / enum / propertyNamesRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / enum / typeRemoved value: -"object" - added
Input schema / properties / outputPathAdded value: +{ + "description": "Optional local file path to save the generated document to (e.g. \"/home/user/out.pdf\" or \"~/out.pdf\"). When set, the file is written to disk and the tool returns the saved path + size instead of embedding the document inline — ideal for large files. Local (stdio) mode only; rejected in HTTP mode. Ignored for async/webhook renders (no document is returned inline).", + "type": "string" +} - changed
Input schema / properties / reportName / descriptionPrevious value: -"Filename for the generated document, returned in the Content-Disposition header. Supports Carbone tags resolved against the data at render time. Examples: \"invoice.pdf\" (static), \"{d.type}-{d.id}.pdf\" (dynamic), \"{d.client}-{d.date:formatD(YYYY-MM)}.docx\"."New value: +"Filename (WITHOUT extension) for the generated document, returned in the Content-Disposition header. Carbone automatically appends the extension that matches convertTo, so do not include one — passing \"invoice.pdf\" yields \"invoice.pdf.pdf\". Supports Carbone tags resolved against the data at render time. Examples: \"invoice\" (static), \"{d.type}-{d.id}\" (dynamic), \"{d.client}-{d.date:formatD(YYYY-MM)}\"." - added
Input schema / properties / returnLinkAdded value: +{ + "description": "If true, generate the document and return a public download URL instead of the file contents. The link is SHORT-LIVED and ONE-TIME — Carbone deletes the file after the first download — so it is meant for the end user to download once (do not fetch it programmatically). Works in stdio and HTTP. Mutually exclusive with outputPath, asAttachment, and webhookUrl (async).", + "type": "boolean" +} - removed
Input schema / properties / translations / additionalPropertiesRemoved value: -{ - "additionalProperties": { - "type": "string" - }, - "propertyNames": { - "type": "string" - }, - "type": "object" -} - added
Input schema / properties / translations / anyOfAdded value: +[ + { + "additionalProperties": { + "additionalProperties": { + "type": "string" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "string" + } +] - changed
Input schema / properties / translations / descriptionPrevious value: -"Translation map for multilingual documents. Requires \"lang\" to be set to select the active locale. Top-level keys are BCP-47 locale codes; values are key → translated-string maps. Template usage: {t(greeting)} is replaced by the matching string for the active locale. Example: { \"fr-fr\": { \"greeting\": \"Bonjour\", \"total\": \"Total\" }, \"en-us\": { \"greeting\": \"Hello\", \"total\": \"Total\" } }. Documentation: https://carbone.io/documentation.html#translations"New value: +"Translation map for multilingual documents. Requires \"lang\" to be set to select the active locale. Top-level keys are BCP-47 locale codes; values are key → translated-string maps. Template usage: {t(greeting)} is replaced by the matching string for the active locale. Example: { \"fr-fr\": { \"greeting\": \"Bonjour\", \"total\": \"Total\" }, \"en-us\": { \"greeting\": \"Hello\", \"total\": \"Total\" } }. These dictionaries get large, so you may instead pass a string reference — a local path, HTTPS URL, or base64 to a JSON file. Documentation: https://carbone.io/documentation.html#translations" - removed
Input schema / properties / translations / propertyNamesRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / translations / typeRemoved value: -"object"
- Changed
upload_template2 fields changed- changed
Input schema / properties / template / descriptionPrevious value: -"The template file. Accepts a local file path (e.g. /home/user/invoice.docx), a URL (https://example.com/template.docx), or a base64-encoded string. Supported formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, IDML, XML, Markdown (MD), PDF, and more. Full list: https://carbone.io/documentation/developer/http-api/generate-reports.html#output-file-type"New value: +"The template file. Accepts a local file path (e.g. /home/user/invoice.docx), a URL (https://example.com/template.docx), or a base64-encoded string. Supported formats: DOCX, XLSX, PPTX, ODT, ODS, ODP, ODG, HTML, XHTML, IDML, XML, Markdown (MD), PDF, and more. Full list: https://carbone.io/documentation/developer/http-api/generate-reports.md" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "id": { + "description": "Stable Template ID (when versioning is enabled).", + "type": "string" + }, + "name": { + "description": "Template display name.", + "type": "string" + }, + "size": { + "description": "Template size in bytes.", + "type": "number" + }, + "templateId": { + "description": "Template ID returned in legacy/non-versioned mode.", + "type": "string" + }, + "type": { + "description": "Detected template file type.", + "type": "string" + }, + "versionId": { + "description": "Version ID (SHA-256) of this uploaded version.", + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" +}
11 tool updates
v1.1.2- First observed
convert_document - First observed
delete_template - First observed
download_template - First observed
get_api_status - First observed
get_capabilities - First observed
list_categories - First observed
list_tags - First observed
list_templates - First observed
render_document - First observed
update_template_metadata - First observed
upload_template
TDQS
Scored across 11 tools
Most tools have clearly distinct purposes: template CRUD, rendering, conversion, and API introspection are well separated. The only potential ambiguity is between convert_document and render_document, but their descriptions strongly differentiate template-preserving conversion from data-injection rendering.
All tools follow a consistent verb_noun snake_case pattern: list_templates, upload_template, render_document, get_api_status, etc. This makes the tool surface predictable and easy to navigate.
11 tools is well-scoped for a document templating and rendering service: template CRUD, listing/management, conversion, rendering, and discovery/status each have a place. No redundancy or bloat.
The surface covers template CRUD (upload, list, download, delete, update metadata), rendering, conversion, category/tag discovery, and API health. This is comprehensive for Carbone's core workflows; no obvious dead ends.
Maintenance
Related MCP Connectors
Generate PDF, Word (.docx) and PowerPoint (.pptx) documents from Markdown over MCP.
MCP server for Api2Pdf — generate PDFs & images from HTML, URLs or office files; merge, barcodes.
- pdfs.buildOAuthbuild.pdfs
Design, publish and render PDF templates with Typst. Full template lifecycle over MCP.
Use your own Word templates to convert Markdown → DOCX/PDF/HTML from any MCP-compatible AI.
Related MCP Servers
- AlicenseBqualityDmaintenanceA universal MCP server for document processing, conversion, and automation. Handle PDF, DOCX, HTML, Markdown, and more through a unified API and toolset.1316 npm139MIT
- AlicenseAqualityDmaintenanceMCP server for Word document (.docx) creation and manipulation — the production-grade document automation tool for AI agents.936 npmMIT
- AlicenseCqualityDmaintenanceA unified MCP server for document processing that enables creating, editing, and converting Word documents (DOCX), PDFs, Markdown, and images, with support for templates, formatting, and batch operations.100MIT
- FlicenseAqualityCmaintenanceMCP server for rendering, parsing, converting, and editing Office documents (Excel, PowerPoint, Word) from a structured JSON spec, using LibreOffice WASM for conversion and preview.51-