Skip to main content
Glama

List the AI Video Story series

list_series
Read-onlyIdempotent

Lists aicut's AI Video Story series (niches): episodic short-video formats that generate a whole multi-scene episode from one idea. BROWSING IS browse_series' JOB: when the USER is choosing a series ('what series do you have'), call browse_series FIRST (a series is chosen BY EYE). THIS TOOL IS THE DATA READ behind that choice (prices, the duration ladder) and the fallback with no cards. Never paste preview_url / preview_video_url into the chat, dump the catalogue, or call this once per series. TWO CALLS. WITHOUT series_id: the COMPACT CATALOG, a shortlist in the picker's order: id, name, tagline, preview_url + preview_video_url, rank, badge, frames_first, cast (required / writer_owned), defaults.video_model and episode_tokens (a rough min-max token range at the default length, frames and scene videos only, so an understatement). cast, defaults and episode_tokens are NULL when the series cannot be fully described: say nothing about its cost and fetch the full entry. With no card, present 3-5 that fit (name, pitch, episode_tokens) and the count of the rest. WITH series_id: that ONE series IN FULL, REQUIRED before you quote or create anything (never quote money off the compact list). PASS video_model (the series' defaults.video_model unless the user named one): a full entry carries about ninety ladder rungs across every model. PRICING (only on the series_id call): pricing.video_models[].durations is the length PICKER, each option a real length in seconds with scene_count, frames_tokens (at create), videos_tokens (at fire) and total_tokens; durations.default_seconds is the default. Also pricing.start_frame_models, pricing.frame_regen_tokens (one redraw) and pricing.render_tokens_per_minute (the final render: the only quote before the scene videos are done; give it as a rate or a rough figure with a tilde, never as the price). Any block can be NULL: a null is not a zero and not a guess, so use estimate_only; if durations is null the series cannot be sized from here (point at the web app). QUOTE A RUNG HONESTLY, TWO FLAGS THAT ARE NOT THE SAME QUESTION: videos_estimated (tilde videos_tokens) and frames_estimated (tilde frames_tokens); tilde the total whenever EITHER is true, even when exact is true. exact is true on every shipped rung; if one is not, quote estimate_only. scene_count_estimated true means scene_count is what the rung derives, not what the episode will contain. Never state a scene count as fact: it is only what a rung derives and the writer decides; do not volunteer it. duration and scene_count are INFORMATIONAL (no argument matches them): the sizing question is LENGTH in seconds. Use the series' defaults unless the user names a model; when defaults is null omit the model arguments. The flow: get_recipe story-episode.

Input Schema

NameRequiredDescriptionDefault
series_idNoA series id from the compact catalog: returns that ONE series with every field a quote or create needs. Omit for the compact catalog.
video_modelNoThe model you intend to create on (the series' `defaults.video_model` unless the user named one): only its duration ladder comes back. Omit only to compare models. Needs `series_id`; a model the series does not publish is refused with the ones it does.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine operational context beyond that — two-call shape, null-not-zero semantics, quoting rules, response-size warning for `video_model`, and presentation prohibitions (never paste `preview_url`, never dump the catalogue) — which is meaningful but pitched at the calling agent's output discipline rather than the tool's own behavior.

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?

It is front-loaded with identity and the browse rule, and the two-mode structure is legible. But it is very long and heavily shouted in caps, with some restatement (the no-dump/no-paste instructions recur) that crowds out faster scanning.

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 carries the return shape and does so thoroughly: it enumerates the compact-catalog fields, the full-entry pricing blocks, the estimation flags and their interaction, and the null-handling path. An agent has everything needed to call and interpret the result.

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 coverage is 100% and both parameters already document their shape and default-vs-omit behavior. The description reinforces the selection rule (use `defaults.video_model` unless the user named a model) and states the refusal case, but does not add much that the schema text lacks.

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?

States a specific verb+resource ("Lists aicut's AI Video Story series (niches)") and defines what a series is, then explicitly separates the browsing job (`browse_series`) from this data-read job. An agent can place it among the ~60 siblings without opening the schema.

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?

Explicit when/when-not: call `browse_series` FIRST when the user is choosing by eye, this tool is the data read behind that choice and the fallback with no cards. It also prescribes call discipline ("TWO CALLS", never once per series) and the lookup-vs-list decision driven by `series_id`.

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