Skip to main content
Glama

openFlow

by io.github.molkex
OverviewDiscussionsAdmin

create_character_from_photo

Create a new Flow character whose portrait (and optionally body) is a REAL PHOTO, not a text description or generation. Both photos become the character's slot-0 (portrait) and slot-1 (body) images directly — Flow's own upload mechanism in its New Character composer, discovered live 2026-07-11 — no image generation call happens for either slot, so resemblance is exact, not "similar style". Boots the on-demand Chrome for this account (~15-30s, longer if body_photo_base64 is also given), same as create_character, no Android/recaptcha involved.

photo_base64: raw base64-encoded image bytes, no data: URI prefix — portrait.
body_photo_base64: same format, optional — ideally a full-body photo of the same
person, for a guaranteed-exact body image (no generation at all for that slot).

physical_description: IMPORTANT, look at the photo yourself and write this —
a detailed physical description (build, hair color/style, eye color, clothing,
distinguishing features), similar in spirit to: "Adult male, mid-20s, ~180cm,
lean build. Medium-brown wavy hair, light blue-grey eyes, faint stubble. Wears
a dark grey hoodie, dark jeans, white sneakers." This gets saved into the same
"Character Info" field as Flow's own UI. CORRECTED same day as this tool was
first built: an earlier version of this doc claimed body/multi-view generation
can never stay consistent with a photo-seeded portrait — WRONG, confirmed live.
The actual missing ingredient was this detailed text spec — with it, both
generate_character_turnaround and generate_character_expression_sheet below
produce genuinely consistent, on-model results (reproduced live against Flow's
real UI, not just guessed). Skip this only for a bare portrait-only character
with no further generation planned.

Next step after you have entity_id: update_character for a display name, then
generate_character_turnaround / generate_character_expression_sheet if you want
those (skip if you already passed body_photo_base64 for an exact body photo —
generating over it would replace the real photo with a generated approximation).

Fidelity note added 2026-07-11 (later same day): "genuinely consistent" above means
consistent WITH ITSELF across panels (same invented-looking person in every view),
not necessarily an exact match to the real person's face — real-world feedback was
"I don't recognize myself." Good for stylized/invented character sheets; if the goal
is content that's recognizably the actual person, use generate_video_with_reference
(r2v) instead, which conditions on the real photo's pixels rather than a description.

name: optional, added 2026-07-25 — give the character a short human-readable name
and it's saved to YOUR list (list_characters()), keyed on the uploaded photo as the
identity reference (portrait_media_id). Once named, use
generate_with_face(character=name, prompt=...) for further images instead of
tracking portrait_media_id yourself. Must be unique among your own characters; a
clash does NOT fail the call — the character is still created in Flow, just
reported back with a `registration_error` instead of a `name` in the result, so
pick a different name and register it yourself later if that happens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
accountYes
photo_base64Yes
body_photo_base64No
physical_descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description goes far beyond the basic annotations: it discloses the ~15-30s Chrome boot cost, that no image generation occurs, that no Android/recaptcha is involved, that name clashes do not fail the call but produce a registration_error, and the fidelity limitation that 'genuinely consistent' means internally consistent rather than an exact match to the real person. This is rich, accurate behavioral context that complements the annotations without contradicting them.

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

Conciseness3/5

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

The description is front-loaded with the core behavior and has useful per-parameter structure, but it is overwrought. It includes dated editorial notes and corrections ('CORRECTED same day as this tool was first built', 'Fidelity note added 2026-07-11'), which add historical context but could be condensed without loss of operational meaning.

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

Completeness5/5

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

For a 5-parameter tool with no output schema, the description is exceptionally complete. It covers the full workflow after the call (update_character, generate_character_turnaround, generate_character_expression_sheet), the failure mode for duplicate names, the latency expectation, the exact-photo versus consistent-with-itself distinction, and when to route to generate_video_with_reference instead. An agent has everything needed to call this correctly and interpret the result.

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?

With 0% schema description coverage, the description carries the full burden, and it largely succeeds: it explains that photo_base64 is raw base64 without a data: URI prefix, describes body_photo_base64 as optional and ideally full-body, gives a detailed example for physical_description, and explains the uniqueness and registration behavior of name. Only the required account parameter is not explained, and even that gap is minor.

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: 'Create a new Flow character whose portrait (and optionally body) is a REAL PHOTO.' It immediately distinguishes itself from text-description or generation-based creation, which differentiates it clearly from siblings like create_character and create_character_from_description.

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 when-to-use guidance and alternatives. It tells the agent to use generate_video_with_reference when a recognizably real person is the goal, and to use generate_character_turnaround or generate_character_expression_sheet when further generated panels are wanted, while noting when to skip them if a real body photo was provided.

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