Magnific Character Variants: Web UI Binding Traps and MCP Limits
Clicking a character card's select button in Magnific silently commits the default set and ignores variants. Here is how multi-look personas work.

Key takeaways
- Magnific character entities support multiple reference sets called variants under a single @mention, avoiding duplicated roster profiles.
- Clicking the card's -select-button skips the variant picker and silently binds the default reference set while reporting a false '[ok]' status.
- Automation scripts must click the card body (-media container) to expose the underlying variant selection grid.
- MCP integrations cannot read or manipulate variants; calling MCP library_edit destructively replaces reference libraries down to 6 images.
- Variants should isolate specific styling alterations—such as 7 bob portraits—rather than diluting conditioning with redundant full-body plates.
Managing multi-look synthetic personas under unified entities
Operating a commercial synthetic talent agency requires styling models across diverse wardrobe eras, distinct makeup palettes, and radically altered haircuts. Early studio workflows addressed restyling by creating separate character profiles for each aesthetic variation. If a certified talent needed a short bob for an avant-garde editorial, engineers registered a secondary character profile in the library. This practice rapidly degraded infrastructure maintenance, fragmenting facial provenance across multiple identifiers and doubling compliance bookkeeping across legal registries.
Magnific provides native architectural support for multi-look personas through character variants. A character entity is not limited to a single rigid collection of images; it holds multiple discrete reference sets under one unified `@mention`. By consolidating stylistic iterations under a parent persona, studio production teams preserve identity provenance while maintaining clean asset catalogs across high-throughput commercial pipelines.
Never register a secondary character entity for a restyle; attach a named variant to the existing persona. In our production database, certified talent Miranda Calder carries library ID 2192659. Her primary identity anchors to her Original set, featuring long natural hair. When campaign specifications demanded a Cleopatra-inspired blunt bob, the studio attached variant ID 2192976 labeled 'cleopatra' directly to her master profile. Both looks resolve through the single mention `@miranda-calder`, centralizing IP whitelisting.
The silent default binding trap of the web interface
Automating generation pipelines through web browser runners revealed a dangerous UI trap that silently ships incorrect character styling. In our production brief schema, engineers request specific persona looks using explicit variant syntax: `character:@name#variant`. For example, directing a Parisian rooftop shoot declared `character:@miranda-calder#cleopatra`. During initial automated runs on 2026-08-21, the Playwright runner reported clean execution logs, displaying `[ok] character ref attached`.
Inspecting the rendered imagery revealed that the talent materialized with her long natural hair rather than the requested blunt bob. The failure stemmed from a subtle interaction pattern in Magnific's asset picker. Clicking the explicit `-select-button` mounted on the character thumbnail card immediately commits the talent's default reference set. It completely bypasses the variant menu, binding the Original look without throwing an exception or logging a warning.
To safely expose character variants, browser automation must never click the `-select-button`. Instead, scripts must click the main card body, targeting the `-media` container or the bare thumbnail surface. Clicking the card body transitions the modal into the variant selection grid, signaled by the appearance of `library-characters-picker-variants-back`. Only from this nested grid can automation click the specific variant thumbnail.
Programmatic variant selection and failure detection
Reliable headless operation demands that automation fail loud rather than proceeding with incorrect visual assets. When a production brief includes a `#variant` flag, our runner verifies that the variant picker successfully mounts. If the secondary grid fails to open, the runner raises an immediate exception rather than defaulting to the baseline persona.
| Character Entity | Variant Name | Target Identifier | UI Interaction Target | Observed Binding Behavior |
|---|---|---|---|---|
| Miranda Calder | Default (Original) | ID 2192659 | Card `-select-button` | Binds long hair Original set correctly |
| Miranda Calder | Cleopatra Bob | ID 2192976 | Card `-select-button` | Silent failure: binds Original; logs `[ok]` |
| Miranda Calder | Cleopatra Bob | ID 2192976 | Card body (`-media`) | Opens grid; binds 7-frame bob variant |
| Aiko Velora | Certified Flagship | ID 1990481 | Unified Profile | 18 frames with integrated dentition |
| Livia Serrano | Commercial Roster | ID 1991506 | Web UI Upload | 21 frames; destroyed if edited via MCP |
Within the variant grid, reference sets are addressed strictly by natural language name rather than numeric identifiers. The Original reference set matches the character's primary name (`miranda-calder`), marked by a dedicated original pill. Additional looks use their assigned string labels, such as `cleopatra`. Because variants lack independent thumbnail cards in the primary asset modal, attempting to bind them via raw library IDs causes immediate selector failure.
Reference destruction risks within MCP library endpoints
While the web interface provides sophisticated variant controls, attempting to manage reference sets through the official Model Context Protocol (MCP) introduces severe data destruction hazards. The MCP server implementation operates on an outdated schema that cannot perceive character variants. In tools like `library_edit` and `images_generate`, the protocol expects a flat character identifier with no parameter space to declare variant subsets.
Worse, the MCP `library_list` tool provides actively misleading telemetry. It exposes a `variantCount` field that consistently reports 1, even when a character entity demonstrably contains multiple verified variants on disk. Relying on MCP metadata to audit variant inventories will falsely indicate that secondary reference sets do not exist across your roster.
The most dangerous hazard lies within `library_edit.images`. The endpoint documentation specifies that input images replace the existing reference collection, capped between 1 to 6 files. In modern production, certified roster characters carry extensive reference sets: our 2026-09-22 audit confirmed that Livia Serrano carries 21 reference frames. Executing an MCP edit against her profile would permanently wipe her 21 curated frames down to a maximum of 6. All reference library modifications must remain strictly confined to the web interface.
Curating specialized reference frames without visual dilution
Designing an effective character variant requires precise curation. A common instinct among production teams is to populate a new variant with an exhaustive collection of full-body standing frames, seated poses, and wardrobe tests. This approach dilutes the primary conditioning objective.
A variant should contain exclusively the frames that teach the specific deviation from the baseline model. For Miranda Calder's Cleopatra restyle, the variant contains exactly 7 tightly framed portraits capturing the blunt hemline across multiple angles: front, left and right three-quarters, side profiles, rear neckline, and a subtle smile. It contains zero full-body photographs.
Full-body proportions, skeletal ratios, and baseline posture are already established by the 9 certified frames within her Original set. Including full-body images in a hairstyle variant forces the model to negotiate conflicting wardrobe and background cues. If a shot requires full-body framing, the production brief should bind the Original persona; when the shot focuses on the dramatic bob, the brief routes to `character:@miranda-calder#cleopatra`.



