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), they must not fill most of the frame (the words would never be visible), the window must be inside ONE take with no cut in it, and no speed ramp over that footage. 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

TableJSON 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 annotations (readOnlyHint=false, destructiveHint=false), the description carries the full burden. It discloses scope (project-scoped only), temporal-state matting behavior, refusal criteria listed as 'REQUIREMENTS I check and refuse on', reporting of overlap, and the recommendation not to zoom or stabilize. It adds substantive behavioral detail beyond annotations and contradicts none.

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?

The description is long but earns its length: it is organized, front-loaded with project scope, then semantics, then usage prohibitions, then style guidance. Some sentences are redundant for choosing a tool ('PUT WORDS BEHIND THE MOVING SUBJECT' repeated), but no unsourced marketing 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?

Given 15 parameters, no output schema, and minimal annotations, the description is nearly complete: it covers the depth semantics, parameter meaning, expected failure conditions, fallback behavior, and how to remove the effect. It goes beyond the minimum needed for correct invocation.

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?

Only 7% of parameters have schema descriptions, so the description must compensate. It does by identifying arg groups: 'Same styling arguments as add_text (template/x/y/size_scale/color/font/entrance/exit)' and explains at_output_s + duration_s and the special default for size_scale. However, at least four properties (box, uppercase, accent_color, gap between x/y) remain unaddressed, and it depends on the agent already knowing add_ with sibling's arguments, so not a full 5.

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?

States the exact operation with specific verb and resource: put text behind the subject, a real depth composite. It explicitly differentiates from add_text and explains when words read as an ordinary title, so an agent can tell this apart 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: requires a visible person, refuses if no person and tells agent to offer add_text instead. It also names sibling tools as alternatives for using add_text and remove_text, leaving no inference required.

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.