Carbone MCP

Inspect Template

inspect_template

Read-onlyIdempotent

List the Carbone tags a template uses and return a sample JSON dataset matching its structure. Call it before render_document when you do not know which data a template expects. Pass exactly one of templateId (a stored template: Template ID or Version ID) or template: an HTTPS URL or a base64-encoded string (local file paths are not accepted over HTTP). It runs one render on the Carbone account and discards the document. {t()} translation tags are not listed.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`template`	No	Inline template to inspect, without storing it. 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, MD, TXT, CSV, RTF, PDF. Carbone reads XML-based and text-based documents (plus PDF): the legacy binary Office formats DOC, XLS and PPT are rejected as input, although they are valid outputs. Re-save such a file as DOCX, XLSX or PPTX first. Mutually exclusive with templateId — provide exactly one, never both.
`templateId`	No	The ID of a stored template to inspect. Two ID formats are accepted: (1) Template ID (64-bit) — the deployed version is inspected. (2) Version ID (SHA-256) — that exact version is inspected. Both are returned by upload_template and list_templates. Mutually exclusive with template — provide exactly one, never both.

Output Schema

TableJSON Schema

Name	Required	Description
`tags`	Yes	The Carbone tags of the template, as written, e.g. "{d.customer.name}", "{d.items[i].label}", "{c.company}". {t()} translation tags are not listed.
`error`	No	Error reported by Carbone while inspecting; only present when there is one.
`sample`	Yes	A sample dataset matching the template structure, with placeholder values: { "data": {...}, "complement": {...} }. Pass sample.data as render_document data, and sample.complement as complement.
`signatures`	No	Signature fields found in the template; only present when there are any.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 14, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds genuinely non-derivable behavior: it consumes one render on the Carbone account and discards the document, and it explicitly rejects local file paths because the server is reached over HTTP. It also flags an output limitation (translation tags are not listed), which is real context beyond the annotation set.

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?

Front-loaded with what the tool returns, then the call condition, then the input constraint, then the side effect and the caveat. Every sentence carries actionable content with no filler or restated title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no prose. Combined with the when-to-use trigger, the exactly-one input rule, the quota side effect and the translation-tag caveat, an agent has everything needed to call this correctly on the first attempt.

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 coverage is 100%: the schema already documents both input forms, the Template ID vs Version ID distinction, supported formats and the mutual-exclusivity rule. The description restates rather than extends that information, so the baseline 3 applies.

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?

Names a specific verb+resource: lists the Carbone tags a template uses AND returns a sample JSON dataset matching its structure. It is clearly differentiated from siblings by explicitly positioning itself upstream of render_document, so an agent can tell it apart from list_tags or get_capabilities without reading either schema.

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?

Gives an explicit trigger condition — 'Call it before render_document when you do not know which data a template expects' — naming the sibling it precedes. It does not cover exclusions (e.g. when you already know the payload, or how it relates to list_tags), so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Carbone MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.