Skip to main content
Glama

txtreel

Render a txtreel video

chat_render_video

Render a txtreel conversation (script or messages) to an MP4 and wait for it to finish. This queues a render, waits for it, and returns once it is done (or after failing/timing out). A short render (a handful of messages) typically takes 20-60 seconds.

Returns a public link to the MP4; the file is deleted after 24 hours. If txtreel is busy or you hit the rate limit, the result is an error with the message.

Tip: call chat_validate first to catch script errors before paying for a render.

Conversation script format (one event per line):

them: hey, you up? me: yeah why [pause 1.5] wait 1.5 s --- Today 9:41 PM date/time separator me: [photo URL] caption a photo (URL, local file path, or an uploaded photo's number) [them reacts ❤️] reaction on my last message [read] they read my messages === everything above is already on screen at the start === scroll 3 same, but open on the oldest message and skim down in 3 s

comment

"Name: text" also means "them" when Name matches contact.name (e.g. contact.name "Sam" lets you write "Sam: omg" instead of "them: omg"). A literal "\n" inside a message becomes a line break. Lines starting with # are comments.

Guidance: one short message per line, like real texting — split up what a real person would send as separate texts rather than one long paragraph. A typical reel is 8-16 messages and 15-30 seconds. Use "[pause N]" to hold a beat before a reply lands (dramatic timing). Use "===" to start the video with everything above it already on screen, e.g. for a "catch up on this conversation" reel. Photos: "me: [photo https://example.com/image.jpg] optional caption" (https URLs only; local file paths are not available). Use "=== scroll 3" instead to open on the oldest message of a longer history and skim down to the live part in 3 s — too fast to read, so viewers pause and rewind (good for comments: hide a detail in the history). Leave keyboard at its default (true) so the newest messages stay above where the Reels caption/UI usually sits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
speedNoPacing multiplier; 2 = twice as fast, 0.5 = half speed. Default: 1.
themeNoColor theme, "light" or "dark". Default: light.
scriptNoConversation as a plain-text script. Use this OR messages, not both. Conversation script format (one event per line): them: hey, you up? me: yeah why [pause 1.5] wait 1.5 s --- Today 9:41 PM date/time separator me: [photo URL] caption a photo (URL, local file path, or an uploaded photo's number) [them reacts ❤️] reaction on my last message [read] they read my messages === everything above is already on screen at the start === scroll 3 same, but open on the oldest message and skim down in 3 s # comment "Name: text" also means "them" when Name matches contact.name (e.g. contact.name "Sam" lets you write "Sam: omg" instead of "them: omg"). A literal "\n" inside a message becomes a line break. Lines starting with # are comments. Guidance: one short message per line, like real texting — split up what a real person would send as separate texts rather than one long paragraph. A typical reel is 8-16 messages and 15-30 seconds. Use "[pause N]" to hold a beat before a reply lands (dramatic timing). Use "===" to start the video with everything above it already on screen, e.g. for a "catch up on this conversation" reel. Photos: "me: [photo https://example.com/image.jpg] optional caption" (https URLs only; local file paths are not available). Use "=== scroll 3" instead to open on the oldest message of a longer history and skim down to the live part in 3 s — too fast to read, so viewers pause and rewind (good for comments: hide a detail in the history). Leave keyboard at its default (true) so the newest messages stay above where the Reels caption/UI usually sits.
soundsNoReal UI sounds: iOS key clicks while typing, the app's send and receive sounds. Default: true.
contactNoContact header info.
endHoldNoSeconds to hold on the final frame before the video ends. Default: 2.
autoReadNoMark "me" messages as read as soon as the other person starts typing. Default: true.
keyboardNoShow the iOS keyboard, which keeps the latest messages above the Reels caption area. Default: true.
messagesNoConversation as an array of event objects instead of a script string (use this OR script, not both). Passed through to the txtreel API as-is; each item is one of: {from:"me"|"them", text, delay?, typing?, hold?, time?, instant?} (type "message" is the default and can be omitted), {type:"pause", seconds}, {type:"timestamp", text, instant?}, {type:"read", time?}, {type:"react", from:"me"|"them", emoji}.
platformNoChat app to render: "imessage", "whatsapp", or "instagram". Default: imessage.
startTimeNoClock used for messages, read receipts, and WhatsApp bubble times, e.g. "9:41 PM". Default: 9:41 PM.
statusBarNoPhone status bar shown at the top of the frame.
composerTypingNoType "me" messages into the input bar before sending them. Default: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Goes well past the annotations: states the call blocks until the render completes (20-60s typical), returns a public MP4 link, the file is deleted after 24 hours, and busy/rate-limit conditions surface as an error message. Those latency, lifecycle, and failure traits are exactly the behavior an agent needs and are not in readOnlyHint/openWorldHint/idempotentHint. No conflict with 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loading is good: purpose, blocking behavior, return value, and the validate tip come first. But the large conversation-script format section duplicates the script parameter's schema description almost word-for-word, inflating the text without adding new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter, nested-object tool with no output schema, the description covers the essentials an agent needs: synchronous wait, the returned public link and its 24-hour expiry, and error behavior. Remaining parameter detail is fully carried by the schema, so the omission there is acceptable.

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%, so all 13 parameters (including nested contact/statusBar) are already documented, making 3 the baseline. The description's script-format block is essentially a verbatim copy of the script property's schema description, so it adds no meaning beyond what the schema already carries.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource: render a txtreel conversation (script or messages) to an MP4, and clarifies it is synchronous (queues, waits, returns when done). The video-vs-message framing is clear. However, it never distinguishes this from the sibling chat_screenshot, so an agent choosing between image and video output gets no explicit routing help from the text.

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?

Gives strong in-context guidance: call chat_validate first to catch script errors before paying for a render, plus practical advice on message length, reel duration, [pause] timing, and === usage. It stops short of explicit when-not-to-use or contrast with chat_screenshot / reddit_render_video, so it is clear context without exclusions.

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