Skip to main content
Glama

Update template

updateTemplate
Destructive

Edit a template that already exists. Two kinds of field, and they behave differently. name, slug, description and status are metadata: they change in place and create no version. subject, html, blocks, props and slots are the BODY: the edit lands in the draft, and when the template has nothing left to edit (its head is published) a new draft numbered one higher is minted. Either way nothing a live send resolves moves until publishTemplate is called, which is what makes it safe to edit a template that is sending right now. Give one of html, document (the whole block design, every block kind and style, as getTemplateVersion returns it) or blocks (a flat list with no styling), never several. A field you leave out keeps what the head already had, so an edit to the subject alone keeps the body; props and slots, when sent, replace the whole list. Sending blocks replaces the block list and nothing else: the page settings the editor holds alongside it (preview text, web fonts, the Tailwind switch and the page style) are carried over from the version you are editing, so a template designed in the app does not lose its look to an edit made here. Read getTemplate first: the props it lists are what sends already pass, and dropping one makes those sends fail. Pass the head version and its Saved time from getTemplate as expectedVersion and expectedUpdatedAt, so an edit somebody saved since is refused rather than overwritten.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "updateTemplate"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
htmlNo
nameNo
slugNo
propsNo
slotsNo
blocksNo
statusNo
subjectNo
documentNoThe whole block design the editor uses: {"preview": "...", "style": {...}, "fonts": [...], "body": [blocks], "props": [...], "slots": [...]}. A block is {"kind", "id", "style", "align", ...}: Section, Container, Row and Column hold children (a Row holds only Columns); Heading, Text, Markdown, Button, Link, CodeBlock and CodeInline hold text; Button and Link take href; Img takes src, alt, width and height; Hr is a divider. style is camelCase CSS. getTemplateVersion and getTemplateStarter return complete documents to copy the shape from.
descriptionNo
expectedVersionNo
expectedUpdatedAtNoThe Saved time getTemplate gave for the head version, as an ISO 8601 instant. When the head was saved again after it, the call is refused with version_conflict.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / expectedUpdatedAt
      Added value: +{
      +  "description": "The Saved time getTemplate gave for the head version, as an ISO 8601 instant. When the head was saved again after it, the call is refused with version_conflict.",
      +  "format": "date-time",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Despite annotations already covering mutation and destructiveness, the description adds substantial behavior: metadata changes in place while body edits create or modify drafts, live sends are unaffected until publishTemplate, and concurrency is handled via expectedVersion and expectedUpdatedAt. It also explains replacement semantics for props, slots, and blocks.

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 long but proportionate to a 13-parameter mutation with versioning behavior. It is front-loaded with the core purpose and then organizes details around metadata versus body fields, draft creation, safe editing, and concurrency without obvious filler.

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?

For a complex mutation with no output schema and limited annotations, the description covers nearly all behavioral risks an agent needs: draft creation, live-send isolation, field exclusivity, replacement semantics, and conflict avoidance. The main omission is that it does not describe what the tool returns or whether the response includes the resulting version.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low at 15%, so the description carries most of the semantic burden and does so thoroughly. It explains the metadata fields, body fields, the exclusive choice among html, document, and blocks, the replacement behavior of props and slots, and the concurrency meaning of expectedVersion and expectedUpdatedAt.

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 opens with a specific verb and resource: "Edit a template that already exists." It further distinguishes metadata edits from body edits and names related operations like publishTemplate and getTemplate, so an agent can identify the tool 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 Guidelines4/5

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

It gives clear preconditions and sequencing: read getTemplate first, pass expectedVersion and expectedUpdatedAt, and call publishTemplate to move live sends. However, it does not explicitly distinguish this tool from nearby editing siblings such as editTemplateDesign or replaceTemplateContent.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.