Skip to main content
Glama

generate_avatar

Generate a UGC persona: your agent passes a persona brief (physical look plus vibe of one invented creator), and we return stills of that invented person plus an avatar_id. The persona brief anchors the same character in generate_clips takes, and the stills are the customer's reference artifact for the creative. Ask for up to 3; the default model returns a single strong base still, imagen and flux return the full set. Metered per generation; the price is shown in the response. Paid plans only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoHow many stills to request (2 to 3). The default model returns 1 regardless; imagen and flux honor this.
modelNoImage model. Default seedream-4.0 (lowest cost).bytedance/seedream-4.0
persona_briefYesPhysical description plus vibe of the invented UGC creator. One person (age, look, styling, setting, energy).

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already set openWorldHint=true and destructiveHint=false. The description adds behavioral context: metered generation, price in response, paid plans only, and model-dependent count behavior. No contradictions with 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?

Description is informative but slightly long; each sentence adds value. It is front-loaded with the main action. Minor redundancy with 'stills' mentioned twice could be condensed.

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?

Given 3 parameters with full schema coverage, no output schema, and annotations, the description covers key aspects: action, input, output, pricing, plan restriction, and model differences. It is complete enough for effective use without missing critical context.

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 meaning beyond schema: explains count is only honored by imagen/flux (not default), elaborates persona_brief content (age, look, styling, setting, energy), and notes model defaults to lowest cost. This significantly aids agent understanding.

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 clearly states the tool generates a UGC persona (avatar) based on a persona brief, returning stills and an avatar_id. It distinguishes from sibling generate_clips by noting the persona brief anchors the same character and stills are a reference artifact. The verb 'generate' and resource 'avatar' are specific.

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?

The description implies when to use (need UGC persona stills/avatar) and references generate_clips as related, but lacks explicit when-not-to-use or alternatives beyond that single sibling. The 'Paid plans only' restriction is clear.

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.

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.