Carbone MCP
Server Details
Generate PDF/DOCX/XLSX/PPTX from templates+JSON. Convert Office/HTML/MD to PDF. Universal templating
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- carboneio/carbone-mcp
- GitHub Stars
- 4
- Server Listing
- Carbone MCP
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. Two input forms are accepted: (1) HTTPS URL — the file is downloaded automatically, e.g. "https://example.com/file.pptx". (2) Base64-encoded string — the raw file content encoded as base64. Local file paths are NOT accepted — this server is reached over HTTP, so a path would resolve on the server's disk rather than yours and is rejected. Upload the bytes as base64, or host the file at a URL. 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 | NOT AVAILABLE on this server, which is reached over HTTP: the converted document would be written to the server's disk instead of yours, so passing outputPath is rejected. Use asAttachment to receive the bytes, or returnLink for a one-time download URL. | |
| 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 declare readOnlyHint/openWorldHint/idempotentHint, but the description carries substantial additional behavioral burden and delivers richly: outputs can be rejected (outputPath 'NOT AVAILABLE... rejected'), local file paths rejected, legacy DOC/XLS/PPT rejected as input, returnLink is 'SHORT-LIVED and ONE-TIME,' converter 'I' SILENTLY IGNORES security options ('NEVER pick "I" when the request needs a password'), and reportName double-extension trap. No contradiction with the benign 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?
Front-loaded with core purpose and clearly structured (purpose → sibling contrast → common conversions). However, it is a dense wall of text that partially duplicates schema content — the converter engine explanation, format lists, and output-mode details already live in the parameter descriptions. The conversion examples earn their place, but some restatement of schema material could be trimmed.
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 high-complexity tool (9 params, converter engine selection, 100+ format matrix, multiple delivery modes, and no output schema to describe returns), the description is exceptionally complete: it covers input limits, output delivery behavior (inline vs. temp file/asAttachment), edge cases (hardRefresh, returnLink lifecycle, egress authorization), and impossibility cases (outputPath rejected, DOC/XLS rejected). Nothing material is left for the agent to discover at runtime.
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 schema's own param descriptions are already rich (file input forms, converter engine details, formatOptions examples). The description adds value beyond the schema by demonstrating concrete parameter combinations for common conversions (file: 'report.docx', convertTo: 'pdf', converter: 'I'), and by flagging pitfalls like the reportName extension trap and hardRefresh necessity. Slightly redundant with schema but still additive.
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?
Description opens with a specific verb+resource: 'Convert any document to another format without storing a template,' and immediately differentiates from the sibling render_document by stating that Carbone tags are preserved, not resolved, and that render_document handles data injection, translations, and batch generation. It also scopes the tool's reach (100+ format combinations) and gives concrete conversion examples.
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 an explicit alternative: 'Use render_document instead when you need data injection ({d.field} tags resolved), translations, or batch generation.' It also defines a specific use case for this tool ('this is also how you proof a template in another format') and adds per-conversion engine recommendations (converter 'I' for fastest DOCX→PDF, 'O' for PPTX fidelity, 'C' for HTML full rendering), giving the agent actionable selection criteria.
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 | NOT AVAILABLE on this server, which is reached over HTTP: the template file would be written to the server's disk instead of yours, so passing outputPath is rejected. Use asAttachment to receive the bytes, or returnLink for a one-time download URL. | |
| 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 readOnly and idempotent, but the description adds substantial behavioral context: the distinction between Template ID (deployed version) and Version ID, the sample:true behavior, the error if no sample exists, and the note that outputPath is rejected on HTTP servers. These go well beyond the structured fields without contradiction.
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 four sentences, each serving a distinct purpose: defining the tool, stating use cases, explaining ID semantics, and covering the sample option. It is front-loaded with the most critical information and uses no superfluous words.
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, complex ID semantics, and HTTP-specific limitations, the description covers all essential aspects: version selection, sample retrieval, and the unavailable outputPath behavior. It even hints at error conditions. No critical gaps are apparent given the tool's complexity and the absence of an output schema.
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 set to 3. The main description text adds minimal parameter-level nuance beyond what is already in the schema (e.g., 'sample:true' is mentioned, but the parameter description already explains it fully). The description does not significantly enrich parameter understanding beyond schema definitions.
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 'Download[s] the original source file of a stored Carbone template' with specific examples (DOCX, XLSX, etc.), which precisely conveys the verb and resource. It differentiates from siblings like render_document by emphasizing 'source file,' making the purpose 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?
It provides clear usage scenarios ('Use this to inspect, edit, or back up a template') and references the alternative workflow 'before calling render_document against an unfamiliar template.' However, it does not explicitly state when NOT to use the tool or name an alternative like render_document for generated output, which would strengthen the guidance.
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?
Beyond the readOnly/openWorld/idempotent annotations, it discloses important quirks: the null ID behavior for versioning-disabled uploads, cursor-based pagination via nextCursor, and the includeVersions flag's effect. This gives the agent practical expectations that annotations alone do not convey.
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 compact and front-loaded: first sentence states scope, second covers filters and pagination, third adds a critical limitation, and fourth clarifies version quirks. Every sentence earns its place with no redundancy.
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 list tool with an output schema, this description covers filtering options, pagination, version handling, unsupported operations, and an edge case with null IDs. It provides sufficient context for an agent to use the tool correctly and know when to consult siblings.
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%, so baseline is 3. The description adds valuable context beyond the schema by warning that tags cannot be filtered and explaining that templates uploaded without versioning are identified by versionId. It could go slightly further by restating which filter is best for common use cases, but overall it adds meaningful parameter nuance.
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 a specific verb and resource: 'List stored Carbone templates with filtering, search, and pagination.' It clearly distinguishes the tool from siblings like list_tags and list_categories by enumerating the template-specific filters and behaviors.
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 when not to use a filtering approach ('filtering by tags is not supported by the Carbone API') and names the alternative: 'use list_tags to discover tags, then filter results manually.' It also provides cross-tool guidance about passing versionId in place of Template ID for delete_template and download_template.
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: an HTTPS URL or a base64-encoded JSON string (local file paths are not accepted over HTTP) — 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 — an HTTPS URL or a base64-encoded JSON string (local file paths are not accepted over HTTP). 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. Two input forms are accepted: (1) HTTPS URL — the file is downloaded automatically, e.g. "https://example.com/file.pptx". (2) Base64-encoded string — the raw file content encoded as base64. Local file paths are NOT accepted — this server is reached over HTTP, so a path would resolve on the server's disk rather than yours and is rejected. Upload the bytes as base64, or host the file at a URL. 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 — an HTTPS URL or a base64-encoded JSON string (local file paths are not accepted over HTTP). | |
| outputPath | No | NOT AVAILABLE on this server, which is reached over HTTP: the generated document would be written to the server's disk instead of yours, so passing outputPath is rejected. Use asAttachment to receive the bytes, or returnLink for a one-time download URL. 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 — an HTTPS URL or a base64-encoded JSON string (local file paths are not accepted over HTTP). 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 — an HTTPS URL or a base64-encoded JSON string (local file paths are not accepted over HTTP). | |
| 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?
The description discloses important behaviors like async mode, webhook callback, and outputPath rejection. However, it incorrectly states that template accepts 'file path' while the schema explicitly rejects local file paths, creating a misleading impression about valid inputs.
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 packs a lot of information into a single paragraph without redundancy. It is front-loaded with the primary purpose and modes, then summarizes features concisely. While slightly dense, every sentence contributes meaningful context.
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 26 parameters and no output schema, the description provides a solid high-level overview of all capabilities (format conversion, multilingual, currency, batch, async). It does not enumerate every parameter but relies on the schema for details, which is appropriate given the schema's richness.
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 adds only a high-level overview of modes and features, which mostly repeats schema information. It does not provide additional parameter-level meaning beyond what the schema already offers.
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 core purpose: 'Generate a document by merging a Carbone template with JSON data.' It also identifies two distinct modes (templateId vs inline template), which differentiates it from sibling tools like upload_template and convert_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 on when to use each mode: 'Use this for ephemeral renders; use upload_template + templateId when you need to reuse the template.' It also states that async mode is required for batch generation, and clarifies that outputPath is not available on HTTP servers.
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 MetadataAIdempotentInspect
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?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds crucial behavioral context: it clarifies that expireAt triggers automatic deletion, deployedAt activates a version, and the tool can be used for immediate deletion ('use 42000000000'). This goes beyond what annotations provide.
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 and front-loaded with the primary purpose, followed by two key usage notes. It's efficient but could be slightly more structured, though the schema covers details.
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 metadata update tool with 8 parameters, full schema coverage, and rich annotations, the description covers the critical behavioral aspects (deployment activation, expiration/deletion) that the schema and annotations don't. No output schema exists, but the return value is likely standard.
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 includes detailed descriptions for each parameter, such as the special '42000000000' sentinel for immediate actions and the behavior of templateId vs version ID. The description adds context about deployment timestamp semantics beyond the raw schema.
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 purpose: 'Update the metadata of a stored template' and enumerates specific fields (name, comment, category, tags, deployment timestamp, expiration). It distinguishes itself from siblings like delete_template and upload_template by focusing on metadata updates with deployment/expiration semantics.
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 usage guidance: 'Use deployedAt to activate a specific version for rendering. Use expireAt to schedule or trigger immediate deletion.' This helps the agent decide when to use this tool versus alternatives, though it could mention when not to use it.
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. Two input forms are accepted: (1) HTTPS URL — the file is downloaded automatically, e.g. "https://example.com/file.pptx". (2) Base64-encoded string — the raw file content encoded as base64. Local file paths are NOT accepted — this server is reached over HTTP, so a path would resolve on the server's disk rather than yours and is rejected. Upload the bytes as base64, or host the file at a URL. 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 indicate this is a write operation (readOnlyHint: false) and not destructive (destructiveHint: false). The description adds behavioral context by explaining versioning: multiple versions under a single ID, with deployedAt controlling the active version. It also mentions that a returned Template ID is used for rendering. This goes beyond the annotations without contradicting them, though it does not detail side effects like immediate deletion or replacement behavior.
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 three sentences, front-loading the core purpose prominently. It includes essential information (reusability, rendering connection, versioning, supported formats) without redundancy. Every sentence contributes value, and the structure is efficient and clear.
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 (10 parameters) and the presence of an output schema, the description is appropriately high-level. It explains the purpose, versioning model, and supported formats, which are the key contextual points. It does not delve into parameter specifics (already in schema) or return values (covered by output schema), so it is complete for an agent to understand the tool's role and integration with render_document.
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 provides a high-level overview of versioning and formats, but most parameter-specific details (e.g., template input forms, deployedAt semantics) are already in the schema. The description adds no new parameter meaning beyond what the schema already states, aligning with the baseline.
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: 'Upload and store a reusable Carbone template.' It specifies the resource (template), the action (upload), and its purpose (to later render documents). It also distinguishes itself from sibling tools by mentioning the returned Template ID and its use with render_document, which sets it apart from render_document, download_template, and others.
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 context on when to use the tool: 'Once uploaded, use render_document with the returned Template ID to generate documents from it.' It also explains versioning behavior (deployedAt controls active version), which guides usage. However, it doesn't explicitly compare to update_template_metadata or state when not to use it, but the context is clear enough.
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. Dates show when Glama detected each change.
6 tool updates
- 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. Two input forms are accepted: (1) HTTPS URL — the file is downloaded automatically, e.g. \"https://example.com/file.pptx\". (2) Base64-encoded string — the raw file content encoded as base64. Local file paths are NOT accepted — this server is reached over HTTP, so a path would resolve on the server's disk rather than yours and is rejected. Upload the bytes as base64, or host the file at a URL. 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: +"NOT AVAILABLE on this server, which is reached over HTTP: the converted document would be written to the server's disk instead of yours, so passing outputPath is rejected. Use asAttachment to receive the bytes, or returnLink for a one-time download URL." - 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: +"NOT AVAILABLE on this server, which is reached over HTTP: the template file would be written to the server's disk instead of yours, so passing outputPath is rejected. Use asAttachment to receive the bytes, or returnLink for a one-time download URL." - 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 — an HTTPS URL or a base64-encoded JSON string (local file paths are not accepted over HTTP)." - 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 — an HTTPS URL or a base64-encoded JSON string (local file paths are not accepted over HTTP)." - 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: an HTTPS URL or a base64-encoded JSON string (local file paths are not accepted over HTTP) — 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 — an HTTPS URL or a base64-encoded JSON string (local file paths are not accepted over HTTP). 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: +"NOT AVAILABLE on this server, which is reached over HTTP: the generated document would be written to the server's disk instead of yours, so passing outputPath is rejected. Use asAttachment to receive the bytes, or returnLink for a one-time download URL. 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. Two input forms are accepted: (1) HTTPS URL — the file is downloaded automatically, e.g. \"https://example.com/file.pptx\". (2) Base64-encoded string — the raw file content encoded as base64. Local file paths are NOT accepted — this server is reached over HTTP, so a path would resolve on the server's disk rather than yours and is rejected. Upload the bytes as base64, or host the file at a URL. 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 — an HTTPS URL or a base64-encoded JSON string (local file paths are not accepted over HTTP). 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. Two input forms are accepted: (1) HTTPS URL — the file is downloaded automatically, e.g. \"https://example.com/file.pptx\". (2) Base64-encoded string — the raw file content encoded as base64. Local file paths are NOT accepted — this server is reached over HTTP, so a path would resolve on the server's disk rather than yours and is rejected. Upload the bytes as base64, or host the file at a URL. 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
- 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" -]
1 tool update
- Changed
render_document25 fields changed- 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" - 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" - 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"
2 tool updates
- Changed
convert_document1 field changed- 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"
- 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.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"
2 tool updates
- Changed
convert_document2 fields changed- changed
Input schema / properties / asAttachment / descriptionPrevious value: -"If true, return the document as a downloadable file attachment (base64 resource) instead of inline text/image. Use when the user wants to download or save the file rather than read its content inline — especially in HTTP mode where outputPath is unavailable. Default: false (text inline, images viewable, other binaries as resources). Ignored when outputPath is set."New value: +"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." - 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
render_document2 fields changed- changed
Input schema / properties / asAttachment / descriptionPrevious value: -"If true, return the document as a downloadable file attachment (base64 resource) instead of inline text/image. Use when the user wants to download or save the file rather than read its content inline — especially in HTTP mode where outputPath is unavailable. Default: false (text inline, images viewable, other binaries as resources). Ignored when outputPath is set."New value: +"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." - 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" +}
8 tool updates
- Changed
convert_document3 fields changed- added
Input schema / properties / asAttachmentAdded value: +{ + "description": "If true, return the document as a downloadable file attachment (base64 resource) instead of inline text/image. Use when the user wants to download or save the file rather than read its content inline — especially in HTTP mode where outputPath is unavailable. Default: false (text inline, images viewable, other binaries as resources). Ignored when outputPath 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" + } +] - 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" +}
- 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_document4 fields changed- added
Input schema / properties / asAttachmentAdded value: +{ + "description": "If true, return the document as a downloadable file attachment (base64 resource) instead of inline text/image. Use when the user wants to download or save the file rather than read its content inline — especially in HTTP mode where outputPath is unavailable. Default: false (text inline, images viewable, other binaries as resources). Ignored when outputPath 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 } 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" + } +] - 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)}\"."
- Changed
upload_template1 field changed- 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" +}
1 tool update
- Changed
render_document2 fields changed- added
Input schema / properties / webhookHeadersAdded value: +{ + "additionalProperties": { + "type": "string" + }, + "description": "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.", + "propertyNames": { + "type": "string" + }, + "type": "object" +} - added
Input schema / properties / webhookUrlAdded value: +{ + "description": "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\".", + "format": "uri", + "type": "string" +}
11 tool updates
- 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
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Generate HTML to PDF documents in bulk or single — raw replacements or based on conditions, loops
Cloud PDF generation from HTML, CSS and XSL-FO, with PDF/A and PDF/UA support.
Markdown in, any format out. PDFs merged, split, watermarked. Runs on our own doc engines.
Turn an HTML template plus JSON into a finished PDF: a quote, invoice, work order or certificate.
Related MCP Servers
AlicenseAqualityBmaintenanceRenders PDFs from HTML templates or saved templates and spreadsheet data, with batch job support and document retrieval.465841MIT
Dokmatiq DocGenofficial
AlicenseAqualityCmaintenancePDF/DOCX/Excel generation from HTML/Markdown with stationery overlay, ZUGFeRD/XRechnung e-invoicing, digital signing, form filling, and AI receipt OCR with DATEV/SKR03 export.40MIT- FlicenseNot gradedqualityBmaintenanceEnables conversion between PDF/Office documents and structured JSON, supporting extraction and generation of document content.-
- AlicenseAqualityAmaintenanceMCP server for Office documents — create, edit, fill templates, convert, and extract Word/Excel/PowerPoint. LaTeX-style markup, math formulas, PDF export, template loops, and document diff. stdio / SSE / Streamable HTTP with auth and rate limiting.12Apache 2.0
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
Each tool targets a distinct resource or action: document conversion, template lifecycle, metadata, status checks, and listing operations are all clearly separated. The potential overlap between convert_document and render_document is explicitly addressed in their descriptions, with clear guidance on when to use each.
All tool names follow a consistent snake_case verb_noun pattern: convert_document, delete_template, download_template, get_api_status, list_templates, render_document, upload_template, etc. Verbs are precise and match the operation performed, making the API predictable.
Eleven tools is well-scoped for a document templating and rendering server. Each tool covers a meaningful part of the workflow: template management, rendering, conversion, metadata, and account-level discovery, without redundancy or bloat.
The tool surface covers the full template lifecycle: upload, list, download, update metadata, delete, and render. It also includes conversion, status checking, capability discovery, and tag/category enumeration, leaving no obvious dead ends for typical Carbone workflows.