Skip to main content
Glama

create_omni_character

NEW — Create a reusable visual character for Gemini Omni video generation. Combines image + optional voice. Returns characterId.

Instructions

NEW — Create a reusable visual character for Gemini Omni video generation. Combines image + optional voice. Returns characterId.

Input Schema

NameRequiredDescriptionDefault
audio_idsNoOptional voice IDs from create_omni_voice
image_urlsYesExactly 1 image URL (≤20MB)
max_creditsNoRefuse to submit if the estimated cost exceeds this many credits (overrides KIE_MAX_CREDITS_PER_CALL). Estimates come from published rates; kie bills the actual amount.
descriptionsYesCharacter appearance, identity, style, clothing, personality
estimate_onlyNoReturn the estimated credit cost WITHOUT submitting anything. Use before expensive runs (video, 4K, 1080p upgrades, layer splits).
character_nameNoCharacter name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv5.8.0
    • addedInput schema / properties / estimate_only
      Added value: +{
      +  "description": "Return the estimated credit cost WITHOUT submitting anything. Use before expensive runs (video, 4K, 1080p upgrades, layer splits).",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / max_credits
      Added value: +{
      +  "description": "Refuse to submit if the estimated cost exceeds this many credits (overrides KIE_MAX_CREDITS_PER_CALL). Estimates come from published rates; kie bills the actual amount.",
      +  "type": "number"
      +}
  2. First observedv4.7.0

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries full behavioral burden but discloses little beyond 'returns characterId'. It does not explain credit implications, whether the character persists/is reusable across calls, idempotency, or any auth/rate constraints, even though the schema hints at billing behavior via max_credits and estimate_only.

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?

Three short, front-loaded sentences with no waste; the key action and return value lead. The 'NEW —' prefix is marketing rather than functional, but costs nothing.

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

Completeness3/5

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

No output schema exists, but the description does name the return value ('characterId'), which is the essential output. For a creation tool with zero annotations, it should say more about persistence, cost, and failure behavior, so it is only minimally complete.

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 coverage is 100%, so the schema already documents every parameter thoroughly. The description adds only high-level mapping ('image + optional voice') to image_urls/audio_ids. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific verb and resource ('Create a reusable visual character for Gemini Omni video generation') and clarifies it 'combines image + optional voice', which helps distinguish it from create_omni_voice. It never names a sibling explicitly, but the scope is clear enough for an agent to select it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by 'for Gemini Omni video generation'. There is no explicit when-to-use/when-not-to-use guidance, no mention of prerequisites (e.g. needing an existing voice ID from create_omni_voice), and no routing to alternatives.

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