Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

List saved creators

list_creators
Read-onlyIdempotent

Retrieve this workspace's saved AI creators and their portraits, consent status, poses, and voices. Reuse an existing cast member before generating a new person to keep the same face across ads.

Instructions

List this workspace’s SAVED CREATORS — the reusable on-camera cast (AI creators made here, a person pulled from a social profile, a consented photo upload). Read-only, FREE. Each entry gives the name, the PORTRAIT URL, where the portrait came from and whether a real person’s likeness consent is on file, how many extra pose plates exist, and any chosen or cloned voice. TO PUT ONE IN A FINISHED AD, pass their id or name as render_ad’s creator — that casts them for the whole spot (and skips the character-portrait render, so it costs less than not casting anyone). THE PORTRAIT URL IS THE REUSE HANDLE for the raw lanes — pass it as generate_avatar’s image (a talking clip of them), generate_video’s refImage (they star in the scene), recast_motion’s image (they perform a reference clip’s motion), or generate_image’s refImages. CALL THIS BEFORE OFFERING TO GENERATE A NEW PERSON: re-casting somebody the workspace already has keeps the SAME face across every ad, while a fresh person costs credits and breaks that continuity. An empty answer means the workspace genuinely has no cast yet — say so and offer generate_avatar / save_creator, never invent a roster.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNomax creators to return (default 24)
genderNofilter the PRESET creators by gender (the saved cast is never filtered)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.366
    • addedInput schema / properties / gender
      Added value: +{
+  "description": "filter the PRESET creators by gender (the saved cast is never filtered)",
+  "enum": [
+    "female",
+    "male"
+  ],
+  "type": "string"
+}
  2. Addedv0.1.161

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds substantial context beyond them: the list is FREE, each entry includes consent status, pose plate count, and voice metadata, and the portrait URL is a reuse handle for multiple generation tools. It also explains that casting a saved creator skips the portrait render and costs less. This is rich behavioral context for a list tool.

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 front-loaded with purpose, then usage, then downstream integrations, and every major section adds value. It is longer than typical and uses emphatic all-caps formatting, but for a tool with many cross-tool handoffs and no output schema, the length is mostly earned. Slight reduction for density and caps-heavy style.

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?

Given the absence of an output schema, the description explains what each returned entry contains: name, portrait URL, portrait source, likeness consent, extra pose plates, and voice. It also covers empty-result behavior and the main downstream use cases. Combined with annotations that already cover safety, this is complete for an agent to call and act on the result correctly.

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?

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description does not add parameter-level syntax or filtering semantics beyond what the schema provides. Baseline 3 is appropriate when the schema fully carries parameter meaning.

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 specific verb and resource: 'List this workspace’s SAVED CREATORS — the reusable on-camera cast.' It clearly distinguishes saved creators from preset/findable people and explains the exact resource type (AI creators, social profiles, consented uploads). An agent can tell this is not the same as save_creator, update_saved_creator, delete_creator, or find_creators.

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?

It gives explicit when-to-use guidance: call this before offering to generate a new person to preserve face continuity and avoid credits. It also names downstream alternatives and exact parameter handoffs: render_ad's `creator`, generate_avatar's `image`, generate_video's `refImage`, recast_motion's `image`, and generate_image's `refImages`. It even specifies what to do on an empty result.

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