Skip to main content
Glama
Sign In
Carbone MCP

Carbone MCP

Official
by carboneio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Templates

list_templates
Read-onlyIdempotent

Find and filter stored Carbone templates by ID, version, category, or origin; search and paginate results to browse templates or view version history.

Instructions

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. Each result carries its tags: to find templates by tag, keep the results whose tags include it (list_tags lists the tags in use). 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).

Input Schema

NameRequiredDescriptionDefault
idNoFilter by Template ID (64-bit format). Cannot be a Version ID.
limitNoMaximum number of results to return, between 1 and 100 (Carbone API limit). Default: 100. Use cursor to page beyond that.
cursorNoPagination cursor from the previous response nextCursor field. Use to fetch the next page.
originNoFilter by upload origin: 0 = API, 1 = Carbone Studio, 2 = Salesforce integration, 3 = Odoo integration, 4 = HubSpot integration. Templates uploaded through this MCP server are origin 0.
searchNoFuzzy search in template names, or exact match on Template ID / Version ID.
categoryNoFilter by category (e.g. "invoices", "legal").
versionIdNoFilter by Version ID (SHA-256 format).
includeVersionsNoIf true, returns all versions for each template. Default: false (only deployed version).

Output Schema

NameRequiredDescriptionDefault
hasMoreYesWhether more results are available via the cursor.
templatesYesThe matching templates (all fields).
nextCursorNoCursor to pass to the next list_templates call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of results to return, between 1 and 100. Default: 100. Use cursor to page beyond that."New value: +"Maximum number of results to return, between 1 and 100 (Carbone API limit). Default: 100. Use cursor to page beyond that."
    • changedInput schema / properties / origin / description
      Previous value: -"Filter by upload origin. 0 = API, 1 = Carbone Studio, 2 = Salesforce, 3 = Odoo, 4 = HubSpot. Templates created through this MCP are origin 0."New value: +"Filter by upload origin: 0 = API, 1 = Carbone Studio, 2 = Salesforce integration, 3 = Odoo integration, 4 = HubSpot integration. Templates uploaded through this MCP server are origin 0."
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed2 schema fields changedv1.6.0
    • changedInput schema / properties / limit / description
      Previous 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."
    • changedInput schema / properties / origin / description
      Previous 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."
  3. Changed5 schema fields changedv1.2.2
    • changedInput schema / properties / limit / description
      Previous 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."
    • removedInput schema / properties / limit / exclusiveMinimum
      Removed value: -0
    • changedInput schema / properties / limit / maximum
      Previous value: -9007199254740991New value: +100
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedOutput 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"
+}
  4. First observedv1.1.2

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: cursor-based pagination and the id=null case for templates uploaded with versioning disabled. It stops short of describing result shape, but the output schema handles that.

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

Conciseness4/5

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

Front-loaded with purpose and filtering scope in the first sentence, then edge cases. Slight redundancy between the opening phrase "with filtering, search, and pagination" and the subsequent enumeration of filter fields, but every remaining sentence carries actionable content.

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?

For an 8-parameter, zero-required listing tool with full schema coverage, annotations, and an output schema, the description covers the one thing structured fields cannot: the id=null/versionId fallback and tag-based lookup workflow. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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, but the description adds real semantic value beyond the schema by explaining how id and versionId relate (null id, versionId as substitute) and how tags are actually consumed from results rather than filtered on.

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?

Opens with a specific verb+resource ("List stored Carbone templates") and enumerates the filtering dimensions, which cleanly separates it from siblings like list_tags, list_categories, and inspect_template. An agent can identify the tool's role without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use includeVersions for version history, use list_tags to discover tags (since tags are not a filter parameter here), and pass versionId to delete_template/download_template when id is null. It names concrete alternatives and the conditions that select them.

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

Deploy Server

Other Tools