Skip to main content
Glama

list_3d_stories

The 3D Animated film maker. ONE call shows the whole story library of 233 public-domain stories (fairy tales, fables, classic adventures, Bible Old and New Testament, myths and legends, Anunnaki and Sumerian myths, classic drama, nursery rhymes, bedtime tales) for every age group at once; there is no per-type or per-age filter, so never call it more than once in a reply or once per request, whatever the user asks to see. Call it when the user wants a 3D animated film, cartoon or kids' movie and has not named a story, or asks what stories there are. Reads only, costs nothing. In apps that show panels (Claude, ChatGPT) the panel is the whole 3D maker, like the website: every story with a type switch and search, then the story's characters to make and approve, then look, length, narrator, captions and music, then a review step with the Make button. Say one sentence and wait: do not list the titles yourself, and do not call suggest_3d_cast, create_3d_character or create_3d_film unless the user asks you to in words. A repeat call within half a minute returns one line, not another panel. In apps without panels, list the stories in text and go step by step in the chat. Pass the chosen story's id to create_3d_film. The user can also tell their own story instead (see create_3d_film own_* fields).

Input Schema

NameRequiredDescriptionDefault
limitNoText apps only: how many to list. Default 12.
searchNoOnly when the user names a story: words to look for in titles, blurbs and cast, e.g. 'Noah', 'Cinderella'. Leave out to show the whole library (the panel has its own search and type switch).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / properties / group
      Removed value: -{
      -  "description": "Only one group, e.g. 'Fairy tales', 'Bible – Old Testament', 'Nursery rhymes', 'Myths & legends', 'Classic drama'.",
      -  "type": "string"
      -}
    • changedInput schema / properties / limit / description
      Previous value: -"How many to return. Default 12."New value: +"Text apps only: how many to list. Default 12."
    • removedInput schema / properties / preset
      Removed value: -{
      -  "description": "Only stories made for this look: nursery (ages 0-5), kids (6-12), epic (Epic & faith: Bible, myths, legends, all ages), drama (cinematic drama, teens and adults).",
      -  "enum": [
      -    "nursery",
      -    "kids",
      -    "epic",
      -    "drama"
      -  ],
      -  "type": "string"
      -}
    • changedInput schema / properties / search / description
      Previous value: -"Words to look for in titles, blurbs and cast, e.g. 'Noah', 'wolf', 'Cinderella'."New value: +"Only when the user names a story: words to look for in titles, blurbs and cast, e.g. 'Noah', 'Cinderella'. Leave out to show the whole library (the panel has its own search and type switch)."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it declares read-only behavior and zero cost, absence of per-type/per-age filters, a repeat-call throttle ('within half a minute returns one line'), and how behavior differs between panel apps (Claude, ChatGPT) and text-only apps. It even prescribes the interaction pattern ('say one sentence and wait') which materially affects correct invocation.

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

Conciseness3/5

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

Purpose and the single-call constraint are front-loaded, but the description sprawls into a long procedural script describing the panel's internal step sequence, which is not needed to decide whether or how to call this listing tool. Several clauses about downstream steps could be trimmed without losing selection value.

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 and no annotations, so the description must explain the return surface, and it does: a full panel in panel apps, a text listing with a default count in text apps, and a one-line response on repeat calls. It also tells the agent what to do with the result ('pass the chosen story's id to create_3d_film'), leaving no material gap for correct invocation.

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; the description adds meaning beyond it by scoping 'search' to cases where the user names a story and framing the unfiltered default as the whole library, plus noting limit applies to text apps only. It does not add format or syntax detail beyond the schema, so it stops short of a 5.

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?

Opens with a specific verb and resource ('ONE call shows the whole story library of 233 public-domain stories') and enumerates the content types covered. It clearly separates this from siblings like list_3d_characters, list_3d_shots and create_3d_film, so an agent can pick it without opening other schemas.

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?

Explicitly states when to call it (user wants a 3D animated film/cartoon/kids' movie without a named story, or asks what stories exist) and when not to call it again ('never call it more than once in a reply'). It also names the alternatives to avoid (suggest_3d_cast, create_3d_character, create_3d_film) and the condition under which they are allowed.

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.

Resources