Carbone MCP

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

No annotations provided, so description carries full burden. Adds valuable context that operation does not persist templates (unlike siblings) and hints at converter selection logic ('for best fidelity', 'full CSS/JS rendering'). However, lacks disclosure of output format (file returned how?), idempotency, or rate limits.

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?

Well-structured and front-loaded: purpose → scope → input methods → alternative tool → concrete examples. Lengthy due to extensive examples, but each demonstrates distinct parameter combinations (converter variants, format pairs) that justify the space.

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

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

With 3 parameters fully documented in schema, description provides comprehensive usage context including input source options and sibling differentiation. Only gap is absence of output specification (return value format) given no output schema exists, which would complete the picture.

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?

Despite 100% schema coverage, description adds significant value through concrete usage examples showing parameter interaction (e.g., converter: 'O' for Office fidelity, converter: 'C' for HTML rendering). These patterns supplement the schema's technical definitions with semantic guidance.

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?

Opens with specific verb+resource ('Convert any document to another format') and immediately distinguishes from template-based siblings ('without storing a template'). Explicitly contrasts with render_document later, clarifying its niche in the tool ecosystem.

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?

Provides explicit when-not-to-use guidance: 'Use render_document instead when you need data injection ({d.field} tags), translations, or batch generation.' Clearly delineates boundary between simple conversion and template rendering workflows.

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

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

With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: the soft-delete mechanism, the 24-hour garbage collection delay, and the distinction between deleting all versions versus a specific version. It does not mention potential error states or return values, preventing a perfect score.

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 efficiently structured in four logical clauses: action definition, behavioral mechanism (soft delete), parameter usage patterns, and alternative tool reference. Every sentence adds distinct value 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 a single-parameter deletion tool without output schema, the description is comprehensive. It covers the deletion mechanism, timing semantics, parameter interpretation, and alternative workflows. No critical information gaps remain given the tool's relative simplicity.

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?

While the schema has 100% coverage (baseline 3), the description adds crucial semantic meaning by explaining the behavioral difference between passing a Template ID (deletes all versions) versus a Version ID (deletes only that specific version), and notes where these IDs originate (upload_template and list_templates).

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 action ('Delete a stored Carbone template') and distinguishes this tool from siblings by specifying it performs a 'soft delete' rather than immediate deletion, and explicitly differentiates it from update_template_metadata which is reserved for immediate/scheduled deletion.

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?

Provides explicit guidance on when to use the sibling tool update_template_metadata instead ('For immediate or scheduled deletion, use update_template_metadata...'), including specific parameter values (expireAt = 42000000000). Also clarifies the two distinct usage patterns (Template ID vs Version ID) and their different scopes.

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

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

No annotations provided, so description carries full disclosure burden. Explains versioning behavior (Template ID returns deployed version, Version ID returns specific version) but omits safety characteristics (read-only nature), return format (binary stream vs base64), error handling, and rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with zero waste: definition with examples, use cases, parameter guidance. Front-loaded with core action, appropriate length for single-parameter tool, no redundant phrases.

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?

Appropriate for low complexity (single parameter, flat structure). Covers primary use cases and parameter versioning logic. Minor gap: no mention of return format/file handling since no output schema exists to document the binary response.

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 has 100% description coverage, establishing baseline of 3. Description adds narrative framing ('Pass a Template ID...') but largely overlaps with schema details regarding ID behavior; does not add syntax examples or validation rules beyond 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?

States specific verb 'Download' with exact resource 'original source file of a stored Carbone template' and concrete examples (DOCX, XLSX, PPTX, HTML). Effectively distinguishes from render_document (final output generation) and upload_template (inverse operation) by emphasizing source file retrieval.

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?

Provides clear use cases ('inspect, edit, or back up') and explains parameter logic for version selection (deployed vs specific). Lacks explicit named alternatives or negative constraints (e.g., contrasting with render_document for final document generation).

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

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

No annotations provided, so description carries full burden. Discloses return values ('current API version and a status message') which is crucial given no output schema exists. However, omits error conditions, authentication requirements, or rate limiting details that would help an agent handle failures.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: purpose declaration, return value disclosure (compensating for missing output schema), and usage context. No redundancy or filler.

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

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

Adequate for a zero-parameter diagnostic tool. Compensates for missing output schema by describing return values. Could be improved by mentioning error states or authentication, but sufficient for basic connectivity verification use case.

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?

Zero parameters per schema, establishing baseline 4. Description correctly omits parameter discussion since none exist, avoiding confusion.

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 uses specific verb 'Check' with clear resource 'Carbone API health and version'. Distinctly different from document-manipulation siblings (convert_document, render_document, etc.) which operate on templates/documents rather than API meta-status.

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?

Provides clear usage context ('verifying connectivity and confirming which Carbone version is active') establishing when to invoke this diagnostic tool. Lacks explicit 'when not to use' or alternatives, but unnecessary given this is the only health-check endpoint among document-operation siblings.

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

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

With no annotations provided, the description carries the full burden of disclosure. It successfully describes the return payload contents (formats, features, examples, links), indicating this is a read-only discovery operation. It could be improved by mentioning caching behavior or response format, but adequately covers the essential behavioral trait for a discovery tool.

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 with zero waste: the first defines the return value and content, the second provides actionable usage guidance. Information is front-loaded and every word earns its place. Appropriate length for a parameter-less utility function.

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, discovery purpose) and absence of an output schema, the description adequately explains what the function returns. It lists the specific types of information included in the capability summary, providing sufficient context for an agent to understand when and why to invoke it.

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?

The input schema contains zero parameters, which establishes a baseline score of 4. The description correctly does not invent parameters, and no additional parameter context is needed for this simple discovery endpoint.

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 specific verbs ('Returns') and clearly identifies the resource ('summary of all Carbone capabilities'), including concrete examples of what the summary contains (formats, features, examples, documentation). It clearly distinguishes itself from operational siblings like convert_document or delete_template by focusing on system discovery rather than resource manipulation.

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?

Provides explicit temporal guidance ('Call this first') and clear conditionality ('if you are unsure what Carbone can do'), establishing it as the entry point for discovery before using other tools. This directly addresses when to use this tool versus the operational alternatives.

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

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

Without annotations, the description carries the full disclosure burden. It adds behavioral context by specifying the scope ('currently in use'), explaining the domain concept ('act like folders'), and revealing what the return value contains ('returned names'). It implies read-only behavior through the verb 'List', though it lacks explicit safety declarations or format specifics (array vs object).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences efficiently cover purpose, conceptual analogy with examples, and usage guidance. Every sentence earns its place: the first defines the action, the second explains the data model, and the third provides integration context. Well-structured and appropriately sized.

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) and lack of output schema or annotations, the description sufficiently compensates by explaining what is returned and how to use it. It misses minor details like explicit return type structure, but adequately covers the essential behavioral and usage context for a list utility.

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 zero parameters and 100% schema coverage (trivially), the baseline applies. The description correctly requires no additional parameter explanation since the tool accepts no inputs, and the schema adequately reflects this.

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 ('List') and clear resource ('template categories'), explicitly defining the scope as 'currently in use in your Carbone account'. It effectively distinguishes from siblings like list_templates and list_tags by clarifying that categories are organizational folders, not the templates themselves or tags.

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 to use the tool ('Use the returned names as the category filter') and names specific sibling alternatives where these values are consumed ('list_templates or upload_template'). It also provides the conceptual model (categories as folders) to guide selection.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the domain semantics (tags are free-form labels) and crucial operational constraints (API does not support filtering by tag). It lacks explicit safety declarations (e.g., 'read-only'), though the verb 'List' implies this; the behavioral guidance regarding manual filtering is valuable context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with zero waste: sentence 1 states purpose, sentence 2 provides domain context with examples, sentence 3 gives critical usage constraints. The information is front-loaded and structured logically from 'what' to 'how to use'.

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 zero-parameter tool without output schema, the description adequately compensates by explaining what tags represent and providing usage examples. It covers the operational workflow completely. A minor gap remains in not explicitly describing the return structure (e.g., array format), though this is partially implied by 'List'.

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?

The input schema contains zero parameters, which establishes a baseline of 4. The description appropriately does not invent parameters, focusing instead on explaining the semantic meaning of the returned data (what tags are) rather than inputs.

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 ('List') and resource ('tags'), clarifies the scope ('across templates in your Carbone account'), and defines what tags are with concrete examples ('sales', 'billing', 'v2'). It effectively distinguishes this from list_templates by explaining the tag discovery workflow.

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 'Note' explicitly states when to use this tool (to discover available tags) and provides the exact alternative workflow ('then call list_templates and filter the results manually'). It clearly explains the API limitation necessitating this two-step process, which is critical for correct agent behavior.

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

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

With no annotations provided, the description carries the full disclosure burden. It successfully communicates the pagination mechanism ('cursor-based'), a critical API limitation (no tag filtering), and data scope behavior (includeVersions returns all versions vs default deployed version). It lacks explicit mention of the read-only nature or response format, but covers the key behavioral traits needed for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Five well-structured sentences with zero waste. Front-loaded with the core action, followed by filtering options, specific parameter guidance, pagination notes, and a critical limitation with alternative. Every sentence earns its place; no redundancy with the schema.

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?

Comprehensive for an 8-parameter tool with no output schema. Covers all major parameter groups (filtering, pagination, versioning) and critical API constraints. The only gap is the lack of description for return values (which would be helpful given no output schema exists), but the behavioral and usage guidance is complete enough for confident invocation.

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, the baseline is 3. The description adds semantic value by explaining the purpose of includeVersions ('see the full version history') and contextualizing cursor usage ('for large collections'). It also explicitly maps filtering capabilities to the Carbone domain (Template ID vs Version ID distinction), adding clarity 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 opens with a clear, specific purpose ('List stored Carbone templates') including the resource type and supported operations (filtering, search, pagination). It effectively distinguishes from siblings by explicitly referencing list_tags as the correct tool for tag discovery, clarifying this tool's scope boundaries.

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?

Provides explicit when-not-to-use guidance ('filtering by tags is not supported') and names the specific alternative tool ('use list_tags'). It also clarifies when to use includeVersions ('to see the full version history') and cursor ('for large collections'), giving clear usage contexts.

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

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

With no annotations provided, the description carries full behavioral burden and excels: it discloses async webhook POST behavior, timeout differences (5 min vs 60s), mutual exclusivity constraints ('provide exactly one, never both'), and side effects (renderId posted to URL). It also notes default values (Europe/Paris timezone, LibreOffice converter) implicitly expected by the system.

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?

Four sentences, zero waste. Front-loaded with core purpose, followed by feature enumeration, async explanation, and batch constraint. Every sentence earns its place despite the tool's high complexity (21 parameters).

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?

Missing explicit description of synchronous return values (does it return binary content or a download URL?). Given no output schema exists and the tool is a generation endpoint, describing the successful response payload is essential for agent invocation confidence. Async path is well-covered via webhook explanation.

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?

Given 100% schema description coverage (baseline 3), the description adds conceptual value by framing parameters into two distinct usage modes and highlighting critical constraints (mutual exclusivity, async requirement for batch) that might be scattered across individual parameter descriptions. It provides the mental model the schema lacks.

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 precise verb-resource-action ('Generate a document by merging...') and immediately distinguishes the two primary operational modes (templateId vs inline template). It explicitly references sibling tool upload_template ('use upload_template + templateId when you need to reuse'), clearly delineating responsibilities.

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 states when to use ephemeral inline templates versus stored templates, and mandates async mode for batch generation ('Async mode is required when using batchSplitBy'). Deducting one point because it doesn't explicitly contrast with convert_document sibling for pure conversion workflows.

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

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

With no annotations provided, the description carries full disclosure burden. It successfully signals the destructive potential of expireAt ('trigger immediate deletion') and the workflow impact of deployedAt ('activate...for rendering'). It does not mention rate limits, authorization requirements, or the partial-update nature of unspecified fields, but covers the safety-critical behaviors.

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?

Extremely efficient two-sentence structure. The first sentence establishes scope and lists editable fields; the second provides targeted usage guidance for the two non-obvious timestamp parameters. Every clause conveys essential information with zero redundancy or filler.

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

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

Given the rich schema (100% coverage, 7 parameters) and lack of output schema or annotations, the description adequately covers the high-level purpose and critical behavioral nuances (deletion triggering, version activation). It appropriately delegates the Template ID vs Version ID distinction to the schema's detailed parameter descriptions while ensuring the agent understands the consequences of setting the timestamp fields.

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?

While the schema has 100% coverage, the description adds significant semantic value beyond mechanical field definitions. It translates 'deployedAt' into the user goal 'activate a specific version for rendering' and 'expireAt' into 'schedule or trigger immediate deletion,' explaining the 'why' and 'what for' rather than just the 'what'.

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 ('Update') and resource ('metadata of a stored template'), followed by an explicit enumeration of editable fields (name, comment, category, tags, deployment timestamp, expiration). It clearly distinguishes from sibling tools like delete_template by framing deletion as a metadata-scheduled action ('Use expireAt to...trigger immediate deletion') rather than a direct deletion operation, and links deployedAt to the render_document workflow.

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?

Provides explicit guidance on the two critical timestamp parameters: 'Use deployedAt to activate a specific version for rendering' and 'Use expireAt to schedule or trigger immediate deletion.' This explains when to use these specific fields. However, it lacks an explicit 'when not to use' statement (e.g., when to prefer delete_template over expireAt for immediate deletion).

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

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

With no annotations provided, the description carries full behavioral burden. It effectively explains the versioning system (multiple versions under stable ID, deployedAt controlling active version) and lists accepted formats. Missing safety/idempotency details (e.g., storage limits, overwrite behavior), but covers core operational model well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with zero waste. Front-loaded with primary action and immediate next-step guidance. Each sentence covers distinct domains: workflow integration, versioning mechanics, and format support. No redundant or filler content.

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 10-parameter upload tool with no output schema, the description covers the essential conceptual framework (upload→render workflow, versioning model, format support). Mentions the key return value (Template ID). Missing explicit return structure details and error conditions, but sufficiently complete given the rich schema documentation compensates for parameter-level details.

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%, establishing a baseline of 3. The description adds value by explaining how deployedAt functions to control version activation (business logic beyond the schema's technical description) and contextualizing the versioning parameter through the versioning system explanation. It also clarifies the template parameter's relationship to the render workflow.

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?

States specific action ('Upload and store') and resource ('reusable Carbone template'). Explicitly distinguishes from sibling render_document by stating it returns a Template ID for use with that tool. Clearly scopes functionality to template storage with versioning support.

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?

Provides explicit workflow guidance ('Once uploaded, use render_document...') establishing the correct sequence of operations. Explains versioning behavior and deployment timing (deployedAt). Lacks explicit 'when not to use' guidance or distinction from update_template_metadata, but effectively orients the agent within the document generation pipeline.

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