Skip to main content
Glama

openFlow

by io.github.molkex
OverviewDiscussionsAdmin

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: farm 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

A3.8/5.0
Behavior4/5

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

Annotations are minimal (readOnlyHint=false implies mutation; destructiveHint=false), and the description goes well beyond them by candidly disclosing that multi-view reliability on the new image_inputs path is 'unverified-but-plausible', that the mechanism changed 2026-07-26, and that the old finding stands. This is honest, context-rich disclosure rather than repeating the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The actual purpose is front-loaded in the first sentence, but the description then unfolds into a long historical narrative (2026-07-11 finding, 2026-07-26 change, worker.py's BROWSER_JOB_TYPES, thread-by-thread disclaimers about what was and wasn't re-verified). This institutional memory is valuable for trust but is padded with redundant caveats that could be condensed to a sentence or two.

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 tools with no output schema and a complex mechanism history, the description covers reliability status, recommended prerequisites, and parameter semantics for 3 of 4 parameters. It is fairly complete, minus the unexplained outfit_description parameter, which is the one material omission for an agent trying to call it correctly.

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

Parameters2/5

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

Schema description coverage is 0%, so the description carries the full burden for all 4 parameters. It explains account (farm account owning the entity's project) and character_slot_index (which slot, default 1), and references entity_id implicitly via 'this entity_id's project'. However, outfit_description is entirely absent from the description — a parameter with a non-trivial default that an agent would not know how to set meaningfully. With 0% coverage, this gap is significant.

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 opening sentence states a specific verb (generate), resource (character turnaround), and output format (FULL BODY from 3 angles in one row, labeled). It also explicitly names the sibling it is not — 'a separate path from plain image generation' — so an agent can distinguish it from generate_character_image without opening schemas.

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 gives clear usage context: recommend saving a detailed physical description first via create_character_from_photo's physical_description param or update_character's personality_notes, and it distinguishes this path from plain generation. It lacks an explicit 'when NOT to use' statement, but the alternative tool names and conditions are supplied.

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

All openFlow toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources