Skip to main content
Glama
hermoso-ai

Hermoso

Official

List saved creators

list_creators
Read-only

Retrieve your workspace’s saved on-camera cast, including portrait URLs, consent status, pose plates, and voices. Reuse an existing creator before generating a new one to keep the same face across ads and avoid extra costs.

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)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.161

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, FREE.' It goes further by disclosing the exact shape of each returned entry, the cost/continuity implications of recasting, and the honest-empty-result behavior. No annotation contradiction exists.

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

Conciseness5/5

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

Though long, the description is densely packed with actionable information and every sentence earns its place. The core 'what' is front-loaded, followed by reuse handles and workflow guidance. Nothing is redundant or filler.

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 read-only listing tool with no output schema, the description fully compensates: it enumerates return fields, explains empty-result semantics, warns against inventing data, and maps the returned portrait/creator info to downstream tool parameters. An agent can use this tool correctly with no missing context.

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% for the single parameter, and the schema already documents 'limit' with its default. The description adds no parameter-specific meaning, but given complete schema coverage, it does not need to. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'List this workspace’s SAVED CREATORS — the reusable on-camera cast.' It clearly distinguishes saved creators from other creator-related tools like find_creators by defining what counts as a creator here and what the call returns.

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 explicitly tells the agent when to call this tool ('CALL THIS BEFORE OFFERING TO GENERATE A NEW PERSON'), what to do on an empty result (offer generate_avatar / save_creator, never invent a roster), and how to feed results into render_ad, generate_avatar, generate_video, recast_motion, and generate_image. This is model usage guidance.

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