Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Save a creator

save_creator

Save a portrait to your workspace CAST so the same person can star in future ads. Add a name and public image URL to reuse them in avatars and videos.

Instructions

Add a portrait to this workspace’s reusable CAST so the SAME person can star in future ads — the headless twin of the app’s + > Pick a creator > save. Pass the portrait’s public url (a generate_image render of an AI person, or a photo of a real person you have permission to use, or of yourself; never a photo just because it is public) plus a name to call them by; from then on list_creators returns them and their url can be re-passed to generate_avatar / generate_video / recast_motion. Saving is FREE and renders nothing. LIKENESS: leave source "generated" for an AI-made person (free on every plan) and use "upload"/"social" for a REAL person. Using a real person’s face, likeness or voice confirms you are them or have their consent, take full, unlimited responsibility for its use and will cover any claim against Hermoso (hermoso.ai/terms). Paid plan only; recorded.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lookNotheir canonical wardrobe/appearance in words — reused to hold the look steady across ads
nameYeswhat to call this creator (e.g. “Sarah”) — list_creators and the app’s picker match on it
brandNoprofile id/name from list_brands, this call only
imageNoREQUIRED except with useAnyway. public https url of the portrait (an existing render’s url, or any public photo). Not a local file path — upload it with upload_file first and save the url that returns
posesNoup to 4 extra full-body / angle plates of the SAME person (public urls) — they make a wider shot hold the identity
voiceNoa default voice name for this persona (engines + voices are in hermoso_capabilities)
sourceNo"generated" (default) = an AI-made person; "upload" / "social" = a REAL person
useAnywayNoonly for a creator whose saved photo was flagged too unclear to cast (render_ad says so): true casts the current photo as it is, no new image needed

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.374
    • changedInput schema / properties / brand / description
      Previous value: -"brand id/name from list_brands, this call only"New value: +"profile id/name from list_brands, this call only"
  2. Changed1 schema field changedv0.1.371
    • addedInput schema / properties / brand
      Added value: +{
+  "description": "brand id/name from list_brands, this call only",
+  "type": "string"
+}
  3. Changed1 schema field changedv0.1.285
    • removedInput schema / properties / consented
      Removed value: -{
-  "description": "REAL people only: the user has confirmed that person consented to their likeness being used in ads",
-  "type": "boolean"
-}
  4. Changed3 schema fields changedv0.1.272
    • changedInput schema / properties / image / description
      Previous value: -"public https url of the portrait (an existing render’s url, or any public photo). Not a local file path — upload it with upload_file first and save the url that returns"New value: +"REQUIRED except with useAnyway. public https url of the portrait (an existing render’s url, or any public photo). Not a local file path — upload it with upload_file first and save the url that returns"
    • addedInput schema / properties / useAnyway
      Added value: +{
+  "description": "only for a creator whose saved photo was flagged too unclear to cast (render_ad says so): true casts the current photo as it is, no new image needed",
+  "type": "boolean"
+}
    • changedInput schema / required
      Previous value: -[
-  "name",
-  "image"
-]New value: +[
+  "name"
+]
  5. Addedv0.1.161

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, it discloses that saving is FREE and renders nothing, that it is paid-plan only, that the action is recorded, and it carries the likeness/consent legal terms and responsibility. That is substantial behavioral context an agent would not get from readOnlyHint/destructiveHint alone.

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?

It is front-loaded with purpose before the mechanics, and most clauses earn their place (cost, source semantics, consent). However it is delivered as one dense run-on paragraph with heavy em-dashes, which reduces scannability for an 8-parameter tool.

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 mutation tool with no output schema, it covers cost, plan gating, downstream consumption via list_creators, and the consent obligation, which is close to complete. It does not describe the failure/flag path in detail (only useAnyway references render_ad flagging), leaving a small gap.

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 the baseline is 3, but the description adds real meaning: the public-https-url constraint and 'not a local file path' rule for image, the source enum's real-vs-AI distinction tied to consent, and how name/look are reused. It stops short of clarifying every field (brand, voice, poses beyond a mention), so it is above baseline but not exhaustive.

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 names a concrete verb+resource ('Add a portrait to this workspace's reusable CAST') and states the scope precisely, including that it is the headless twin of a specific app action. It implicitly separates itself from list_creators (downstream read) and generate_avatar/generate_video/recast_motion (consumers of the saved url), so an agent can place it 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?

It gives a clear condition to use it (so the SAME person can star in future ads), an explicit when-not ('never a photo just because it is public'), and routes local files through upload_file first. It does not contrast with the sibling update_saved_creator or find_creators, so the alternative-selection guidance is strong but not exhaustive.

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

Deploy Server

Other Tools