Skip to main content
Glama

Generate Avatar Reference

generate_avatar
Destructive

Generate reusable avatar/model references through the same creator path as the Uwear app. The default view is upper_body_front, a clean bust identity anchor. For a draft multi-view avatar, generate the bust first, pass its result URL in identity_reference_urls when generating each slot view, then save the chosen results together with save_generated_avatar. Traits are optional user-given facts and are never guessed. If the user wants help writing the person description, call build_avatar_prompt first only for that purpose; if the user's wording is already intentional, pass it directly here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional name to carry with the avatar generation
viewNoReference view to generate. Defaults to the upper-body identity anchor.upper_body_front
buildNoOptional concrete physical build. Never inferred.
modelNoOptional image model slug or display name. Defaults to the cheapest active image generation model available to the account.
promptYesDescription of the person to render as a reusable avatar reference
age_rangeNoOptional concrete age or age range. Never inferred.
avatar_idNoOptional existing avatar whose anchor fixes identity for a slot view. Not required when identity_reference_urls are supplied.
height_cmNoOptional height in centimeters. Never inferred.
expressionNoExact expression instruction for a supported reference view. Replaces the configured neutral expression default.
num_imagesNoNumber of avatar candidate images to generate
identity_reference_urlsNoPerson-image URLs that fix identity for a slot view. In a draft flow, pass the generated bust URL here before the avatar has been saved.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / expression
      Added value: +{
      +  "default": null,
      +  "description": "Exact expression instruction for a supported reference view. Replaces the configured neutral expression default.",
      +  "maxLength": 500,
      +  "type": "string"
      +}
  2. Changed8 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / age_range / description
      Previous value: -"Optional concrete age or age range for the avatar footer."New value: +"Optional concrete age or age range. Never inferred."
    • addedInput schema / properties / avatar_id
      Added value: +{
      +  "default": null,
      +  "description": "Optional existing avatar whose anchor fixes identity for a slot view. Not required when identity_reference_urls are supplied.",
      +  "exclusiveMinimum": 0,
      +  "type": "integer"
      +}
    • changedInput schema / properties / build / description
      Previous value: -"Optional authoritative physical build for the avatar footer. When omitted, the canonical creator derives it from the resolved persona. Placeholder values and inference instructions are rejected."New value: +"Optional concrete physical build. Never inferred."
    • addedInput schema / properties / height_cm
      Added value: +{
      +  "default": null,
      +  "description": "Optional height in centimeters. Never inferred.",
      +  "maximum": 220,
      +  "minimum": 40,
      +  "type": "integer"
      +}
    • addedInput schema / properties / identity_reference_urls
      Added value: +{
      +  "default": null,
      +  "description": "Person-image URLs that fix identity for a slot view. In a draft flow, pass the generated bust URL here before the avatar has been saved.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "maxItems": 5,
      +  "type": "array"
      +}
    • changedInput schema / properties / prompt / description
      Previous value: -"Description of the person to render as a reusable avatar design sheet"New value: +"Description of the person to render as a reusable avatar reference"
    • addedInput schema / properties / view
      Added value: +{
      +  "default": "upper_body_front",
      +  "description": "Reference view to generate. Defaults to the upper-body identity anchor.",
      +  "enum": [
      +    "upper_body_front",
      +    "full_body_front",
      +    "full_body_side",
      +    "full_body_back",
      +    "detail_eyes",
      +    "detail_skin"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations include destructiveHint=true and readOnlyHint=false, which the description does not contradict. The description adds behavioral context beyond annotations: traits are never guessed, and the multi-view generation workflow is explained. It doesn't discuss side effects or non-idempotency, but annotations cover that partially. Overall it adds useful context.

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?

The description is well-structured with the core purpose front-loaded, followed by workflow and guidance. It is slightly long but every sentence serves a purpose, and it avoids redundancy with the schema.

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 tool with 11 parameters and many sibling tools, the description covers the essential workflow, the default view, and when to route to other tools. It doesn't explain output format (no output schema) or some self-explanatory params, but given the complexity, it is sufficiently complete.

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 baseline is 3. The description adds meaning to identity_reference_urls by explaining the draft flow and how to use the bust URL. It also clarifies that build, age_range, and height_cm are user-given and never inferred. This enriches the schema definitions.

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 reusable avatar/model references and distinguishes it from siblings like build_avatar_prompt (for description writing) and save_generated_avatar (for saving). It specifies the default view and the intended use case.

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?

The description gives explicit workflow guidance: generate the bust first, pass its URL as identity_reference_urls for slot views, then save with save_generated_avatar. It also names when to use build_avatar_prompt instead and when to pass the prompt directly. This is clear and actionable.

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