Skip to main content
Glama

Make a person in a picture talk

lip_sync

Make a person say a line, their mouth on the sound's words. mode still: a new video of the person in a picture (an image asset, or one frame of a video with atSeconds), in that picture's place and light, talking with natural head moves. mode dub: the person's own footage (a video asset, startSeconds to endSeconds) keeps everything as it was filmed and only the mouth changes, to dub new words or another language over what they said. The sound is a sound or video asset, or a part of one. With generate_speech's voiceAssetId, the person says new words in their own voice: pick a clean stretch of them speaking with read_transcript, make the line with generate_speech, then lip_sync them with it; edit_video can then change the new clip's world. The new video has the line's sound in it: place it as a video clip and do not place the sound again. A still is as long as the sound, at least 5 seconds, up to 60: a shorter sound is padded with silence to 5 seconds, where the person stays quiet, and the answer says where the words end, so the clip can be trimmed there. A dub is as long as the line: footage shorter than the line plays forward and back to cover it, so pick footage about as long as the line. It answers at once with a Job ID and the media is made in the background: start every generation you need, keep working, then call wait_for_jobs with all their Job IDs to get each Asset ID for patch_film. Uses credits for each second of the video: a still about 30 credits a second at standard and about 61 credits a second at high, 1.2 times that over 15 seconds, so a 5-second line uses 152 credits at standard; a dub about 51 credits a second of the longer of the footage and the line, so 5 seconds use 253 credits. Tell the person the cost before you start it.

Input Schema

NameRequiredDescriptionDefault
modeYesstill: the person in a picture, an image or one frame of a video (atSeconds), comes to life saying the line. dub: a stretch of a video (startSeconds to endSeconds) keeps its real moves, face and framing, and only the mouth changes to say the line.
assetIdYesstill: an image asset, or a video asset with atSeconds for one of its frames: one face, turned to the camera, clear and not covered, in a picture from 2:5 (tall) to 5:2 (wide). dub: the video asset whose person says the line, with their face in view. Use the IDs search_assets gives.
qualityYesstill: standard (null) for most videos, made at 768p; high makes it at 1080p and uses twice the credits, only when the person asks for the sharpest picture. null with dub, which keeps the footage's own size.
atSecondsYesstill with a video asset: the source second of the frame to animate, one where the face is clear and the mouth closed or still, which you checked with preview_frame or read_asset; null for an image, or for a video's first frame. null with dub.
projectIdYesThe project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.
endSecondsYesdub: source second of assetId where the footage to dub ends. null with still.
audioAssetIdYesWhat they say: a sound asset, usually the speech generate_speech made (with voiceAssetId for the person's own voice), or a video or sound asset with speech.
startSecondsYesdub: source second of assetId where the footage to dub starts, with endSeconds: the part a clip plays, about as long as the line. null for both dubs the whole video, which is then 1 to 60 seconds long. null with still.
audioEndSecondsYesSource second of audioAssetId where the line ends.
audioStartSecondsYesSource second of audioAssetId where the line starts, with audioEndSeconds; null for both uses the whole asset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false, idempotentHint=false) by disclosing async behavior (returns a Job ID immediately, media is generated in the background), the 5-second silence padding and 60-second ceiling for stills, the ping-pong looping for short dub footage, that the returned sound is already baked into the clip and must not be placed again, and detailed per-second credit costs. These are exactly the traits annotations cannot convey.

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 purpose and mode split, then workflow, then cost — a sensible ordering with no filler sentences. It is long and duplicates some schema content (the mode and assetId definitions are essentially repeated verbatim), which costs it a point on a tool whose schema is already fully documented.

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 no output schema, the description still covers the return contract (immediate Job ID, later Asset ID via wait_for_jobs for patch_film) and even notes the answer reports where the words end so the silence-padded clip can be trimmed. Combined with cost, duration bounds and mode prerequisites, an agent has everything needed to call and chain it correctly.

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 the baseline is 3; the description adds cross-parameter semantics the schema cannot express, such as still duration tracking the sound with 5s minimum/60s maximum, dub length being governed by the longer of footage and line, and guidance to pick footage about as long as the line. It does restate much of the mode/assetId schema text, keeping it from a 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 a concrete verb+resource ('make a person say a line, their mouth on the sound's words') and immediately splits it into two well-defined modes, still vs dub. It names the sibling tools it composes with (generate_speech, read_transcript, edit_video, patch_film, wait_for_jobs), so an agent can distinguish it from generate_video or replace_person without opening any 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?

Explicitly says when to use each mode (still = animate a picture; dub = keep real footage, change only the mouth, e.g. another language) and prescribes the end-to-end alternative path when using a cloned voice. It also adds a hard procedural rule ('tell the person the cost before you start it') and post-call workflow (start jobs, keep working, wait_for_jobs).

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.