Skip to main content
Glama

text

Create a live, editable text layer or restyle one, chosen with op (create, set_content, set_font, set_color, set_alignment, set_box), with an optional fixed box that wraps the text and a fit option. create adds a layer at x / y with text, font_size in points and optional font_name, red / green / blue and alignment; it reports layer_id, name, bounds, the photo's ppi and the font size in pixels. The set_* ops change the text layer named by layer_id or layer (a non-text layer is refused). Fonts accept a family ("Inter") or a full name ("Inter Bold"), case-insensitive; a miss is refused with the closest installed names (list them with inspect what=fonts). Text is capped at 2000 characters, and a layer that would render past the size limit is refused and leaves the photo unchanged. Alignment is LEFT, CENTER, RIGHT or FULLYJUSTIFIED only. box {width, height?} (create, set_box) fixes the text box so text wraps at width; fit shrinks the size to approximately the largest size at which the wrapped text fits a box with both sides; the result then carries box and, for fit, fitted and fit_probes. Text sits at the top of the box (there is no vertical alignment). There is no undo in this session: checkpoint first when in doubt.

Input Schema

NameRequiredDescriptionDefault
xNocreate only: the layer's left edge in document pixels.
yNocreate only: the layer's top edge in document pixels.
opYescreate: a new text layer at the top of the stack with `text` at `x`/`y` (default 100,100) and `font_size` (default 24), optionally with font_name, red/green/blue and alignment. set_content: replace the text with `text`. set_font: set `font_name`, `font_size`, or both (omit font_name to resize in the current font). set_color: set red/green/blue. set_alignment: set `alignment`. set_box: put the layer in a fixed `box` (re-wrapping its text). The set_* ops act on the text layer named by `layer_id` or `layer`.
boxNocreate, set_box: a fixed text box {width, height?} in image pixels (each side 1 to 30000, area within the text-box cap: 64 MP at 8-bit, 32 MP at 16-bit, 16 MP at 32-bit). The text wraps at `width` (newlines in the text are kept) and is placed at the top of the box; there is no vertical alignment, so a taller box leaves the space below. Omit `height` and the layer grows to the wrapped text's height. The box survives later set_content / set_font / set_alignment edits. Emoji and some scripts depend on installed fonts and may render as empty boxes.
fitNocreate, set_box: with a `box` that has both width and height (at most 16 MP), shrink the text to approximately the largest size (at most font_size, or the current size for set_box) at which the wrapped text fits inside the box, searched in at most 12 trial renders. A word wider than the box counts as not fitting. The result reports `fitted`: false when even min_size overflows (the text is left at min_size).
redNoText colour red, 0-255. red, green and blue go together.
blueNoText colour blue, 0-255.
textNocreate: initial text. set_content: the new text, replacing the existing text. At most 2000 characters. For a line break, put a newline character in the string (not a backslash followed by n).
greenNoText colour green, 0-255.
imageYesImage id, as returned by open_photo.
layerNoset_*: name of the text layer to change. Ignored when layer_id is given. Not used by create.
layer_idNoset_*: id of the text layer to change (create reports it; inspect flags text layers with is_text_layer). Takes priority over `layer`. Not used by create.
min_sizeNofit only: the smallest font size to try, in pixels (default 8).
alignmentNoText alignment: LEFT, CENTER, RIGHT or FULLYJUSTIFIED (the justified-with-last-line variants are refused). In a box, alignment applies within the box width.
font_nameNoFont family ("Inter", "Open Sans") or full name ("Inter Bold"), case-insensitive. create: omit for a default sans. A name that matches nothing is refused with the closest installed names; inspect what=fonts lists them all.
font_sizeNoFont size in points, 1 to 1296, converted to pixels with the image resolution. create: initial size (default 24). set_font: new size (omit to keep the current size).

Output Schema

NameRequiredDescriptionDefault
boxNocreate / set_box with a box: the resulting box in pixels.
ppiNoThe image's resolution.
fontNo
nameNo
textNoCapped at 200 characters for reporting.
colorNo
boundsNo
fittedNofit only: false when even min_size overflows the box.
layer_idNo
alignmentNo
font_sizeNoPoints.
fit_probesNofit only: trial renders used (at most 12).
has_markupNo
fit_secondsNofit only: time the search took.
text_lengthNo
font_size_pxNoThe font size in pixels at the image resolution (the height of a line).
text_truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / op / description
      Previous value: -"create: a new text layer at the top of the stack with `text` at `x`/`y` (default 100,100) and `font_size` (default 24), optionally with font_name, red/green/blue and alignment. set_content: replace the text with `text`. set_font: set `font_name` (optionally `font_size`). set_color: set red/green/blue. set_alignment: set `alignment`. set_box: put the layer in a fixed `box` (re-wrapping its text). The set_* ops act on the text layer named by `layer_id` or `layer`."New value: +"create: a new text layer at the top of the stack with `text` at `x`/`y` (default 100,100) and `font_size` (default 24), optionally with font_name, red/green/blue and alignment. set_content: replace the text with `text`. set_font: set `font_name`, `font_size`, or both (omit font_name to resize in the current font). set_color: set red/green/blue. set_alignment: set `alignment`. set_box: put the layer in a fixed `box` (re-wrapping its text). The set_* ops act on the text layer named by `layer_id` or `layer`."
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say readOnly=false, destructive=false, idempotent=false, so the description carries real weight and delivers: 2000-character cap, size-limit refusal that "leaves the photo unchanged", refusal of non-text layers, font-miss refusal with closest installed names, alignment variants refused, and no undo. That is exactly the operational context an agent needs before mutating a document.

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 the verb and op list, and every clause carries information. It is dense to the point of being a single sprawling paragraph with heavy parentheticals, and some material (fit probes, box caps) duplicates the schema, but there is no filler.

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?

With 16 parameters, nested `box`, an output schema, and a set of destructive-ish live edits, this is a complex tool and the description covers modes, limits, refusals, wrapping/fit behavior and recovery advice. Since the return fields are declared in the output schema, it correctly does not spend words enumerating them.

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% and the schema's `op`, `box`, `fit`, `font_name` and `layer_id` descriptions already contain most of this detail, including the fit probe count and box area caps. The prose adds only a little genuine semantics beyond the schema (e.g. "a non-text layer is refused"), so the baseline 3 is right.

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 names a specific verb and resource ("create a live, editable text layer or restyle one") and immediately enumerates the `op` modes, which is enough to separate it from siblings like add_adjustment, recolor or transform_layer. An agent knows it is the text-layer 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 explains which op to pick and when create vs set_* applies ("the set_* ops change the text layer named by layer_id or layer"), plus a concrete safeguard ("There is no undo in this session: checkpoint first when in doubt"). It does not explicitly route to alternatives when the goal is, say, adding shapes or effects, but the usage context for the tool itself is clear.

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.

Resources