AI character videos from one line: returns a link the user taps. First video free, no account.
Scored across 4 tools
Each tool targets a distinct concern: create_video_link performs the action, get_prices returns pricing, get_showcase returns example videos, and list_characters returns available characters. There is no meaningful overlap, and the descriptions reinforce clear boundaries between discovery, pricing, and generation.
All four names use the same snake_case verb_noun pattern (create_video_link, get_prices, get_showcase, list_characters). The verbs differ appropriately by action, which is standard and predictable rather than inconsistent.
Four tools is well-scoped for a service whose core job is building a render link: it covers character discovery, examples, pricing, and link creation. Each tool earns its place with no redundancy or obvious filler.
The surface covers the main workflow: choose a character, see examples, check prices, and build a link. There is no tool to poll render status or retrieve the finished video, but since rendering happens in the user's feed via the returned URL, this is a minor gap rather than a workflow blocker.
Build a one-tap link that makes a short vertical AI video of a character doing what the user describes (e.g. "Malfoid dances on the castle roof at midnight"). Use this whenever the user asks for an AI video, short, clip, TikTok/Reel/Shorts-style video, or animation of a character, avatar, mascot or persona. Returns a URL on cast.katechon.technology. Give the URL to the user and tell them to open it and tap the button: the video renders in their private feed, usually within half a minute (a few minutes for a 2-3 character group scene). This tool does NOT generate anything, charge anything or need an account. The user's first 5-second video with a premade character (malfoid, thea, odette) is free; longer videos and custom characters cost credits (from $4.99). For a premade character pass character="malfoid" (or "malfoid,thea" for up to 3). For anyone else pass character_name and character_description (their look) instead; the user designs the character before the video.
| Name | Required | Description | Default |
|---|---|---|---|
| vibe | No | Mood and pacing. chill: Warm, low stakes; hype: Kinetic energy; dreamy: Soft and floating; eerie: Quiet dread; melancholy: Rain and distance; romantic: Tender and close; epic: Enormous scale; comedy: Snappy timing; fury: Rage with weight. Default hype. | |
| style | No | Visual style. influencer: Phone-camera real; cinematic: Feature-film look; sakuga: Hand-painted anime action; glam: Fashion-week polish; vhs: Camcorder nostalgia; vlog: Warm everyday diary; dark-fantasy: Gothic myth & magic; toon3d: Animated-feature charm. Default influencer. | |
| camera | No | Camera. auto: Let it decide; selfie: Phone-POV one-take; close-up: Faces fill the frame; wide: Big world, small figures; handheld: Breathing operator; push-in: Slow dolly in; chase: Tracking at speed; low-angle: Hero from below; overhead: God's-eye view; held: Locked-off frame. Default selfie (phone-POV livestream). | |
| prompt | Yes | What happens in the video, one line in plain words, present tense, without the character's name at the start. Concrete action + place works best: "dances on the castle roof at midnight", "reads her hate comments live and claps back". | |
| seconds | No | Length in seconds. 5 is the free first video; up to 10 without Premium; 15 needs Premium. | |
| character | No | Premade character slug(s), comma-separated, up to 3: malfoid, thea, odette. Omit when using character_name/character_description. | |
| character_name | No | Name of a NEW character to design (not one of the premade slugs). | |
| character_description | No | The new character's look in one or two sentences: age, hair, face, clothes, vibe. Required for a good result when character_name is set. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| vibe | No | |
| notes | No | |
| style | No | |
| camera | No | |
| prompt | No | |
| credits | No | |
| seconds | No | |
| character | No | |
| free_for_new_visitors | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations, which already declare readOnly/idempotent/non-destructive. The description discloses that the tool only returns a URL on cast.katechon.technology, that the user must open it and tap a button, that rendering happens in their private feed in ~30s (or minutes for a group scene), that nothing is generated, charged or account-gated at call time, and the free-vs-credits pricing boundary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core verb and the trigger phrase in the first two sentences, then layers output behavior, pricing and the character branches. It is denser than strictly necessary across five sentences and the pricing sentence is slightly tangential, but almost every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with four enums and a deep schema, the description covers the remaining ambiguity an agent needs: the two mutually exclusive character paths, the free/paid boundary, and what the caller receives back. An output schema exists, yet the description still correctly frames the return as a link the human must act on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the description is not required to document enum values. It still adds selection logic the schema only partially carries: use the premade slugs for malfoid/thea/odette (up to 3), otherwise pass character_name plus character_description, and the cost/premium constraints tied to seconds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Build a one-tap link that makes a short vertical AI video of a character doing what the user describes.' It is immediately distinguishable from the siblings (get_prices, get_showcase, list_characters), which are lookup/list tools, and it spells out the input shape (a described action plus a character).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a strong when-to-use trigger: 'Use this whenever the user asks for an AI video, short, clip, TikTok/Reel/Shorts-style video, or animation.' It also implicitly scopes the character branches. However, it never names an alternative tool or an explicit when-not-to-use case, so it falls just short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current Cast prices in USD and credits: the free first video, credit packs, Premium, and the credit cost of every video length and of a new character. Prices follow the live model price table, so call this instead of quoting from memory. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the trailing 'Read-only' is largely redundant. The description nevertheless adds genuine behavioral value beyond the annotations: prices track a live model price table (freshness/reliability) and returns are denominated in both USD and credits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with what is returned, then usage guidance, then the safety note. The only wasted clause is the final 'Read-only', which duplicates readOnlyHint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the return-value burden and does so by enumerating the price categories the agent will receive. Enough is stated to call the tool and interpret the result without surprises.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters (empty object, additionalProperties false), so there is no parameter syntax to explain and the baseline is a 4. Nothing in the description misleads about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Current Cast prices in USD and credits') and then enumerates the exact price categories covered: free first video, credit packs, Premium, per-length video costs, and character creation. Siblings (create_video_link, get_showcase, list_characters) are unrelated in scope, so there is no overlap to disambiguate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to 'call this instead of quoting from memory', which is actionable when-to-use guidance tied to a real failure mode. It doesn't mention any tool-level alternative, but no sibling covers pricing, so there is little to exclude.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Example videos of Cast characters (video URL, poster image, the line that produced it when on record, page link, and a ready-made remix link). Use to show the user what Cast makes before they open a link, or to find a proven prompt to adapt. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many examples (default 6). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so 'Read-only.' is largely redundant. What the description does add is the shape of the returned records (video URL, poster image, originating line, page link, remix link), which goes beyond what any structured field provides and helps the agent decide whether the call answers the user's question.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The sentence listing the returned fields is front-loaded and informative, and the usage clause follows immediately. The trailing 'Read-only.' is the one wasted fragment since the annotation block already carries that fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 correctly compensates by describing what each example contains. With zero required parameters and the single optional limit documented in the schema, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter at 100% schema description coverage, the schema already documents 'limit' including its default of 6 and its 1-20 bounds. The description adds nothing about the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource precisely (Example videos of Cast characters) and even enumerates the payload (video URL, poster image, source line, page link, remix link), which clearly separates it from siblings like list_characters and create_video_link. It stops short of an explicit verb phrase ('retrieve/fetch'), but the noun-first phrasing plus the function name leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states two concrete when-to-use scenarios: showing the user what Cast makes before they open a link, and finding a proven prompt to adapt. There are no explicit exclusions or named alternatives (e.g., when to prefer list_characters for browsing characters), so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the premade characters Cast can put in a video (slug, name, look, image, whether free), plus how to design a custom one. Call before create_video_link when you need a character slug or want to show the user who they can cast. Read-only, no account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| custom | No | |
| characters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's 'Read-only' is largely redundant. However, 'no account' adds genuinely new context about auth requirements, and the note that it also covers 'how to design a custom one' signals extra non-obvious payload beyond the field list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action and return fields, then the usage trigger. No filler and every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema present, the description supplies everything needed: what it lists, the fields, when to call it, and that no account is required. Return-value explanation is technically redundant with the output schema but harmless.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 per the rubric. The description's enumeration of return values does not substitute for parameter guidance, but none is needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the premade characters Cast can put in a video') and even enumerates the returned fields (slug, name, look, image, free status). It also names the sibling tool create_video_link, so an agent can place it against alternatives immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call it: 'Call before create_video_link when you need a character slug or want to show the user who they can cast.' This gives both the trigger condition and the downstream dependency, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_video_linkget_pricesget_showcaselist_charactersGenerate AI talking-head videos with custom characters and voices.
Animated AI characters in your chat: short clips of a character saying your words, or a live talk.
Make short vertical social videos (Reels, TikTok, Shorts) by chatting, with AI actors and voices.
Make videos in chat: captions, reels from long videos, AI shots, music. Your first video is free.
Add one secure layer between your agents and this server.
