Skip to main content
Glama
hermoso-ai

Hermoso

Official

List saved creators

list_creators
Read-only

Retrieve saved AI creators with portrait URLs, consent status, poses, and voices to reuse the same on-camera cast across ads, ensuring face continuity and avoiding 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)
Behavior5/5

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

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds behavioral context: it's 'FREE', explains the return fields (name, portrait URL, consent status, pose plates, voice), and notes empty-result behavior. It also reveals cost implications of casting vs. not casting. The description fully overloads the annotation safety profile with practical details.

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?

The description is long but every sentence earns its place: it front-loads the purpose, then packs essential routing and cost information in a logical flow. There's no filler or redundancy; each clause serves a distinct decision an agent must make.

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?

With no output schema, the description compensates by detailing the exact fields returned. It also covers edge cases (empty roster), downstream usage across sibling tools, and cost/continuity rationales. For a simple list tool with one optional param, this is comprehensive beyond expectations.

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?

The only parameter (limit) is already fully documented in the schema with 100% coverage; the description adds nothing extra about it. Since the schema is self-sufficient, the baseline of 3 is appropriate—the description doesn't need to repeat what's structured.

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 explicitly states the action (list) and resource (saved creators in the workspace), and defines what a 'creator' is (AI creators, social pulls, consented photos). It clearly distinguishes itself from siblings by naming downstream tools (render_ad, generate_avatar, etc.) and the alternative save_creator. The scope and purpose are unambiguous.

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: 'CALL THIS BEFORE OFFERING TO GENERATE A NEW PERSON' and explains the trade-off (continuity vs. cost). It also names alternatives for the empty case (generate_avatar / save_creator) and instructs not to invent a roster. This is direct, actionable routing advice.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hermoso-ai/hermoso'

If you have feedback or need assistance with the MCP directory API, please join our Discord server