Skip to main content
Glama

generate_character_turnaround

Generate a single image showing the character's FULL BODY from 3 angles (front/side/back) in one row, labeled — a "turnaround sheet". Pure HTTP as of 2026-07-26 — no browser involved (see below for what changed and what that does and does NOT prove).

History, so the mechanism change doesn't erase the reason this tool exists:
confirmed live 2026-07-11 that the plain Android-bearer generate_character_image
path produces an INCONSISTENT result for this exact kind of multi-view prompt,
even with a detailed physical description already saved on the entity — a real
web composer (Chrome/CDP) driving Flow's own translation/agent layer was reliably
consistent for the same prompt. That is why this tool exists as a separate path
from plain image generation, and that finding still stands.

What changed 2026-07-26: this no longer drives that browser composer. The
underlying job type (generate_character_scene) moved to a THIRD mechanism, not
either of the two compared above — plain HTTP with image_inputs=[the character's
own portrait_media_id from the registry], the same face-preserving mechanism
generate_with_face uses. This was done to remove the last browser dependency
(worker.py's BROWSER_JOB_TYPES is now empty), not because this new path's
multi-view consistency was re-verified — it has NOT been checked live yet whether
image_inputs alone holds up as well as the old composer did for a 3-angle sheet.
Treat multi-view reliability here as unverified-but-plausible until confirmed by
eye against real output, not as re-proven.

Still recommend a detailed physical description saved first (create_character_from_photo's
physical_description param, or update_character's personality_notes) — that
recommendation carries over from the 2026-07-11 finding above; whether it still
matters mechanically on this new image_inputs path (vs. the composer's own
entityContext-driven translation layer, which this path does not use) has not been
separately tested, so keeping it costs nothing and there's no evidence yet that
it's safe to drop.

account: Google account that owns this entity_id's project.
character_slot_index: which slot to write the result into (0 = portrait, 1 =
body — default 1).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountYes
entity_idYes
outfit_descriptionNoобычная повседневная одежда
character_slot_indexNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond annotations, the description discloses the exact mechanism (pure HTTP, image_inputs using the character's portrait_media_id), that it uses a third mechanism rather than either compared path, that it has not been re-verified live, and what the recommendation does and does not prove. This is unusually candid about limitations.

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 long, but the length is earned: the history, mechanism change, and reliability caveat are essential for correct use. It is organized into clear sections and front-loads the core purpose before the detailed backstory, though it could be trimmed without losing meaning.

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?

The description covers purpose, mechanism, reliability status, prerequisites, slot behavior, and account ownership. It does not describe the output format or how to retrieve the image, and it leaves some parameter definitions to inference, so it is not fully complete, but it is strong given the tool's complexity.

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?

With 0% schema description coverage, the description helps by defining account and character_slot_index with explicit semantics and defaults. However, it does not explain entity_id beyond 'entity_id's project' and completely omits outfit_description, leaving two parameters under-specified.

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 states a specific verb and resource: 'Generate a single image showing the character's FULL BODY from 3 angles (front/side/back) in one row, labeled — a turnaround sheet.' It also explicitly distinguishes this path from plain generate_character_image, making the tool's unique role clear.

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 explains when this tool exists: plain Android-bearer generation was inconsistent for multi-view prompts, while a browser-composer path was consistent. It also gives a prerequisite recommendation (save a detailed physical description first) and warns that the new mechanism's multi-view reliability is unverified, which is critical usage context.

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.