Cast

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

Annotations declare readOnlyHint/idempotent/non-destructive, and the description reinforces this with the crucial disclosure that the tool "does NOT generate anything, charge anything or need an account" — preventing an agent from misreporting a charge. It also discloses the downstream flow (URL on malfoid.tv/cast, a pass holder films in Create) and the pass requirement, which no annotation conveys.

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 core action, the return value, the no-charge/no-account caveat and the character routing all appear in a logical order with a concrete example. It runs long and the opening phrase "makes a short vertical AI video" sits in slight tension with the later "does NOT generate anything," costing a little crispness, but no sentence is pure filler.

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 an output schema, the description covers what an agent needs: what the URL is, what to tell the user, that filming requires a pass, and how to choose between premade and custom characters. Return-value details are delegated appropriately to the output schema.

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 coverage is 100%, so enum meanings (vibe, style, camera, seconds) are already documented and the description rightly does not repeat them. It does add real routing logic beyond the schema: use character="malfoid" or "malfoid,leo" for premade cast, and character_name plus character_description for anyone else, with the note that the user designs that character first.

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?

Opens with a specific verb and artifact: "Build a one-tap link that makes a short vertical AI video of a character doing what the user describes," with an inline example. It is immediately distinguishable from siblings get_prices, get_showcase and list_characters, and it explicitly routes to list_characters for supported premade cast.

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?

"Use this whenever the user asks for an AI video, short, clip, TikTok/Reel/Shorts-style video, or animation of a character" gives explicit trigger conditions, and the description names the alternatives: list_characters for premade slugs, story cards for other cast members, and the credit-paid path for longer videos or custom characters.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered and the closing 'Read-only' merely restates it. The description does add value beyond annotations by noting prices 'follow the live model price table,' warning the agent that returned values are time-sensitive even though the call is idempotent and that stale/from-memory figures are unreliable.

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?

Two sentences, front-loaded with the resource and its contents, then the operational directive. Every clause carries information: the enumeration tells the agent what to expect back, and the live-price note prevents a real failure mode.

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, yet the description effectively describes the return content by listing the price categories and units (USD and credits). With annotations covering safety and no parameters to document, nothing an agent needs in order to call this correctly is missing.

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, so the baseline is 4; there is no parameter surface the description needed to explain and it does not waste space pretending otherwise.

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 ('Current Cast prices in USD and credits') and then enumerates exactly what price categories are covered: Season 1 weekly passes, agent credit packs, Premium, per-video-length credit costs, and new-character cost. An agent knows precisely what it gets without opening the schema, and the scope is clearly distinct from the sibling tools (create_video_link, get_showcase, list_characters).

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 says to 'call this instead of quoting from memory,' which is a clear when-to-use directive and names the alternative behavior being displaced. It lacks explicit when-not conditions or routing among the sibling tools, but for a zero-parameter price lookup there is little ambiguity left.

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

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.

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.