Skip to main content
Glama

List aicut characters

list_characters
Read-onlyIdempotent

Returns the characters saved on this aicut account, newest first, one page at a time: kind: "uploaded" entries the user made from their own photos and kind: "cast_member" entries generated as AI Video Story cast. Each carries an id, a display name, a portrait image_url where one exists and, for cast members, the visual world. Read-only: it creates nothing and spends nothing. WHEN: the user wants to reuse a character ('same cast as last time') or you want to show what the account has. world DOES NOT IDENTIFY THE SERIES and nothing on these rows does (a world is shared by many series), so 'the same cast as last time' cannot be answered from this list alone, and that is a MONEY point: never pick members for a story create by matching world to the series. Name the candidates to the user and let them confirm, or draft a fresh cast with generate_cast (free): a wrong pick is only discovered after the frames are drawn and charged. WHAT EACH KIND CAN DO: cast_member ids are what generate_story_video takes as cast_member_ids; a cast member's portrait image_url is usually one of this account's own images and can go into generate_* media fields (members on a series' stock preset carry a shared url those fields refuse). uploaded ids are what generate_video takes as character_ids (a flat 0.2 tokens on top of the video); their portrait urls are NOT accepted by media fields (a saved character is not an upload_media upload): pass the id. Paging: cursor from the previous next_cursor while has_more is true.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many to return, 1 to 100. Defaults to 50.
cursorNoThe previous response's `next_cursor`. Omit for the first page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, it discloses that this creates nothing and spends nothing, describes the returned fields, explains paging through `cursor`/`has_more`, and maps each kind's ids and image URLs to downstream tools. It also surfaces the important behavioral risk that `world` does not identify the series and cannot answer 'same cast as last time' 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?

The description is front-loaded with the return shape and then moves into usage, warnings, id semantics, and paging. It is longer than a typical list-tool description and contains some repetition around `world` not identifying series, but most sentences carry useful cross-tool or cost-risk information.

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?

There is no output schema, so the description carries the burden of describing return values, and it does so thoroughly: kinds, fields, ids, image URL behavior, and paging. Combined with the annotations covering safety, it gives an agent enough context to call and interpret the tool 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?

The input schema already has 100% description coverage for both parameters, including the default for `limit` and the meaning of `cursor`. The description reinforces paging by saying to use `cursor` from the previous `next_cursor` while `has_more` is true, but it adds little parameter-level meaning beyond the schema.

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 states a specific verb and resource: it returns characters saved on the account, newest first, in two explicitly named kinds (`uploaded` and `cast_member`). It also describes the distinguishing fields and the difference between the two kinds, so an agent can tell what this tool returns versus other list tools.

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 an explicit WHEN section: the user wants to reuse a character or see what the account has. It also names `generate_cast` as the alternative for drafting a fresh cast and explains why matching by `world` to a series is unreliable, including the cost consequence of a wrong pick.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Directories

Listed in ChatGPT · aicut

Last observed