Skip to main content
Glama

Morpha

set_layer_text

Edit an existing text layer (text.). Patches its text content, font, size, colour, and full type styling — pass only the fields you want to change. Does NOT create layers and does NOT touch image layers; use add_text_layer to make a new one. font_family is a Google Fonts family name (e.g. "Anton", "Bebas Neue"). text_size is the font size in px (omit to keep the current size). text_color is #rrggbb. Styling: font_weight (100-900, e.g. 800 for a black/heavy logo look), font_style (italic), text_transform (uppercase/lowercase), letter_spacing (px, may be negative for tight tracking), line_height (multiplier), text_align, text_autofit ("wrap" default = fixed size + word-wrap, the size you set is what renders; "fit"=auto-size to fill the box, grows and shrinks; "shrink"=legacy shrink-only), text_valign (top/middle/bottom block alignment), an outline via stroke_width + stroke_color, and a text_shadow. To make text MASK another layer (video/image-filled letterforms) use set_matte_source with this layer's id as the matte source. Only elementId is required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoThe text to render. Newlines are honoured as hard line breaks.
curveNoCurve the text onto an arc, in degrees of total sweep. 0 = straight (default). POSITIVE = a SMILE (⌣, ends rise); NEGATIVE = an ARCH (⌒, rainbow). Clamped ±135. A tasteful smile is ~+60. Applies to a SINGLE line — multi-line text is joined to one line while curved (the stored text is untouched, so curve:0 restores it).
elementIdYesText layer id, text.<id>.
projectIdYesOpaque project id (a v4 UUID, from list_projects/create_project). Selects which existing project this call mutates.
text_sizeNoFont size in px.
font_styleNoItalic toggle. Default normal.
text_alignNoHorizontal alignment of each line. Default center.
text_colorNoText fill colour as #rrggbb.
decorationsNoPer-character underline / strikethrough. { underline?: [{start,end}], strikethrough?: [{start,end}] } — each a list of half-open character ranges [start,end) (UTF-16 offsets) into `text`. E.g. underline the first word of "Big news": underline:[{start:0,end:3}]. Ranges are normalized (sorted + merged). null clears all decorations; editing `text` in the SAME call re-indexes existing ranges against the new text. Not rendered on curved text.
font_familyNoGoogle Fonts family name, e.g. "Anton".
font_weightNoFont weight 100..900 (400 regular, 700 bold, 800 black). Default 400; the canvas synthesizes weights a static font doesn't ship.
line_heightNoLine height as a multiple of font size (1.2 = 120%).
text_shadowNoDrop shadow { offsetX, offsetY, blur, color }; color is any CSS colour (rgba allowed). null clears it.
text_valignNoVertical alignment of the text block within its box. "middle" (default) centres it; "bottom" pins it to the box floor so extra wrapped lines grow upward from a fixed baseline (captions use this so a wrapped line doesn't shift the others); "top" pins the ceiling.
stroke_colorNoOutline colour as #rrggbb. Defaults to white when a width is set.
stroke_widthNoOutline width in px (0 = no outline).
text_autofitNoHow text fits its box. "hug" (default for new layers): hold text_size FIXED and DERIVE the box from the measured text plus padding, honouring the literal newlines you pass — the box shrink-wraps the exact content and grows/shrinks live as the text changes, so it can never re-wrap differently between the editor preview and the export (bake your own "\n" breaks; pair with set_text_background for a rounded caption box). "wrap": hold text_size FIXED in a fixed-size box and only word-wrap (hard-breaking a single over-wide word), never resize. "fit": ignore text_size and auto-size the font BOTH ways (grow and shrink) to the largest size whose wrapped block fills the box — resizing the box resizes the text. "shrink" (legacy): word-wrap then auto-shrink the font from text_size until the block fits; never grows.
letter_spacingNoTracking between glyphs in px; may be negative. Default 0.
text_transformNoCase transform applied before layout. Default none.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and provides deep behavioral detail: autofit grow/shrink semantics, curve single-line joining, decoration re-indexing on text edits, null-clearing behavior, and preview/export consistency for 'hug'. However, the claim 'Only elementId is required' contradicts the input schema, which also requires projectId, so the description is not fully reliable.

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 appropriately so for a 19-parameter styling tool; it front-loads the main action before exclusions, parameter conventions, and advanced use cases. Every sentence adds concrete detail or examples rather than filler.

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?

The prose is remarkably complete for behaviors and parameter semantics, but it is not fully safe to invoke from: the final sentence says only elementId is required while the schema requires projectId. An agent that trusts the description over the schema could send a failing request; no output/return info is provided, though that is less critical.

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 coverage is 100%, so a baseline of 3 applies, but the description adds significant meaning: Google Fonts family examples, smile/arch direction for curve, autofit mode differences, caption-friendly valign behavior, negative letter-spacing, and decoration range offsets. The required-fields contradiction ('only elementId') prevents a 5 because it misstates the projectId requirement.

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 first sentence names a specific verb and resource: 'Edit an existing text layer (text.<id>)' and lists the patched properties (text content, font, size, colour, type styling). It also explicitly distinguishes from add_text_layer and image layers, so an agent can identify this 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 Guidelines5/5

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

The description gives explicit when-to-use and when-not-to-use guidance: patch only fields you want to change, do not create layers, do not touch image layers, and use add_text_layer for creation. It also points to set_matte_source for masking, which covers the main alternative use case.

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.

TDQS

A3.6/5.0
Disambiguation3/5

The tool set has several clusters that overlap conceptually: add_keyframe/add_keyframes/set_keyframes_batch, move_band/move_layer/shift_group/set_group_window, and fade_layer/set_layer_transition/set_layer_visible all target similar actions. However, each tool's description is distinct and detailed enough for an agent to disambiguate after careful reading. The sheer volume of 95 tools still creates meaningful selection risk.

Naming Consistency4/5

Tool names overwhelmingly follow a verb_noun snake_case pattern (add_, remove_, set_, list_, rename_, create_, delete_), which is predictable and readable. Minor inconsistencies exist: plural variants like add_keyframes vs add_keyframe, mixed specificity like remove_keyframe vs remove_color_keyframe, and a few oddballs like reid_project and clip_processing_status. Overall the pattern is strong and helps navigation.

Tool Count2/5

95 tools is far beyond the well-scoped range and will overwhelm agents; even a comprehensive video editor could consolidate keyframe batch operations, overlay/track manipulations, and page/group window controls. Many tools are highly specific (reid_project, safe_zones, move_band) and place burden on the agent to pick among near-synonym verbs. While the broad domain justifies many operations, this count is excessive for a coherent tool surface.

Completeness3/5

The surface covers a broad editing lifecycle: layers, keyframes, text, captions, audio, pages, groups, versions, projects, workspaces, and collections, including batch operations. However, there is no MCP tool to render/export the final MP4 (explicitly delegated to an SDK) and no upload_video tool for bringing in a clip file, leaving major end-to-end gaps. For the stated purpose of building and editing videos, these are significant omissions that force agents to stop short of delivery.

Resources