Skip to main content
Glama

Recao

by app.recao

generate_clips

Idempotent

Render UGC video scenes as ad-ready clips, metered per second of video (the estimate shows the exact price before anything renders). Pass 3 to 6 scenes (5 to 8 seconds each, one action per scene, spoken lines at most 20 words; empty spoken_line for silent characters). Consecutive scenes pack into single TAKES of up to 15 seconds, one generation each. HOW CHARACTER IDENTITY WORKS, read carefully: all characters are described in TEXT (avatar_id resolves to its persona brief; or write the persona field yourself, covering one character or a whole ensemble). The video model rejects every image that contains a person, so no photo can anchor a face. Text keeps a character IDENTICAL only WITHIN a take; ACROSS takes it preserves the look and styling but the exact face can drift, and neither avatar_id nor persona prevents that. Structure your script so scenes where the same character must be recognizably identical sit adjacent and fit one take (15s or less); treat cross-take appearances as different shots of a matching character, and review the result. reference_image_urls (up to 9 https images) keeps real products or props on-model in every take; these images must contain no people. Without confirm, it validates the contract and returns the per-scene price estimate in EUR, and makes nothing. With confirm=true it starts the metered render and returns a job_id: rendering runs in the background over a few minutes, so poll clips_status with that id to get per-scene clip URLs plus the uncut takes. Paid plans only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoseedance-2.0 (default, highest quality) or seedance-2.0-fast (same generation, faster and cheaper).bytedance/seedance-2.0
aspectNoOutput aspect ratio9:16
scenesYes3 to 6 scenes in order. Adjacent scenes sharing a character land in the same take when their combined length allows it.
confirmNoSet true to start the metered render. Returns a job_id to poll with clips_status.
personaNoAlternative to avatar_id: describe the recurring character or the full ensemble (several characters) in words. Same limits: identity holds within a take, not across takes. Ignored when avatar_id is present.
avatar_idNoAvatar id from generate_avatar (starts with av_). Its persona brief describes the recurring character in text; identity holds within a take only, not across takes.
reference_image_urlsNoUp to 9 https image URLs of products or props to keep on-model in every take. No people in these images.

TDQS

A4.9/5.0
Behavior5/5

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

Disclosures go well beyond annotations: pre-render validation, metered pricing with estimate, background rendering, character identity drift across takes, video model rejecting images with people, and reference image constraints. No contradiction with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true).

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?

Information-dense with every sentence earning its place. However, the character identity section is quite long and could benefit from better structure (e.g., bullet points). Front-loaded with core purpose.

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 tool with 7 parameters (1 required) and no output schema, the description covers all relevant aspects: pre-render behavior, render initiation, background polling, character constraints, pricing, and usage prerequisites. It compensates for lack of output schema by describing return values (price estimate, job_id, clip URLs).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds critical meaning: explains how avatar_id and persona affect character identity, that confirm triggers render, that reference images must be people-free, and how scenes combine into takes. This is essential context not inferable from schema alone.

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 description starts with 'Render UGC video scenes as ad-ready clips', clearly stating the verb (render) and resource (UGC video scenes). It also distinguishes from siblings like clips_status (polling) and generate_avatar (avatar creation).

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?

Provides explicit guidelines: confirm=false for validation/estimate, confirm=true for actual render. Specifies scene count (3-6), duration (5-8s), spoken line limit (20 words), character identity behavior across takes, and that reference images must have no people. Also mentions alternatives avatar_id vs persona.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Recao toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose. The status checkers (assemble_status, clips_status) are differentiated by the job type they monitor. Memory tools (index, note, recall) are distinct operations. Competitor ad tools (search, get ads, get details) and video generation pipeline (avatar, clips, assembly) are well-separated.

Naming Consistency5/5

All tools use consistent snake_case with a verb_noun or noun_verb pattern (e.g., assemble_video, get_competitor_ads, memory_index). No mixing of conventions, making the tool names predictable and easy to understand.

Tool Count5/5

With 17 tools, the server covers account management, memory, competitor research, and video generation without being overwhelming. The count is well-scoped for its functionality, neither too sparse nor too heavy.

Completeness4/5

The toolset covers the core workflows: account setup (sign_up, upgrade, whoami), memory (CRUD), competitor analysis (search, get ads, details), and video ad creation (avatar, clips, assembly). Minor gaps like lacking a delete memory tool are acceptable given the domain focus.

Resources