list_series

Lists aicut's AI Video Story series (niches): episodic short-video formats with an authored identity - e.g. fruit dramas, transformation stories - that generate a whole multi-scene episode from one idea. BROWSING IS browse_series' JOB, NOT THIS TOOL'S - AND THAT IS THE FIRST THING TO GET RIGHT HERE. When the USER is looking at the catalogue or deciding which series to use ('what series do you have', 'show me the options', 'what can you make'), call browse_series FIRST and let the card answer: the catalogue is VISUAL, every tile carries that series' own preview still and its demo clip, and a series is chosen BY EYE - the taglines all sound plausible and the art does not. Answering such a question out of this tool's text is the wrong shape even when the text is correct. THIS TOOL IS THE DATA READ behind that choice - prices, the duration ladder, the fields a quote or a create has to be validated against - and the fallback where the client cannot render cards at all. Come here with series_id once a series is settled. TWO CALLS. WITHOUT series_id you get the COMPACT CATALOG - every series' id, kind, name, tagline, preview_url + preview_video_url (the series' own art - see PRESENTING), rank + badge (the picker's own ranking), frames_first (whether the staged story create can serve it TODAY), cast (required / writer_owned), defaults.video_model, and episode_tokens (seconds + a min-max token range for one episode at that default length). episode_tokens COVERS THE START FRAMES AND THE SCENE VIDEOS ONLY - the cast portraits and the final render are extra, so it is the pitch figure for what the episode itself costs and is always an understatement of the all-in. cast, defaults and episode_tokens are each NULL on a series the catalog cannot fully describe - say nothing about its cost and fetch its full entry instead of guessing a number. That is a SHORTLIST, and it is all it is: it deliberately carries no duration ladder, no per-model prices and no create arguments, because the full catalog is half a megabyte and does not fit in a tool result. WITH series_id you get that ONE series IN FULL, and you MUST make this call before you quote a price or create anything. It adds scene_count (min/max/default), the idea-input descriptor with has_idea_presets, the duration block, the complete defaults (video / start-frame / portrait models AND the language the series is written in) and the whole pricing block described next. Never quote money off the compact list: episode_tokens is an orientation figure for a one-line pitch, not a quote. PASS video_model WITH IT. A full entry ships the priced duration ladder for EVERY video model the series offers - around ninety rungs - and you need exactly one: the model you are going to create on. video_model returns only that model's block, which is the difference between a large result and a small one on the call this tool makes mandatory. Pass the series' defaults.video_model unless the user named a model; omit it only when you genuinely mean to compare models. A model the series does not publish is refused with the ones it does, so an id you guessed never silently returns an empty ladder. TWO BLOCKS ARE INFORMATIONAL - READ THEM, DO NOT TRY TO SEND THEM. duration (fixed_only, default_mode, default_scene_seconds, auto_range) describes the writer's own per-scene sizing; there is no matching argument on generate_story_video, which takes duration_seconds off the ladder and nothing else. And scene_count (min/max/default) is internal bookkeeping in the same way - see NEVER ASK FOR A SCENE COUNT below. Neither is an input you are failing to set. PRICING, AND THE ONE BLOCK YOU MUST READ - IT ARRIVES ONLY ON THE series_id CALL: pricing.video_models[].durations is the episode-length PICKER - each option is a real length in seconds with the scene_count it derives, frames_tokens (charged at create), videos_tokens (charged at fire) and total_tokens. durations.default_seconds is the rung to assume. There is also pricing.start_frame_models (per-frame rates for the optional advanced pick), pricing.frame_regen_tokens (what ONE redraw costs) and pricing.render_tokens_per_minute (what the FINAL render costs per rendered minute - a platform rate, the same one render_story_video charges at). THE RENDER RATE IS HOW AN EPISODE'S TOTAL GETS A FOURTH LINE: render_story_video cannot quote its own price until the scene videos are done, so before then this rate is the only published source - state it as a rate or as a rough figure with a tilde, never as the price. ANY OF THESE BLOCKS CAN BE NULL on a series the catalog cannot fully describe - durations, defaults, frame_regen_tokens, even pricing itself. A null is not a zero and never a guess: fall back to estimate_only on the tool that would spend, and if durations is null this series cannot be sized from here at all (say so and point at the aicut web app). Every figure here is the webapp's own quote for that rung; the authoritative episode quote is still the create tool's estimate_only. QUOTE A RUNG HONESTLY - TWO FLAGS, AND THEY ARE NOT THE SAME QUESTION. (1) videos_estimated = is the video figure one the writer is HELD to. When it is true the episode writer picks its own scene count and lengths whatever this rung orders, so mark videos_tokens with a tilde ('~7.5 T') even when exact is true - a rung is routinely both, and today every rung that pins a per-scene length is. (2) frames_estimated = the same question for the frames row: true when the rung orders only a total length, so frames_tokens is what the expected scene count costs rather than the charge - tilde it ('~2 T'). THE TOTAL takes a tilde whenever EITHER videos_estimated or frames_estimated is true, because the total is the two rows added. These are the webapp sign-off's own verdicts, so a rung quoted this way reads exactly as its button does. exact IS A SEPARATE FLAG AND IT IS TRUE ON EVERY RUNG THAT SHIPS: the price is one number, not a range. If one ever ships with exact: false, do not read the price off the rung - call estimate_only and quote that. AND ONE FLAG IS NOT ABOUT MONEY AT ALL: scene_count_estimated true means scene_count is what THIS RUNG DERIVES and not what the episode will contain - the writer picks its own count, which is exactly why the frames figure is loose. Never state such a count as a fact. NEVER ASK FOR A SCENE COUNT. Scenes are a mechanism unit and no tool here takes one: the sizing question is LENGTH in seconds, and the create takes duration_seconds off the ladder above. NEVER STATE A SCENE COUNT AS FACT. A rung's scene_count is what THAT RUNG DERIVES, not what the episode will contain: the writer sizes the episode itself and routinely lands a scene or two either side - on a rung whose frames_estimated is true it is not held to the count at all. So do not say 'at 20s that's 3 scenes'. If the user asks how many scenes they get, answer with the hedge attached - 'the writer decides; this length usually comes out around 3' - and never let a count you stated become a number the user thinks they bought. The count is not a sizing input, not a quote, and not a promise. AND DO NOT VOLUNTEER IT AT ALL: scene_count is internal bookkeeping that rides these responses so the machinery can be reasoned about, not a fact the product tells anyone - the webapp never shows a user a scene count and never asks for one, so neither do you. Answer it only if the user asks, with the hedge above, and never open a sizing question with it. DEFAULTS RULE: use each series' defaults (the series_id call) unless the USER names a model. Do not interview the user about options they did not ask about - the defaults are what the series is tuned for. ONE CARVE-OUT (and it is parity, not an exception): the two models that DRAW THE PICTURES - the start-frame model and the cast portrait model - are visible pickers in the webapp, so name each once, in the line where you are already asking something, with the default and its price already chosen. Name it; do not wait on it. defaults.language is the language the series is WRITTEN IN (some are German formats): use it, and only raise language at all if the user asks for a different one. When defaults is null the series names none - omit the model arguments and let the create resolve them. PRESENTING, WHERE THERE IS NO CARD - on a client that renders one you should not be here, you should have called browse_series. The compact list ARRIVES SORTED in the aicut picker's own order, ranked by real usage, so the first few entries ARE the shortlist. (rank is each series' position in the webapp's full picker, so the numbers can start above 0 and skip: some series are not served here at all.) When the user asks broadly (what formats exist, what should I make), present a SHORTLIST of 3-5: the TOP MATCHES by that published rank among the ones that fit their ask, name + one-line pitch + episode_tokens as a rough cost ('~10 T for 30s') each, plus a count of the rest. badge is worth one word when it is there. DO NOT PASTE preview_url OR preview_video_url INTO THE CHAT. Written as a markdown image a preview renders as a grey placeholder the reader has to click, and a preview clip written as a link is a trip to a browser tab - which is the exact reading experience browse_series exists to replace, and shipping it as a fallback taught the card's own catalogue to look broken. Describe the series in words here and offer the card: an 'I can show you these' followed by browse_series. NEVER dump the whole catalog into chat, and never fan out series_id calls across the shortlist - fetch the one series the user picks. WHEN: the user is BROWSING or deciding which series to use - browse_series first, not this tool. Call this one with NO arguments only where the client cannot render the card, or when what is wanted is catalogue DATA rather than a look at the catalogue; call it with series_id as soon as one series is settled, before you price or create anything. THE STAGED FLOW this catalog feeds: pick a series, then INVENT episode ideas yourself and settle one with the user in chat - offer 3 of your own in one line each and sharpen from their reaction; list_series_ideas is the series' own preset cards and is for when the user asks for THOSE, not the default opening move. The idea is one short paragraph and the engine writes the scenes, never you. Then the staged tools take it from there: generate_cast (the FREE roster draft) and generate_cast_portraits (the PAID faces) on a series whose cast.required is true, then generate_story_video (the start frames generate and the run PARKS for review), regenerate_story_frame for frames the user dislikes and set_scene_kept to cut one, fire_story_video (the scene videos), then render_story_video (the final file). BREVITY: lead with the ONE decision you need from the user, and keep at most one short paragraph before the question. Never re-explain the staged flow (cast -> frames -> fire -> render) once it has been explained in this conversation - after that, name only the next step. When suggesting episode ideas, offer at most 3, one line each. OUTPUT: this returns JSON for you to read. When you report back to the user, give them the media URL plus a one-line summary. Do not paste the raw JSON, job ids, or internal field names into the conversation.