Skip to main content
Glama

Carbone MCP

by io.carbone

Upload Template

upload_template

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoExisting 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.
nameYesDisplay name for the template (e.g. "Invoice Template", "NDA Contract").
tagsNoTags for searchability and filtering (e.g. ["sales", "billing", "v2"]).
sampleNoSample input data attached to the template for testing in Carbone Studio. Each item must include data, complement, translations, and enum objects.
commentNoFree-text comment to describe the template version or its purpose.
categoryNoGroup templates into folders/categories (e.g. "invoices", "legal", "hr").
expireAtNoUTC Unix timestamp (seconds) at which this template will be automatically deleted. Use 42000000000 to delete immediately (special "NOW" sentinel value).
templateYesThe 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
deployedAtNoUTC 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).
versioningNoEnable 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

TableJSON Schema
NameRequiredDescriptionDefault
idNoStable Template ID (when versioning is enabled).
nameYesTemplate display name.
sizeNoTemplate size in bytes.
typeNoDetected template file type.
versionIdNoVersion ID (SHA-256) of this uploaded version.
templateIdNoTemplate ID returned in legacy/non-versioned mode.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Carbone MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources