Skip to main content
Glama

Put text behind the subject

add_text_behind

PROJECT-SCOPED: this call acts only on the explicit project_id and returns the project identity with its result. Put words BEHIND the moving subject — the person walks IN FRONT of the letters, the way a title painted on the street or the wall behind them would. This is the 'text behind me walking' / 'name behind the subject' move, and it is a REAL depth composite, not a fade: a person-matting model that carries temporal state between frames cuts the subject out of every frame — dark clothes on a dark wall, handheld wobble and a moving camera are all fine, and the mask holds steady instead of flickering — and the renderer lays them back over the words. PEOPLE occlude the words (with whatever they carry); static objects — furniture, walls — do NOT: over those the words read as an ordinary title, which is what keeps the occlusion steady. Say so if the user asks about an object. Same styling arguments as add_text (template/x/y/size_scale/color/font/entrance/exit); at_output_s + duration_s are where in the EDITED video the words appear. REQUIREMENTS I check and refuse on, so read the reply: a PERSON must be visible in the window (nothing to go behind otherwise — I say so and you offer add_text instead). Follow crops, cuts and speed ramps in the window are fine: the program matte keeps the words behind the speaker, and a stretch it cannot measure renders as a face-safe slam that the reply names. I also report how much of the text the subject actually crosses — if that is near zero the user will see a plain title, so move the text or the window. BIG TYPE IS THE LOOK: the subject should cross the MIDDLE of tall glyphs with their tops and bottoms staying readable — that is what reads as depth. A small line sits entirely inside the body and whole words vanish, so titles default to size_scale 2.4 here; NEVER shrink the text to 'fix' hidden letters — enlarge it or shorten the phrase. Do NOT put a zoom or a stabilize pass over the window. Remove it with remove_text like any other text.

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
boxNo
exitNo
fontNo
textYes
colorNo
entranceNo
templateNo
uppercaseNo
duration_sNo
project_idYesRequired immutable scope for this call. Copy the id from list_projects/open_project/project_state; the active-project pointer is never used to guess.
size_scaleNo
at_output_sYes
accent_colorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With only generic write annotations (readOnlyHint=false, destructiveHint=false), the description carries the burden and delivers: project scoping, the temporal matting behavior, refusal conditions, occlusion semantics for people vs static objects, defaults (size_scale 2.4), the zoom/stabilize prohibition, and cleanup path. This is far 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?

Long but front-loaded with the project scope and the core composite concept, and most sentences carry distinct rules (refusals, occlusion, defaults). It leans narrative in the middle, which costs a little density, but little is pure padding.

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 a complex creative tool with no output schema and near-zero schema descriptions, the definition covers requirements, failure modes, defaults, alternatives, and removal. An agent has everything needed to call it correctly or decline.

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 only 7% across 15 params, so the description must compensate, and it does for most: it maps styling args (template/x/y/size_scale/color/font/entrance/exit), defines at_output_s/duration_s as positions in the EDITED video, and states the size_scale default. It leaves box, uppercase, and accent_color unexplained.

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?

Names the exact operation ('put words BEHIND the moving subject') and contrasts it with the plain title behavior of add_text when no person is present. It is unambiguously distinguishable from siblings like add_text and add_kinetic_text.

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?

Gives explicit when-to-use (a person must be visible in the window), when-it-refuses ('a PERSON must be visible... I say so and you offer add_text instead'), and prerequisites (follow crops/cuts/speed ramps are fine). It also routes to the sibling add_text and to remove_text for cleanup.

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.