Skip to main content
Glama
templated-io

Templated MCP Server

Official
by templated-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_template

Build reusable design templates programmatically with text, image, shape, and rating layers, including multi-page or multi-size layouts for image, video, and PDF renders.

Instructions

Create a new template programmatically with layers. IMPORTANT: Each layer must have a 'layer' field (unique identifier/name), not 'name'. Valid layer types are: 'text', 'image', 'shape', 'rating'. Use 'shape' for rectangles, circles, and other shapes - shapes require an 'html' field with SVG content. For a multi-page or multi-size template (several sizes in one template), pass 'pages' instead of 'layers': each page carries its own width/height and its layers as an object keyed by layer name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesTemplate name
pagesNoPages for multi-page or multi-size templates (e.g. Instagram square, story and X landscape in ONE template, each with its own width/height). Use this INSTEAD of top-level 'layers'. Each page: 'page' (unique name), optional 'width'/'height' (fall back to the template size), and 'layers' as an OBJECT keyed by layer name (NOT an array). Same shape as get_template_pages returns.
widthYesTemplate width in pixels
heightYesTemplate height in pixels
layersNoArray of layer objects. Each layer MUST have 'layer' (unique name) and 'type' fields.
durationNoDefault video duration in milliseconds for MP4 renders (e.g., 5000 for 5 seconds). Used as fallback when no duration is specified at render time.
backgroundNoTemplate background color (e.g., '#ffffff', 'rgb(255,255,255)', 'transparent')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.7.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the write/no-destroy safety profile is covered. The description adds pitfall warnings about field naming and layer typing, but says nothing about side effects (e.g. whether renders are triggered), permissions, quotas, or what the call returns, so it adds only moderate 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.

Conciseness4/5

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

Purpose is front-loaded in the first sentence and the remaining sentences are conditional caveats, each earning its place. It is somewhat dense in the back half but contains no filler or restatement of the tool name.

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

Completeness3/5

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

For a complex nested write tool with no output schema, the description covers input construction well but omits return values entirely — an agent cannot tell whether it gets back a template ID needed for follow-on renders. It also does not address the relationship between top-level width/height and per-page sizes beyond a brief note.

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 reinforces the most error-prone semantics ('layer' not 'name', valid types, shape requires 'html', pages vs layers), but these points largely restate what the schema already documents, so it adds little beyond the structured fields.

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 opening sentence states a specific verb and resource ('Create a new template programmatically with layers'), which cleanly separates it from siblings like clone_template, update_template, and get_template. It also scopes the operation to layer-bearing templates, so an agent knows exactly what this call produces.

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

Usage Guidelines3/5

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

The description gives conditional structural guidance ('For a multi-page or multi-size template, pass pages instead of layers'), which helps the agent shape the call. However, it never states when to choose this tool over clone_template or update_template, nor any prerequisites, so tool-selection guidance is only implied.

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