Digital Maker AI

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

With no annotations, the description carries the full burden and does so richly: it discloses the credit model (spends animated scenes allowance, Premium 5/Ultimate 10 plus Animation Pack, never video minutes), the duration (a few minutes), and the concurrency limit (one animation at a time per video). It also confirms the original video is preserved, which is critical for a mutation tool.

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 sentences, front-loaded with the action and outcome, then constraints, then cost and timing. Dense but slightly repetitive in restating the scene-selection requirement.

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?

Despite no output schema, the description closes the loop by directing the agent to check_animation for the resulting link, and it covers cost, eligibility, concurrency, and sequencing. An agent has everything needed to call this correctly and explain the outcome to the user.

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 both parameters are already documented, including that scene numbers come from list_video_scenes and start at 1. The description reinforces the 'which scenes, in their own words' framing but adds no format or syntax detail beyond the schema.

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 ('Turn chosen scenes of a finished video into moving AI video clips') plus the side effect of rendering a new animated video alongside the kept original. An agent can distinguish it from siblings like create_video or check_animation without opening a schema.

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?

Explicit when/when-not: multi-scene only, landscape or vertical, not whiteboard or single scene. It also gives the sequencing rule (only call after the user has named the scenes in their own words) and routes the agent to check_animation for the link.

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?

With no annotations, the description carries the full burden and does well: it discloses the cost ('Costs one image') and the destructive side effect that the new picture 'replaces the old one', which an agent needs before overwriting user work. It stops short of stating whether the old image is recoverable or what happens on failure, so a four rather than a five.

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 compact sentences, front-loaded with the action and its core constraint, followed by cost and replacement behavior. Every clause carries information an agent needs; nothing is 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 a two-parameter mutation tool with no annotations and no output schema, the description covers the essentials: what it edits, the single-change rule, the credit cost, and that the old image is replaced. It lacks only explicit sibling routing and failure-mode behavior to be fully complete.

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% and both parameters are already documented, so the schema does the heavy lifting. The description adds meaning by illustrating the 'change' parameter with natural-language examples ('give him a blue tunic', 'make her older') and by emphasizing 'ONE change', which constrains how the free-text field should be filled.

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 gives a specific verb and resource ('Regenerate one of the user's 3D characters') plus the key constraint of a single change, so the action is unambiguous. It does not distinguish itself from close siblings such as change_character, manage_3d_character, or create_3d_character, so an agent must infer the 3D-specific boundary.

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?

Usage is implied rather than stated: 'keeping everything else the same' signals this is for small edits to an existing character, and the three quoted examples clarify acceptable change requests. There is no explicit when-not guidance or named alternative (e.g. creating a new character vs editing) to route the agent among siblings.

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?

With no annotations, the description carries the full burden and does well: it discloses the cost ('Costs one image'), the destructive side effect ('the saved character's picture is replaced by the new one'), and what is preserved versus changed (face, hair, skin tone, build, art style). It omits reversibility of the overwrite and failure behavior for an unknown name.

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 action and the one-change constraint, then layers the draft/saved routing and cost. The parenthetical examples are load-bearing rather than filler, and there is no redundant restatement of the tool name.

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 two-parameter tool with no output schema, the description covers invocation modes, cost, persistence effects, and the visible result ('Shows the new picture'). It stops short of covering edge cases such as a nonexistent saved name or what happens to prior versions.

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 the baseline is 3. The description goes beyond it by explaining the consequence of supplying 'name' (the saved picture is replaced) and by illustrating what counts as a valid 'change' with three examples, which the schema's terse 'The one thing to change' does not convey.

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 ('Regenerate a character') plus a hard scope constraint ('with ONE change') and gives three concrete example prompts. An agent can immediately distinguish this from create_character, draw_character, and manage_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?

Explicitly routes between two modes: the current unsaved draft from draw_character, or a saved character identified by name (pointing to list_characters for discovery). The 'ONE change' framing implies multiple changes need a different path, but that exclusion is never stated outright.

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?

With no annotations, the description carries the full burden and does disclose key traits: cost ("Free"), a quota ("daily limit"), a single-change limit, identity preservation, and that the result is displayed. It omits what happens at the daily limit, whether the operation is reversible, and whether the draft is consumed.

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 action and constraint, then cost, then the prerequisite. Every sentence carries information the agent cannot get from the schema or annotations.

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 one-parameter mutation with no output schema, the description covers scope, identity preservation, cost, quota, and the prerequisite, and states that a picture is returned. Remaining gaps are quota behavior past the daily limit and the draft's state after the call.

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% and already supplies examples and a length range, so the schema does the heavy lifting. The description adds one genuinely useful constraint the schema lacks — that only one change may be requested at a time — but nothing else about how to phrase the change.

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 ("Change one thing about the presenter picture just made") and immediately bounds scope with "keeping the same person" plus an enumeration of changeable attributes. The closing clause routes the agent away from make_presenter/draw_presenter by tying it to an existing draft.

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 hard precondition — "Only works on an unmade draft from draw_presenter" — which is exactly the when-to-use information an agent needs to avoid a failed call. It does not say what to do instead when the draft is already made or when multiple changes are wanted, so the sibling routing is incomplete.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds context beyond them: the call is a status probe whose result becomes richer over time (the link appears 'once it is ready') and it should not be polled. That timing/polling behavior is not expressible in annotations and is the main thing an agent could get wrong.

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 compact sentences with no filler; the return content is front-loaded and the usage constraint follows. Minor awkwardness in 'is getting on' but nothing wasted.

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, the description does the necessary work of saying what comes back (progress status and, eventually, the animated video link). Combined with annotations and full param coverage, an agent has enough to call it 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?

Only one parameter and schema description coverage is 100%, including the 'omit for the most recent video' default, so the schema carries the load. The description adds nothing about video_id semantics beyond that, which is the expected baseline when coverage is complete.

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 resource (an animation created by animate_scenes) and what it returns: progress plus the link to the animated video once ready. It clearly differs from siblings like check_video or check_drive_upload, though the phrasing 'How ... is getting on' is informal rather than a crisp verb+resource statement.

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 an explicit trigger ('Call it when the user asks') and an explicit anti-pattern ('not on a loop'), which is genuinely useful routing guidance. It does not name a specific sibling alternative, but the on-demand vs polling distinction is the key decision here.

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 indicate readOnly and idempotent behavior. Description adds typical timing (under a minute, longer for long videos) and advises against polling, which is useful behavioral context beyond annotations. But doesn't describe error states, what happens if job_id omitted, or return format.

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 concise sentences, front-loaded with purpose and timing, then usage guidance. Every sentence adds value with no redundancy.

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 simple read-only check with one optional parameter and no output schema, the description covers purpose, timing, and usage. Minor gap: doesn't explain what the Drive link looks like or handling of errors, but adequate for basic use.

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 the parameter semantics are fully documented in the schema. The description doesn't add additional meaning about job_id, but doesn't need to since schema is complete. Baseline 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?

States specific verb (Check) and resource (Drive upload progress), plus outcome (get Drive link). Distinguishes from siblings like save_to_drive and check_video by naming the specific upload job.

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?

Provides clear context: call when user asks, not on a loop. Implicitly suggests polling is discouraged. However, doesn't explicitly name save_to_drive as the prerequisite or alternative for checking other jobs.

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 safety profile is covered. The description adds useful guidance against polling, which is a behavioral trait not in the annotations. It doesn't mention what 'ready' means or what the response looks like.

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 short sentences with no waste; the purpose and the usage warning are front-loaded. Every sentence 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 a simple one-parameter read-only status check with full schema coverage and annotations, this is adequate but thin. No output schema exists, so the description could say more about what 'ready' means or the shape of the result, which an agent would need to interpret the response.

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% and the single parameter 'name' is fully documented in the schema, including the omit-for-most-recent behavior. The description adds no parameter meaning beyond the schema, so baseline 3 applies.

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 clearly it checks whether a presenter from make_presenter is ready for video use, naming the verb (check readiness) and resource (presenter). Distinguishes itself from make_presenter by referencing it, though it doesn't differentiate from sibling status-checkers like check_video or check_animation.

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 temporal cue ('yet') and a behavioral instruction ('call when the user asks, not on a loop'), which implies polling avoidance. However, it doesn't specify which alternative to use when the user asks about other readiness states, and doesn't clarify prerequisites like whether make_presenter must have been called first.

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 cover read-only and idempotent behavior, so the description adds genuinely new context: the tool becomes useful only after posting, returns links once complete, and should not be polled. The anti-loop warning is a behavioral trait not expressible in the annotations.

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 short sentences, front-loaded with the return semantics and closed with the usage constraint. No filler, no restatement of the name.

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, the description carries the burden of telling the agent what comes back, and it does ('the links once it has'). What's missing is the intermediate state (what it reports while the post is still pending), but the core contract is covered.

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?

One required parameter with 100% schema description coverage, so the schema already explains that post_id comes from post_to_social. The description reinforces the origin but adds no format or syntax detail beyond it; baseline 3 applies.

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 check verb against a specific resource (a post from post_to_social) and says what it yields: whether the post went out plus the links. An agent can distinguish it from the sibling post_to_social, which publishes rather than reports.

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 when to call it ('when the user asks') and, more importantly, when not to ('not on a loop'), which is real operational guidance. It doesn't enumerate alternative status-check siblings, but the reference to post_to_social grounds the workflow.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real context: long-form jobs take many minutes (timing/latency expectations) and a completed job yields a link. It also discloses post-completion UI behavior (panel offering scene animation or 3D shot review), which an agent could not infer from structured fields.

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-loaded with the core action, followed by the timing caveat and the no-loop rule; every sentence carries information. The final sentence about panels is long and slightly convoluted, but it is not 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?

With no output schema, the description must carry return-value burden. It explains the success case (a link once ready) but never says what comes back while the job is still in progress (status string, progress, error states), which is exactly what a polling tool returns most of the time.

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% and the single parameter is fully documented in the schema ('Job id from create_video. Omit for the most recent video.'). The description adds no additional meaning about video_id, so the baseline of 3 applies.

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: 'Check how a video is coming along and get the link once ready.' An agent can distinguish this status-poll from create_video, update_video, and the other check_* siblings without opening the schema. It stops short of naming an alternative explicitly, so it is clear but not fully differentiated.

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 an explicit usage condition ('Call when the user asks') and an explicit prohibition ('not on a loop'), which is the key failure mode for a polling tool. It does not name a sibling alternative, but there is no real substitute for a status check, so the guidance is effectively complete.

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?

With no annotations supplied, the description carries the full behavioral burden and does so well: it discloses the cost ('Costs one image from the monthly image allowance' with exact per-plan quotas), plan gating, that the result is a draft the user must save, the library limit of 20, and hard content constraints on the look. That is unusually rich disclosure for a generation tool with zero annotation coverage.

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 main action is front-loaded in the first sentence and nearly every clause carries operational value (cost, plan, storage, restrictions). It is written as a dense run-on with semicolons and parentheticals, so it reads as a wall of text rather than a scannable structure, which costs it a point.

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 no-output-schema, no-annotation generation tool, the description covers cost, eligibility, storage/draft lifecycle, sibling relationships, and even the instruction to show the returned picture. It does not address failure modes, regeneration of a failed attempt, or latency, which are minor gaps given the otherwise thorough coverage.

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 already 100%, so the baseline is 3; the description adds real constraints beyond the schema, notably 'Keep looks to appearance and one outfit (for a child only hair, eyes, height and outfit)' and 'no held objects', which shape how the description parameter should be written. It also reinforces that photo_url must be a public https link rather than a chat paste, though that is largely duplicative of the schema.

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 ('Create one character for a 3D Animated film as a Pixar-style 3D reference sheet, full body on white') and covers both input modes: written look or the user's own photo via photo_url. It also draws the boundary against a sibling by noting '3D characters are separate from the regular saved characters used by create_video,' so an agent can distinguish it from create_character and draw_character without opening a schema.

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?

Names the follow-on alternatives explicitly: 'the user can adjust it with change_3d_character' and 'manage_3d_character save keeps it in their 3D library (holds 20)'. It also states eligibility (Pro, Premium, Ultimate) and content exclusions (no held objects, no film or TV characters). It stops short of stating when to choose this over create_character/create_video characters directly, leaving that inference to the 'separate from' sentence.

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?

With no annotations, the description carries the full burden and does so: it discloses real-money cost (one 3D minute per film minute, never plan minutes, Ultimate includes 2/month), the refusal-and-upsell behavior when the account is short, and a 30–90 minute render time with an async job id to poll via check_video. It even explains the exception path for sung nursery rhymes (no narrator, no music, fixed 3 minutes) that overrides several schema fields.

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 cost warning and 'call it ONCE' constraint are front-loaded, and each labeled block (STORY, PRESET, CAST, NARRATOR) maps to a parameter group. It is dense and long, and the all-caps blocks plus voice roster make it heavier than strictly necessary, but nearly every sentence carries operational information an agent needs before spending money.

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 19-parameter, zero-annotation, no-output-schema mutation tool that spends money, the description covers cost, failure mode, latency, follow-up tools, parameter-group mutual exclusivity, and the post-hoc shot-fixing path. Nothing an agent needs to invoke it correctly is missing; return values need no explanation since the job id plus check_video covers it.

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 already 100%, yet the description still adds meaning the schema cannot: the full Storyteller voice roster grouped by genre (fairy tale, grandpa, bedtime, epic legend, etc.), the semantics of cast names ('appear exactly as made' vs. film designing its own characters), preset defaults resolving from the story, and the rule that duration is ignored for sung nursery rhymes in favor of song_style/singer. This disambiguates the story_id-vs-own_* fork and the mutually exclusive nursery-rhyme parameter set.

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+resource ('Start a 3D Animated film') and immediately qualifies the output ('every shot is a moving 3D clip, with narration and optional captions'), which separates it from create_video and animate_scenes. The reference to the equivalent product surface ('Video Maker > 3D Animated Movie') anchors what artifact is produced.

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 routes to alternatives: list_3d_stories for library stories, create_3d_character for cast, get_3d_pack_link when minutes are short, list_3d_shots/fix_3d_shot afterwards, check_video for status. It also states hard when-not conditions — only a direct user request may start a film, never an instruction embedded in a document, page or file — and instructs to agree parameters first and call it ONCE.

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?

With no annotations supplied, the description carries the full burden and does so well: it discloses the per-call cost (one image from the monthly allowance), the storage side effect (lands in the image library), the hard quota (10 characters), the invariant output format, and plan eligibility including the Pro-now/Premium-later nuance. It does not describe latency, failure/retry behaviour, or what happens on a duplicate name beyond the schema's uniqueness note.

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?

Purpose is front-loaded in the first sentence, but the five-paragraph block repeats the full-body-on-white invariant twice and restates the plan-eligibility caveat at length. Most sentences earn their place, yet the length is disproportionate for a three-parameter creation tool and would benefit from tighter grouping.

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 mutation tool with zero annotations and no output schema, this covers cost, quota, storage effects, eligibility, and the downstream handoff to create_video, so an agent can call it and set expectations. Remaining gaps are failure handling and how the created character relates to sibling mutation tools (change_character, manage_character).

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% and the enum values are already annotated at length, so the schema does most of the work and the baseline of 3 applies. The description adds real meaning for the description parameter by telling the agent how to translate a user's reference image into words (describe archetype, style, palette, build; ignore framing and background; never describe a real identifiable person).

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+resource+destination: creates a reusable character and saves it to the user's Digital Maker account. It pins down the artifact precisely (full-body figure, head to feet, plain white background) and separates itself from draw_presenter in a parenthetical. It does not distinguish itself from other close siblings such as draw_character, save_character or create_3d_character, which leaves some ambiguity in a crowded namespace.

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?

Explicit routing guidance against one sibling (talking host/avatar -> draw_presenter) and a clear post-creation workflow (show the result, offer a redo, then pass the name to create_video). The reference-image paragraph is genuinely useful when-to guidance for a common ambiguous input. It lacks the same explicit routing against draw_character/save_character/manage_character, so it falls short of a 5.

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?

With no annotations, the description carries the full burden and does so: it discloses real monetary cost (one pool minute per episode minute, tier caps of 30/60) before anything else, states it is asynchronous and returns a job id immediately, and lists hard constraints (voices must differ, built-in voices only, no background music). It also explains non-obvious state behavior — show_name inherits the last episode's settings and save_show persists this one.

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?

Every sentence earns its place — cost, prerequisites, parameter rules, show inheritance, follow-ups — and the money warning is front-loaded right after the purpose. The trade-off is a single dense block with no line breaks or bullets, which makes the studio and show rules harder to scan for a 14-parameter tool.

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 costly, asynchronous, multi-prerequisite creation tool with no output schema, the description covers everything an agent needs before calling: cost model, tier limits, async job-id return, required user agreement, valid studio/voice sources, and post-completion next steps. Only the CTA booleans are left unexplained, which is minor.

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?

At 79% schema coverage the description still adds real meaning the schema does not: the three accepted forms of 'studio' (approved image_url, saved studio name, public link), the side effect that a saved studio supplies host names/looks/voices, and the show_name inheritance/save_show pairing. It says nothing about like_cta, comment_cta or subscribe_cta, and doesn't clarify host_a/host_b 'look' or gender, so a few parameters remain undocumented in prose.

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 concrete verb and resource ('Start an Animated Podcast episode') and immediately describes the output artifact — two AI hosts, two voices, a held studio picture, captions. It is clearly distinguishable from edit_podcast and preview_podcast_studio, which appear later by name.

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?

Explicit about when and how to invoke: agree topic, length, tone, hosts and studio with the user first; call once per request, only on the user's own direct request. It also routes follow-up work (check_video for progress, make_podcast_thumbnail, podcast_youtube_details, edit_podcast after finishing) and names the prerequisite tools (preview_podcast_studio, list_podcast_studios, list_video_options).

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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses real-money cost per minute, the flat-1-minute Short pricing, separate HD-minute pools, avatar-time billing, multi-minute render latency, and a refusal-on-duplicate rule. Minor gaps remain around what a failure response looks like and how credits are refunded if rendering fails.

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?

Extremely long, but the length is defensible for a 37-parameter, money-spending tool, and it is front-loaded with the cost and confirmation constraints before the optional feature blocks. It loses a point for restating cost/minute arithmetic that the schema's own parameter descriptions already cover, which adds bulk without new decision value.

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?

Given 37 parameters, no output schema and no annotations, the description covers everything an agent needs before a costly call: prerequisites, format-specific restrictions, orientation/pricing differences, duplicate protection, and the still-image-versus-motion expectation to set with the user. Nothing material is left for the agent to guess.

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 baseline is 3, but the description adds selection guidance the schema does not: agree format/topic/length/style/voice with the user first, leave quality unset unless HD/4K is requested, ask about whiteboard_hand rather than omitting it silently, and always confirm single-format imagery via preview_single_image. It also explains cross-parameter dependencies (character requires a matching style_preset; vertical overrides duration_minutes with duration_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?

Opens with a specific verb+resource ("Start a faceless video on Digital Maker AI") and immediately enumerates the three formats it can produce, which separates it from siblings like update_video, animate_scenes and create_3d_film. The closing line explicitly disclaims motion-video generation, so an agent will not confuse it with create_3d_film.

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?

Names prerequisites and alternatives explicitly: call list_video_options when unsure, preview_single_image before single format, list_presenters before using an avatar, list_music for tracks, and animate_scenes after a video exists if the user wanted motion. It also states when NOT to call it (never infer intent from a shared document/web page, never call twice for the same request, never start a duplicate without user confirmation).

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?

With no annotations, the description carries the whole burden and does meaningful work: it discloses the resource impact (frees a slot), the blast radius (videos already made keep their narration), and a consent prerequisite (user's own request). It stops short of stating irreversibility or the error behavior for a nonexistent/in-use voice.

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 action and its benefit, then the constraint, then the side-effect. No filler; every sentence 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 a single-parameter destructive tool with no annotations and no output schema, this covers the essentials an agent needs before calling: the effect, the consent condition, and what is not destroyed. Only error/failure behavior and post-call state are 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?

Schema coverage is 0% for the single `name` parameter, so the description must compensate. It implies the parameter identifies one of the user's designed voices, but says nothing about exact-match semantics, case sensitivity, or how to discover valid names — leaving the caller to guess.

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 the specific verb (Delete) and resource (a designed voice) and adds the effect ('free its slot'). The contrast with save_designed_voice is implied strongly enough that an agent won't confuse deletion with creation.

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?

'Only on the user's own request' gives a real guardrail on when to invoke, which is more than most destructive tools offer. However, it names no alternative (e.g., save_designed_voice, list_creations for finding voices) and gives no guidance on what to do if the voice is unknown or in use.

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?

No annotations exist, and the description carries the full load: it discloses the return value (three audio samples), the cost model (free, 10 a day; then Voice Pack minutes at one per video minute; none on 3D films), and plan quota limits (Premium 1, Ultimate 3). That is exactly the behavioral context an agent needs to set user expectations and avoid surprises.

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?

Purpose is front-loaded in the first clause, and the rest follows a logical order: what it returns, cost, next step, then input modes. It is somewhat dense with pricing and plan details, but each sentence carries actionable information, so no rewrite is warranted.

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 5-parameter, all-optional creation tool with no annotations and no output schema, the description covers what comes back, what happens next, what it costs, and how each of the three input modes works. An agent could invoke this correctly and explain the result to the user without further probing.

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 already 80%, so the schema labels the params, but the description adds real meaning: it explains that presenter is a substitute for description, that story_topic works with story_preset, and gives a concrete example of the speaker-oriented style expected. It adds value beyond the schema without documenting every parameter individually.

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 ('Design a brand-new narrator voice from a written description') and pins the underlying product surface (ElevenLabs Voice Design via Settings > Voice > Design a voice). It is clearly distinguished from save_designed_voice, which is named as the persistence step rather than a competing action.

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 describes the follow-up path ('When the user picks one, save_designed_voice keeps it') and gives the three input modes — free-text description, presenter name, or story_topic + story_preset. It also instructs what to describe ('the SPEAKER... not the recording'), which is rare and useful. It stops short of stating when not to use this tool versus existing voices, so it is not a 5.

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?

With no annotations provided, the description carries the full burden and does so: nothing is saved, no name is consumed, one image is billed from the monthly allowance per picture, Pro tier is required, only public https links are accepted (not pasted images), and identifiable real people must never be reproduced. These are exactly the mutation/cost/policy facts an agent needs before calling.

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-loaded with the unsaved-preview constraint before the alternative and the cost/tier caveats, so a skimming agent still gets the essential contract. It is dense to the point of being run-on in the middle workflow sentence, but no sentence is 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 a non-destructive preview tool with no output schema and no annotations, the description covers lifecycle, persistence, billing, tier gating, reference-image handling and content policy. Nothing needed to invoke it correctly or explain the result to a user 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?

Schema coverage is 100%, so baseline is 3, but the description adds genuinely new meaning: reference_image_url must be a public https link rather than a pasted image, reference_mode selects between recreation ('same') and style transfer ('style'), and style maps to style_preset on create_video for downstream consistency. Only 'description' length/content is left entirely to the schema.

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 ('Create a recurring character for the user's videos') plus the defining constraint ('WITHOUT saving yet') and the concrete output ('a full-body figure on white in the chosen style preset'). It explicitly separates itself from create_character and save_character, so an agent can route correctly without opening any schema.

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 explicit when-to-use ('Prefer this over create_character whenever the user wants to see the character before it is saved') and a full branch map of follow-ups: save_character with a name, change_character for edits, or start again. Also states the access tier ('Pro and above') and the cost condition up front.

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?

With no annotations provided the description carries the full burden, and it discloses cost ('free'), redo behavior ('can be redone'), a rate constraint ('a daily limit applies'), and a destructive side effect ('calling this again replaces any unmade draft'). It further pins the output composition (always a photoreal presenter seated at a desk, hands on the desk) so the agent knows what the description can and cannot control.

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-loaded with purpose and workflow, and nearly every sentence adds new constraints rather than restating. The trailing fragment 'Premium and Ultimate.' is under-explained and reads as bolted on, which keeps it from a 5.

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 single-parameter creation tool with no annotations and no output schema, the description covers purpose, workflow, cost, limits, replacement semantics, tier gating, and expected result. Nothing an agent needs in order to call it 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: which attributes to include (age, build, hair, clothes, expression, room behind them), a prohibition on real identifiable people, and the fact that only identity/setting varies. The fixed staging info is the main thing the schema's example does not convey.

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 ('Create a new AI presenter... from a written description') plus the immediate side effect (the picture is shown in chat for approval). It also disambiguates from look-alike siblings by naming draw/change/make presenter steps, so an agent can tell it apart from change_presenter and make_presenter without opening schemas.

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?

Lays out the full workflow explicitly: this is step one, then change_presenter to adjust, then make_presenter to convert to a talking avatar. It also states exclusions ('Do not describe a real identifiable person') and tier eligibility ('Premium and Ultimate'), leaving little to inference.

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?

With no annotations, the description carries the full behavioral burden and delivers: 3-update cap, non-destructive versioning (current version stays until new one is ready), re-record vs re-render semantics for different change types, a 10% length constraint, and that it spends no minutes. This is exactly the beyond-structured-fields context an agent needs.

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 action and drops constraints in a dense, mostly sentence-per-idea block with no filler. It is somewhat long and has a slightly run-on opener ('as the editor under the podcast on the site does'), but nearly every clause conveys a distinct operational 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?

For a complex, high-parameter mutation tool with no output schema and no annotations, the description covers the safety, cost, versioning, and limits an agent must know before calling. Nothing essential to correct invocation 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?

Schema coverage is 67%, and the description reinforces the parameter groups by mapping edit intents to fields ('rewrite, delete or reassign script lines' → line_changes, 'either host's voice or name' → host_*_voice/name, 'captions, sound bar or studio picture'). It adds contextual meaning but does not detail individual optional params beyond what the schema already documents.

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 ('Change a FINISHED Animated Podcast') and enumerates what can be edited (script lines, host voice/name, captions, sound bar, studio picture), which cleanly separates it from siblings like create_podcast, get_podcast, and preview_podcast_studio. An agent can identify the tool 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear preconditions ('FINISHED' podcast, up to 3 updates, agree exact changes first and call once) that direct when and how to invoke it. It implies but never names alternatives or explicitly states when not to use it (e.g., use get_podcast to read first, create_podcast for new ones), so it stops short of full routing guidance.

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?

Beyond the read-only annotations, the description discloses data freshness (updated continuously), list-size caveats for hand-curated style filters, the instruction to state how many results came back, and the cost profile (reads only, costs nothing, spends no minutes). It also clarifies that start dates are always known, which manages agent behavior around missing data.

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 description is long but front-loaded with purpose and usage, then organized into distinct sections for styles, freshness, result limits, and date/revenue filters. Some repetition exists around read-only cost and returning counts, but almost every sentence adds actionable guidance for an 11-parameter tool.

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 11-parameter read-only search tool with no output schema, the description covers when to use it, how to re-use it for refreshed data, how many results to return, special style definitions, date and revenue filter examples, and important caveats about small curated lists. Nothing material is missing for correct invocation.

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 the baseline is 3. The description still adds useful meaning beyond the schema by explaining the video-style tags in detail, giving natural-language examples for dates and revenue filters, and clarifying how format and style combine with niche.

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 states a specific verb and resource: searching Digital Maker AI's Faceless Finder database for verified faceless YouTube channels. It clearly distinguishes the tool from generic knowledge or sibling creation tools by saying the data is verified, current, and should be preferred over model recall.

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 gives explicit when-to-use conditions: user asks about faceless channels in a space, wants examples, asks who is winning, asks about earnings, or names a specific channel. It also tells the agent to call again for refreshed figures rather than repeat prior answers, and not to pad short requests with extra channels.

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?

With no annotations supplied, the description carries the full burden and does so: it discloses the cost model (free mistake checks capped at 2 per shot, 1 free change per minute, then 3D pack minutes at 5 changes per minute), the asynchronous latency ('takes a couple of minutes'), and the blocking answer state with its two resolutions. These are exactly the traits an agent needs before mutating a film.

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-loaded with the core action, and practically every clause carries non-redundant information about modes, quotas, or state transitions. It is dense and parenthetical-heavy, which makes it slower to parse than ideal, but nothing is 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 a 6-parameter, no-annotation, no-output-schema mutation tool, the description covers prerequisites, per-mode behavior, quota/pricing, latency, blocking states, and the downstream calls that finalize the result. An agent could invoke and recover from this tool without additional context.

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 the baseline is 3, but the description adds real meaning beyond the schema by explaining the consequence of each mode enum value ('keep the picture, animate again' vs 'a new picture of the same characters and place') and the billing difference between reason=mistake and reason=change. It says less about shot, change, and video_id, but those are adequately documented in the schema.

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 resource: 'Remake one shot of a finished 3D film', then enumerates the three modes with what each preserves or regenerates. This distinguishes it clearly from siblings like regenerate_scene_image or animate_scenes, which operate on images or scene drafts rather than a finished 3D film shot.

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 gates usage ('Only on the user's own request'), explains the mistake-vs-change decision tree including the free-quota ordering, and describes the follow-up path via list_3d_shots, keep_3d_shot and update_3d_film. Even the edge case (a failed mistake check leaving the shot awaiting an answer) routes the agent to a concrete next call.

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?

With no annotations supplied, the description carries the full burden and does so: it discloses the monthly allowance by tier, that extra images can be bought, that results save to the user's library, and a hard rate limit of 100 images per hour. It also explains the non-obvious side effect that profile_picture with character crops the real image rather than regenerating it, which is exactly the kind of behavior an agent could otherwise get wrong.

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 most important constraints — what it makes, the quota, the rate limit, the image_type warning — are front-loaded, and the block-caps 'PROFILE PICTURES:' header usefully segments the trickiest case. It is on the long side and repeats profile_picture details already in the schema, and the all-caps emphasis is slightly heavy, but no sentence is wasted.

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 no-annotation, no-output-schema generation tool the description covers quota, persistence, rate limiting and the type/style decision well enough to call it safely. The one gap is the return value: it says the image saves to the library but never says what the call hands back (URL, id, or asset record), which an agent needs for follow-up steps.

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 the schema already defines all four parameters and their enums; the description's added value is the consequence framing ('Set image_type: it controls the shape of the result, and getting it wrong produces something the user cannot actually use') and the character face-matching behavior. It adds meaning beyond the schema without fully duplicating it, though much of the profile_picture enum text reappears nearly verbatim.

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 a concrete resource list ('Generate a YouTube thumbnail, channel banner, logo, product mockup or general image'), which maps directly to the image_type enum. It then explicitly distinguishes itself from the lookalike siblings create_character and draw_presenter, so an agent can route correctly without opening another schema.

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 explicit when-to-use rules for the ambiguous cases: profile_picture for avatars/icons, never logo for a picture of a person, create_character to make a reusable character instead, draw_presenter for an AI presenter. It also states the anti-pattern ('never loop to produce dozens of variations unless they asked for that many'), which is genuine routing guidance rather than restatement.

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?

Since no annotations were provided, the description carries the full behavioral burden. It reveals crucial operational details, such as the pricing matrix for different durations, the structure of the discounts, and the fact that 'Minutes never expire' while the plan is active.

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 description is necessarily verbose due to the complex business rules (pricing tiers, terms agreement). However, it is highly structured and front-loads the most critical procedural steps, making the complexity efficient rather than chaotic.

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?

Despite its length, the tool definition is fully contextualized. It includes the specific business logic (pricing, expiration, discounts) and the complex operational workflow required for successful execution, leaving no ambiguity for the calling agent.

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?

While the schema provides basic data types, the description adds critical semantic value. It specifically defines the role and usage constraints of `accepted_terms`, explaining that it must be set to true only after the user has completed a mandatory, multi-step agreement process.

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 immediately identifies the tool's function as generating a 'Stripe checkout link' specifically for a '3D Pack.' It provides detailed constraints and pricing information, clearly defining its purpose and scope within the overall service offering.

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?

The description dictates an exceptionally complex and precise usage flow: users MUST first call the tool without `accepted_terms` to receive statements, show them, and then only pass `accepted_terms: true` after user verification. This specific operational sequence is a clear guide on when and how to use the tool.

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 readOnly and idempotent; the description adds that the call is a cost-check and implicitly free/non-mutating. It does not describe response shape, but readOnly annotations carry that load.

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 what is returned, then the when. No waste.

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 no-param read-only preflight tool this is essentially complete. Return values are not enumerated field-by-field, but the description names the key fields and no output schema exists, so a small gap remains.

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?

Zero parameters, so baseline is 4; nothing to document and the description correctly treats it as parameterless.

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 states exactly what it returns: plan, renewal date, video minutes remaining, Drive connection status. Specific and distinguishable from every sibling, none of which expose account/billing state.

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 concrete trigger: 'Check before starting a long video so the user knows the cost.' No explicit when-not, but the preflight-before-video condition is actionable and names the alternative path implicitly.

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?

With no annotations, the description carries the full behavioral burden and does well on the highest-risk point: 'Nothing is charged unless the user opens the link and pays' and 'They never expire' tell the agent this is a non-destructive, non-committal action. It omits how the link is returned, whether it is single-use, or any auth/account coupling.

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 the purpose, followed by the billing reassurance and the pricing tiers. Every clause carries information the agent or user needs; nothing is padded.

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 simple two-parameter purchase-link tool with no output schema, the description covers purpose, trigger, pricing, and the no-charge guarantee. It does not describe what the caller receives back (presumably a URL) or whether the link is tied to the requesting account, which is the remaining gap.

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 the baseline is 3, but the description goes beyond the bare 'Which pack.' schema text by mapping each enum value to its scene count and price (starter 5 scenes $9, creator 11/$19, studio 43/$69), which helps the agent pick the right tier. The optional video_id is left to the schema's own explanation.

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 a specific deliverable — a secure checkout link for an Animation Pack — and states the triggering situation (the user wants more animated scenes than they have left). That condition implicitly separates it from the animate_scenes sibling, which consumes scenes rather than selling more, so an agent can route correctly 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear when-to-use trigger ('when the user wants more animated scenes than they have left'), which is exactly the context an agent needs. It does not name an explicit alternative tool or state when not to use it, so it stops short of the top score.

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/destructiveHint=false, so the safety profile is covered; the description still adds value by stating 'Reads only, costs nothing' (cost implication) and by disclosing pagination behavior for long scripts via the from parameter. No auth or rate-limit detail, but the pagination note is real behavioral context beyond the annotations.

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?

Four short sentences, front-loaded with what is returned, then usage, then pagination, then the read-only/cost note. Every sentence carries distinct information with no padding.

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, the description carries the burden of describing return values and does so by enumerating the episode fields, including the script format and its pagination. Nothing an agent needs to call it 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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: it explains that the script is paginated and that from is used to 'read on', and decodes the A = left host / B = right host line convention. This goes beyond the terse schema descriptions.

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?

Names a specific resource (an Animated Podcast episode) and enumerates exactly what is returned: hosts/voices, captions, sound bar, studio, remaining updates, and the script as A/B numbered lines. An agent can distinguish it from edit_podcast, create_podcast, and list_creations without opening a schema.

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 routes the agent: 'Use it before edit_podcast so the user can see what to change,' which establishes the read-then-edit workflow and the alternative it precedes. It does not state a when-not condition, but the context is clear.

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?

With no annotations, the description carries the full burden and does the key part: "Reads only, costs nothing" discloses both the side-effect profile and cost, which is the main risk an agent needs to know. It omits what happens for unfinished or missing videos and gives no sense of transcript size or truncation.

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 sentence is front-loaded and efficient, but the second sentence spends nearly half the text on scene-image downloading, which is adjacent routing information rather than what this tool produces. Tightening that to a clause would preserve the routing value without diluting focus.

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?

Return shape is described (full script, scene by scene) despite there being no output schema, and cost/safety are covered. For a zero-required-parameter read tool the gaps (unfinished-video behavior, empty transcript case) are small.

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% and the single parameter already documents "Omit for the most recent finished video," so the baseline applies. The description reinforces the "finished videos" constraint but adds no format or validity detail beyond the schema.

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 identifies the exact resource returned ("the full narration script ... scene by scene") and scopes it to one of the user's finished videos, which separates it from siblings like list_video_scenes or check_video. The verb is implicit ("The full narration script of...") rather than stated as "returns", but the outcome is unambiguous.

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 names concrete downstream uses (transcript, captions file, description, blog post) and routes the image-related need to list_video_scenes or the video page download. It stops short of explicit exclusions, e.g. it never says what to call when the video is unfinished or when only scene metadata is needed.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses pricing, expiration terms, refund behavior for failed videos, and plan eligibility, but it does not explain whether the checkout link is single-use, time-limited, account-bound, or what permissions are required.

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 description is compact and front-loads the key concept: a Stripe checkout link for Voice Pack minutes. The single dense sentence efficiently packs pricing and refund terms, though the trailing 'Premium and Ultimate' fragment is slightly abrupt.

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 one-parameter tool with no output schema and no annotations, the description supplies the essential context: what the link is for, the pack sizes, prices, expiration policy, refund behavior, and plan eligibility. It could be more complete about link lifecycle and auth, but the core is adequate.

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 0%, and the sole parameter is an enum. The description fully compensates by mapping each enum value to its minute allotment and price: small = 30 minutes $15, medium = 60 minutes $25, large = 120 minutes $45.

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 clearly identifies the resource as a Stripe checkout link for Voice Pack minutes and distinguishes it from sibling pack-link tools by naming the specific voice-minute domain. It lacks an explicit action verb such as 'get' or 'create', but the tool name and noun phrase make the purpose inferable.

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?

Usage is implied by the resource type: an agent can infer this is for purchasing Voice Pack minutes. However, the description does not explicitly say when to use it versus alternatives, nor does it state prerequisites beyond the trailing 'Premium and Ultimate' phrase.

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?

With no annotations present, the description must carry the burden. It does disclose two useful traits: the default is to keep, and kept results propagate into the film at update_3d_film time. It omits whether the shot must already be remade, permission requirements, and what is returned.

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 short sentences with the action and default front-loaded, and the downstream consequence second. Nothing redundant or padded.

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 minimal mutation tool with no annotations and no output schema this is only adequate. Preconditions (that a remake must be finished) and the effect on the shot/state after discarding are not spelled out.

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 67%; keep and video_id are already documented in the schema and the description largely restates the keep default. The required 'shot' parameter has no schema description and the description does not clarify how a shot is identified or what happens if it is not a finished remake.

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 pair (keep/discard) and resource (a finished remake of a shot), which is clear enough to distinguish from siblings like fix_3d_shot or list_3d_shots. It doesn't explicitly name those siblings, so it falls short of a 5.

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?

The clause 'Kept remakes go into the film when update_3d_film runs' gives implied context for when this is used, but there is no explicit when-to-use/when-not guidance and no named alternative for the discard path.

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?

No annotations are provided, so the description carries the burden, and 'Reads only' is a valuable safety disclosure plus the 'library and drafts' note tells the agent results include unpublished items. Beyond that it is silent on ordering, volume, or what a 'picture' actually resolves to.

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 short sentences with zero filler, the resource scope stated first and the call triggers immediately after. Every clause 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 a zero-parameter read tool with no output schema and no annotations, the description covers what it returns (characters plus pictures), when to call it, and that it is non-mutating. Only the absence of any hint about result shape or volume keeps it below the top mark.

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 there is no parameter semantics to explain and the baseline of 4 applies. The description correctly adds no parameter-shaped detail, which is the right call.

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 — the user's 3D film characters, drawing from both library and drafts, including their pictures. That scope clause meaningfully separates it from list_characters and list_3d_shots, though it never names those siblings outright, so the agent must infer the 3D-vs-2D split.

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 three concrete call triggers: before casting a film, when the user asks who they have, and when looking up a name. This is real when-to-use guidance rather than implied usage. It stops short of an explicit exclusion or naming the alternative list tool for 2D 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?

With no annotations, the description carries the behavioral burden and usefully states 'Reads only' plus the remake states returned. However, it omits details such as pagination behavior, authentication needs, or whether it excludes unfinished films, so transparency is adequate but not rich.

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 description is front-loaded with what the tool returns, followed by usage guidance and a read-only note. It is appropriately sized with little waste, though the sentence about in-app user interaction is less essential to invocation.

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?

Because there is no output schema, the description does well to enumerate returned fields and remake states. Parameter details are fully covered by the schema, but the description's 'Every shot' phrasing slightly underplays that listing is paginated by from/count.

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 schema already documents from, count, and video_id including defaults and limits. The description adds no additional parameter meaning beyond the schema, so the baseline 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 clearly identifies the resource as shots of a finished 3D film and enumerates the fields returned. It distinguishes itself as a read-only listing via 'Reads only,' though it does not explicitly name siblings such as fix_3d_shot or keep_3d_shot.

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 gives concrete call contexts: when the user wants to fix/change a shot, inspect what a fix did, or check free changes remaining. It does not explicitly state when not to use it or name the alternative mutation tools, leaving some ambiguity for actions that actually modify a shot.

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?

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.

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.

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.

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.

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.

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.

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

Beyond the read-only and idempotent annotations, the description discloses the user-saved scope and the metadata returned for each character. It does not mention ordering or empty-result behavior, but those are modest omissions for a zero-argument listing operation.

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 short sentences front-load the operation and result contents, then provide selection triggers. There is no filler or redundant restatement of the annotations.

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 simple, zero-argument, read-only tool, the description supplies enough scope, output context, and usage guidance to select and invoke it correctly. Explicit routing away from list_3d_characters and list_presenters would make it more complete within this large sibling set.

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?

There are no input parameters, so the description has no parameter-documentation burden. Its saved-character scope is consistent with a parameterless listing and requires no additional invocation details.

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 opening clause gives a specific verb, resource, and scope: listing the user's saved characters. It also states that results include descriptions and style presets, but does not explicitly distinguish this tool from list_3d_characters or list_presenters.

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?

The second sentence provides three concrete triggers: a character is mentioned by name, the user asks who is saved, or a video will star someone. This is strong when-to-use guidance, though it gives no exclusions or sibling alternatives for 3D characters or presenters.

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, so safety is covered; the description adds genuine behavioral context by disclosing sort order ('newest first') and the return payload ('with links and ids'). It stops short of describing truncation or pagination behavior despite a default of 10 and a max of 25.

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?

A single front-loaded sentence with zero filler; the ordering and return shape are packed into one clause without redundancy.

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 simple 2-param read tool with no output schema, the description covers what is returned (links and ids) and in what order, plus annotations cover the safety profile. Only pagination/limit behavior is unaddressed.

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% and both params (type enum, limit) are documented in the schema, so the baseline of 3 applies. The description adds nothing about filtering by type or limit semantics beyond 'newest first', which is ordering rather than parameter meaning.

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 states the resource (what the user has already made) and its ordering/shape, matching the tool name list_creations. It is clear what comes back, but it never differentiates itself from the other list_* siblings (list_characters, list_music, list_presenters) or states the verb explicitly, so an agent must infer the scope from the name.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The agent is left to infer that this is the tool for enumerating user output, with no exclusion criteria or routing advice.

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 'Reads only' is redundant; however 'costs nothing' adds useful cost context not present in annotations. It also discloses non-obvious behavior — topic marks best fits rather than filtering, and mood actually filters — which is meaningful behavioral nuance.

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: what it returns, how to use topic, then when to use it and where to hand results off. The routing information is front-loaded 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?

With no output schema, the description fills that gap by describing the return shape (tracks grouped by mood with listen links) and the marking behavior. Combined with the explicit handoff to create_video, nothing needed to invoke or act on the result 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?

Schema description coverage is 100% and the enum for mood is fully documented, so the schema already carries both parameters. The description restates the filter-vs-mark distinction ('Pass a topic to have the best fits for it marked') without adding format or syntax detail beyond it, matching the baseline for high coverage.

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 states a specific resource (background music tracks a video can use) and its organization (grouped by mood, each with a listening link). The phrase 'background music tracks a video can use' clearly distinguishes it from siblings like list_presenters or 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?

Explicit triggers are given: 'when the user asks for music, wants to choose a track, or asks what moods exist.' It also names the downstream consumer (create_video as music) and what to pass it, so the agent knows the follow-up action.

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 readOnly, idempotent, and non-destructive behavior. The description adds useful context by stating 'costs nothing' and summarizing exactly what saved studio data is returned, though it does not mention pagination or ordering.

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 description is dense but front-loads the resource being listed and the parenthetical definition of a studio is helpful. The long first sentence is slightly heavy, but every clause conveys relevant scope or workflow 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 list tool with annotations and no output schema, the description provides enough context: what is returned, what a studio is, and when to call it. It could be stronger by noting whether all studios are always returned or whether there are limits, but no major gap prevents correct invocation.

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?

This tool has zero parameters, so the baseline is 4. There are no parameter semantics to clarify beyond what the empty schema already communicates.

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 specifies the exact resource: saved podcast studios, including hosts and voices, saved shows, and ready-made rooms. It also distinguishes this list from create_podcast and preview_podcast_studio by naming those siblings and their roles.

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 gives a clear usage context: use before create_podcast when the user wants to reuse a studio or show, or to pick a room. It lacks an explicit 'do not use when' exclusion, but the intended workflow is clear.

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, but the description adds real behavioral context: it is free ('costs nothing'), it surfaces a quota ('how much avatar time is left'), and it is gated to Premium and Ultimate tiers. It does not describe output shape or error behavior, which keeps it short of a 5.

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-loaded with the core verb+resource and the when-to-call rule in the first two sentences. The later sentence about in-app panels and website Avatar Packs is context rather than instruction, which is slightly more than strictly required, but it is not bloated.

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 parameters and no output schema, the description carries the return content ('presenters, and how much avatar time is left') implicitly and covers prerequisites, cost, and tier gating, so an agent can call it correctly without more information.

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 and no description-side parameter guidance is needed. Nothing here 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 and resource: it lists the user's AI presenters and remaining avatar time. It also disambiguates from neighbors like list_characters, make_presenter, and draw_presenter by naming the creation path explicitly ('New presenters are made right here with draw_presenter').

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 explicit trigger conditions: 'Call it before putting a presenter in a video, or when the user asks who their presenters are or how much avatar time they have.' It also routes related work to siblings (draw_presenter for creation, Avatar Pack for top-ups).

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 "It reads nothing and costs nothing" largely restates them. The genuinely additive disclosures are environmental behavior (form panel where panels exist, full text listing elsewhere) and "nothing is made until the user presses it", which tells the agent the call itself has no side effect on the user's project. Beyond that it says nothing about response shape, size of the returned catalogue, or latency for the large voice catalogue.

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?

It is front-loaded with the key framing sentence, but the body is a semicolon-chained run-on that mixes panel mode, prefill guidance, sibling ordering and the returned catalogue into a single wall of text. The closing enumeration of what create_video can be set to partially repeats the enumeration in the opening sentence.

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 13-parameter, zero-required, side-effect-free options tool with no output schema, the description covers both execution modes, the trigger conditions, the prefill contract and the plan-filtering caveat. What is missing is any sense of what the text-mode answer looks like or how large it is, which matters when the agent must decide whether to surface it inline.

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% and every one of the 13 parameters already carries a "Prefill: ..." or filter description, so the baseline is 3. The description adds only the general framing that supplied values prefill the form and that the catalogue is filtered to the user's plan limits, without clarifying semantics for any individual field such as how section interacts with the prefill parameters.

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 VIDEO MAKER PANEL" plus a concrete enumeration of what the form contains (format, topic, length, style, voice, captions, music, effects, recurring character, AI presenter) states a specific resource and scope, and the description explicitly positions itself against create_video ("everything create_video can be set to"). It also discloses the dual mode (panel form vs. text list) so the agent knows what it is actually invoking.

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 gives positive triggers ("when the user asks to open the video maker, wants to see or choose the options, or asks for 'all options'"; "when they ask what voices or styles exist, or when you are about to guess at a value") and an explicit negative/alternative rule ("Do not retype the options as a table when the panel is shown"). It also prescribes the ordering relative to a sibling: call this before create_video when the user wants to choose.

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 establish read-only, idempotent, non-destructive behavior, and the description adds useful operational context: it costs nothing, long videos require paging with `from`, and picture links can be downloaded. That is meaningful behavioral information beyond the annotations.

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 definition is front-loaded with what the tool returns, then usage guidance, recommendation advice, pagination, and cost/safety notes. Despite being fairly dense, each sentence contributes useful information without repetition.

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?

No output schema exists, so the description carries the burden of explaining returned content, and it does so clearly: numbered scenes, narration, picture links, and remaining animated scene count. Combined with annotations and schema, an agent has enough information to invoke it 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?

Schema description coverage is 100%, so all three parameters are already well documented. The description mentions paging with `from`, but does not add format, default, or edge-case semantics beyond what the schema provides; baseline 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 states a specific verb and resource: listing scenes of one of the user's finished videos, including scene numbers, narration, pictures, and remaining animated scenes. It clearly distinguishes this listing tool from siblings such as check_video and list_creations by describing exactly what is returned.

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 gives explicit trigger conditions: when the user wants to animate or edit scenes, and it names the relevant downstream tools (regenerate_scene_image, set_scene_image, update_video). It also explains pagination with `from` and even when to offer scene recommendations.

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?

With no annotations, the description carries the burden and does disclose non-obvious behavior: it consumes one image from the monthly allowance, saves the result to the user's library, and pulls hosts from the podcast's studio picture rather than from arbitrary characters. It does not cover failure modes (e.g. what happens when no podcast exists or the studio is missing), which keeps it short of a 5.

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?

It is long but front-loaded: purpose and sibling routing come first, then default look, then the custom path, then cost/persistence. The only redundancy is the repeated reminder that 'the hosts still come from the podcast,' which slightly pads the middle paragraph.

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, and the description compensates by saying what is produced (a thumbnail), where it goes (the user's library), and what it costs (one image against the monthly allowance). Combined with the full schema coverage and default/custom routing, an agent has everything needed to invoke it 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning on top: it explains that hosts_sides is the default, that custom requires a custom_prompt describing the look, and gives authoring guidance for headline ('write it yourself from the episode topic, 2 to 6 punchy words, the hook rather than the full title'). The badge and tagline roles are also illustrated with examples.

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 states a specific verb and resource ('Make a YouTube thumbnail for one of the user's Animated Podcasts') and immediately names the sibling it should not be confused with ('Use this, not generate_image, whenever the thumbnail is for a podcast'). An agent can distinguish it from generate_image and preview_single_image without opening any schema.

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 gives an explicit when-to-use rule with an alternative ('use this, not generate_image, whenever the thumbnail is for a podcast'), then states the default behavior ('Give this look unless the user asks for something else') and the escape hatch (layout custom plus custom_prompt). Both the selection and the fallback are spelled out.

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?

With no annotations, the description carries the full burden and does so well: it discloses the cost ('SPENDS 30 seconds of the user's avatar time (not video minutes)'), the latency ('takes a few minutes to get ready'), and quota constraints (max 5 presenters, daily limit on new ones). It even clarifies the unit confusion between avatar time and video minutes, which an agent could not infer.

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?

Four short sentences, no padding, and the required precondition plus cost are front-loaded or immediately adjacent to the action. Every sentence contributes a distinct fact (purpose, precondition, cost/latency, quota).

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 one-parameter async creation tool with no output schema, the description covers everything needed: precondition, cost, expected latency, how to check status, and limits on how many can exist. Nothing an agent needs to call it correctly or set user expectations 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?

Schema description coverage is 100%, and the single 'name' parameter is already documented in the schema with length limits and an example. The description only restates that the presenter is saved 'under a name,' adding no syntax or format detail beyond the structured field, so baseline 3 applies.

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 ('turn the approved draft picture into a real talking AI presenter') plus the durable effect ('save it to the user's account under a name'). This clearly separates it from the sibling draw_presenter (which makes the draft) and list_presenters (which reads them back).

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 an explicit gate: 'Only call this once the user has seen the picture and said yes to it,' which tells the agent exactly when not to call it. It also routes the agent to check_presenter for readiness polling, giving a concrete alternative for the waiting period.

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?

With no annotations, the description carries the full behavioral burden. It discloses the library limit (up to 20), the purpose (future films), and a consent requirement ('only on the user's own request'), which are useful traits. Yet it omits critical details for a deletion tool: whether delete is irreversible, what happens when the library is full, and whether any confirmation or error response is returned.

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 description is a single, front-loaded sentence with a semicolon connecting the two action behaviors, followed by a short constraint sentence. Every clause earns its place; there is no redundant or vague language. It could be slightly more structured (e.g., bullet the actions) but remains efficient.

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 simple two-parameter tool with no annotations and no output schema, the description covers both actions and key limits. However, it does not explain what a 'drafted' character is, what the tool returns on success or failure, or the consequences of deletion. Given the lack of structured behavioral fields, more context would improve completeness.

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 50% – only the 'name' parameter is documented in the schema. The description compensates for the undocumented 'action' enum by explaining both values ('save keeps...; delete removes one'), which adds meaningful semantics beyond the raw enum. The 'name' parameter remains as simple as its schema description, so the overall value is adequate but not rich.

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 states specific verbs (save, delete) and the resource (a drafted 3D character in the user's 3D library) with a clear scope (up to 20, for future films). However, it does not explicitly differentiate this tool from siblings like save_character or manage_character, leaving some ambiguity for an agent choosing among similar operations.

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?

The phrase 'Only on the user's own request' provides a clear usage constraint, indicating this should not be invoked autonomously. However, there is no guidance on when to use this tool versus alternatives such as save_character or manage_character, nor any prerequisites for the save or delete actions.

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?

No annotations exist, so the description carries the full burden. It says delete is one of the two actions but never states whether deletion is permanent, whether characters already used in created videos are affected, or whether any confirmation/undo exists — critical omissions for a destructive operation.

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?

One tight sentence with the verb and resource front-loaded, followed by the scope/consent constraint. No filler, though the single sentence does double duty as purpose and caveat rather than being structured into distinct guidance.

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 three-parameter tool containing an irreversible delete, with no annotations and no output schema, the description omits outcome behavior, side effects on existing videos, and failure modes. The gap is material at this complexity level.

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 only 33%: `name` has no description anywhere, and the description doesn't clarify whether it is an exact identifier, a display name, or what happens on a mismatch. Only `new_name` ("rename only.") is documented, and that comes from the schema, not the description.

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 specific verbs (rename, delete) and a specific resource (the user's saved characters), plus a disambiguating qualifier — "the regular ones used by create_video" — that separates it from manage_3d_character and the change_* siblings. An agent can pick this tool without opening any schema.

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?

"Only on the user's own request" gives a useful consent gate, and the parenthetical implies scope versus 3D characters. But it never explicitly routes the agent away from manage_3d_character, change_character, or change_presenter, so alternative selection is left to inference.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that details are generated once per script version, cached and reused, and that refresh overwrites them, plus that the call is free. It omits auth requirements, whether the cached values can go stale, and any failure modes, leaving meaningful gaps for a generation tool.

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 tight sentences that front-load the output content before the caching/cost note. No filler, though the parenthetical about chapters is the only structural elaboration and the phrasing is slightly elliptical.

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 appropriately names the returned fields (title, description with chapters, tags). It covers the caching model but says nothing about response structure details or edge cases like a missing/incomplete podcast, leaving it adequate rather than complete.

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 both parameters are already documented in the schema. The description's 'refresh writes new ones' and cached-value framing adds minor reinforcing context but no syntax or default detail beyond what the schema provides. This is the expected baseline when the schema does the heavy lifting.

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 identifies the specific resource (YouTube title, description with audio-timed chapters, and tags for a finished Animated Podcast) and notes it mirrors what the site displays. The verb is implicit rather than stated, but an agent can tell what the tool returns without opening the schema. It does not differentiate itself from siblings like get_podcast or edit_podcast.

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?

The line 'Made once per version of the script and then reused; refresh writes new ones' implies the caching/regeneration model and hints at when a caller might want refresh=true. However, there is no explicit when-to-use guidance or named alternative among siblings such as get_podcast. Usage is inferable but not stated.

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?

No annotations exist, but the description carries the full burden well: it discloses that the no-arg call posts nothing, that posting makes the video public under the user's name, that a URL cannot be passed, that accounts must be connected via the website, that posting spends no minutes, and that the feature requires Premium/Ultimate.

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?

Dense but front-loaded: the call-with-no-arguments rule and the public-posting warning appear early, and each sentence introduces a distinct constraint or step. No filler or restatement of the title.

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, the description still explains what the no-arg call returns (connected accounts plus a numbered list of recent videos with ids) and points to check_social_post for delivery status. Nothing an agent needs in order to invoke it safely 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?

Schema coverage is 100%, so a 3 is the floor. The description adds genuine meaning beyond the schema by explaining where item_id comes from (this tool's no-arg list, check_video, or list_creations) and by tying title/caption/YouTube privacy to the confirmation step with the user.

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: publishing one of the user's finished videos to named connected platforms, now or scheduled. It is clearly separable from the sibling check_social_post (status checking) and list_creations (enumeration) without needing to open the schema.

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 prescribes the two-phase workflow: call with no arguments first to list accounts and videos, confirm with the user, then call again with item_id and details. It also names check_social_post as the follow-up alternative and warns not to assume the newest video is intended.

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?

With no annotations, the description carries the full burden and does well: it states cost ('Spends no video minutes'), a rate limit ('a handful of new pictures per hour'), plan gating ('Premium and Ultimate'), a technical constraint (pasted chat images cannot reach the tool; need a public link), and a consent rule for photo_url. It does not explain iteration limits or whether regenerating counts against the same quota.

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-loaded with what the artifact is, then the confirm-then-create workflow, then input rules, then constraints. Dense and mostly waste-free, though the host-design and set-description sentences overlap somewhat with what the schema already documents.

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?

No output schema exists, and the description implies the return is a picture with an image_url referenced later by create_podcast, but never states the return shape explicitly (URL vs. displayed image, whether it persists). Otherwise complete for a nested, 5-parameter generation tool with zero annotations.

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 the baseline is 3; the description adds real meaning on top by explaining how inputs combine (hosts are self-designed via name/gender/look or photo link; the set derives from topic + setting, a ready-made room, or a user empty-room link) and the default behavior when room/setting are omitted. It also disambiguates image inputs (only public https links work).

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: 'Create the studio picture for an Animated Podcast,' then describes the composition (two cartoon hosts at a desk, one each side, held on screen while they talk). This clearly separates it from create_podcast (which consumes the result) and list_podcast_studios (which supplies rooms).

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?

Explicit when-to-use: generate a preview, show it, let the user confirm or request another, only then call create_podcast with its image_url. Explicit when-not-to-use: 'If the user already has a finished studio picture, skip this and pass its link to create_podcast as studio_image_url.' Alternatives (list_podcast_studios, user's own room link) are named with their conditions.

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?

With no annotations, the description carries the behavioral burden and does well: it states that this creates no job, spends no video minutes, and does not touch the daily limit, so redoing it is safe. It also mentions the returned image_url and the need to reuse the same face_side, though it does not describe the full response shape.

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 description is four compact sentences, front-loads the purpose, and includes only actionable guidance: composition, confirmation flow, cost profile, and next-step linkage. Every sentence 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 a six-parameter tool with no annotations and no output schema, the description covers what is generated, how to use the result, the cost/side-effect profile, and the key return value. The input schema already supplies rich parameter details, so the description needs no further expansion.

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 already 100%, so the schema documents all six parameters. The description still adds practical meaning by tying face_side to create_video and warning to pass the SAME face_side, which is workflow semantics beyond the schema.

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 states a specific verb and resource: generating the one held image for a Single Scene video, and even describes the intended composition. It clearly separates this preview image from the later create_video step, so an agent knows exactly what this tool produces.

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 gives clear usage context: show the result to the user for confirmation or another attempt before calling create_video. It does not explicitly compare against alternatives such as generate_image, but the workflow condition is unambiguous.

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?

With no annotations supplied, the description carries the full burden and does so: it discloses that the new picture is not live until update_video re-renders it, that regeneration is quota-metered (10 free, then image allowance/Image Pack), and that Free plan users are blocked. These are exactly the behavioral facts an agent cannot infer from the schema.

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?

Purpose, sequencing rule and a clearly labelled COST block, all front-loaded with no filler. The cost paragraph is dense (three plan tiers in one sentence) and could be tightened, but every clause carries decision-relevant 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 3-parameter mutation tool with no output schema, the description covers what changes (scene's picture is replaced, saved immediately), what does not (the rendered video), the cost gate, and the excluded video types. Nothing material is missing for correct invocation.

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 the baseline is 3; however the description adds real meaning by framing 'prompt' as optional and user-worded and by noting that omitting it regenerates the scene's own picture fresh, which clarifies the default behavior beyond the property description. The scene/video_id pairing is also contextualized within the multi-scene workflow.

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 (generate a new picture for one scene) plus the scope constraint ('finished multi scene or whiteboard video'). Explicitly rules out Single Scene videos, podcasts and 3D films, and implicitly distinguishes itself from set_scene_image and update_video, both of which are named.

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 an explicit ordering rule ('make every picture change first and then call update_video once'), names the free alternative (set_scene_image with the user's own picture), and states the plan-based eligibility condition. The agent knows both when to call it and when to route elsewhere.

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?

With no annotations, the description carries the burden and does well: it discloses the quota (up to 10), how the photo is processed ('saved as it is, padded onto white'), and the draft default. It does not say what happens if the name already exists or whether saving costs credits, which are the remaining behavioral gaps.

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 sentences, front-loaded with the core action and the source options, with no filler. The middle parenthetical about photo handling is dense but earner-placed; minor cost is that it packs two ideas into one long clause.

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?

Covers the full lifecycle an agent needs: where the image comes from, the quota, and how the saved name is reused in create_video. Missing only edge cases (duplicate-name handling, overwrite vs error) for a mutation tool with no annotations or 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 baseline is 3, but the description adds the relationships the schema does not: image_url is specifically for a non-latest draft, photo_url substitutes for a generated picture, and omitting both means the current draft. That mode-selection logic is genuine added meaning.

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 ('Save a character to the user's library under a name') and immediately enumerates the three sources, which distinguishes it from siblings like draw_character, create_character, and change_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?

Explicitly tells the agent which input selects which mode: no image/photo params means the current draft, image_url picks a specific non-latest draft, photo_url saves the user's own photo. It also states the 10-character quota and the downstream step (pass the name as `character` to create_video).

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?

With no annotations, the description carries the full behavioral burden and does well: it discloses quota requirements, the two-hour sample expiration, and the user-selection prerequisite. It does not describe success/failure behavior or whether saving consumes resources irreversibly, so it stops short of complete transparency.

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 description is tightly written and front-loads the action before listing constraints. Every sentence adds useful information about selection, prerequisites, or timing.

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 mutation tool with no annotations and no output schema, the description covers the most important operational context: prerequisites, expiration, and when the save is appropriate. It is slightly incomplete because it does not say what is returned or what happens on failure, but the core context is strong.

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 all four parameters are already documented. The description reinforces that sample is 1, 2, or 3 and that preview_id is an alternative, but adds little beyond what the schema already provides.

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 states a specific verb and resource: keep one sample from the last design_voice as the user's own voice under a name. It clearly distinguishes this from design_voice, which creates the samples, and delete_designed_voice, which removes a saved voice.

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 gives clear usage context: this should be used only after the user has listened and chosen a sample, and it requires a free designed-voice slot plus at least 1 Voice Pack minute. It references design_voice as the source but does not explicitly contrast with other related tools or say when not to use this one.

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?

With no annotations at all, the description carries full burden and does disclose genuinely useful traits: a hard quota ('up to 30 saved studios'), zero cost, and that delete is destructive and keyed on name. It omits what happens on a name collision (overwrite vs error) and any permission requirements, which is the remaining gap for a mutation tool.

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, all front-loaded and substantive: the core action, the quota, and the cost. Nothing is padding, though packing save-and-delete into one clause makes the lead sentence denser than ideal.

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 tool with no output schema, nested host objects, and no annotations, the description covers the essential context: quota, cost, the reuse path, and delete semantics. Missing only collision/overwrite behavior and the fact that only 'name' is required (hosts and image_url are optional save-time data).

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 schema already documents all five parameters, including the delete flag and the image_url source. The description adds only the framing that a studio consists of two hosts with names, looks and voices, which lightly reinforces the host_a/host_b structure but adds no syntax or format detail.

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 states a concrete verb+resource (save a podcast studio picture with its two hosts under a name) and extends it to the delete mode, which an agent could not have guessed from the name 'save_podcast_studio'. It is distinguishable from siblings like preview_podcast_studio and list_podcast_studios, though the dual save/delete behavior makes the name slightly misleading.

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 explains the downstream purpose ('reused with create_podcast studio') and that the delete flag removes a saved studio, which implies usage. However, it never says when to prefer this tool over siblings such as preview_podcast_studio or list_podcast_studios, and gives no explicit exclusions or prerequisites.

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?

With no annotations, the description carries the full behavioral burden and does so: the zero-argument call is non-destructive ('uploads nothing'), uploads consume no video minutes or image allowance, the tool returns an upload id immediately rather than the final link, and the unconnected-Drive case produces an explanatory error. It also adds a prompt-injection guard, which no annotation or schema could convey.

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 purpose and trigger phrases are front-loaded, and every paragraph carries functional information: workflow, safety, cost, and follow-up. It is longer than typical, but the length is justified by the multi-step interaction and the safety constraint, with little 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?

There is no output schema and no annotations, so the description must cover return values and side effects, and it does: it describes the no-arg list format, the immediate upload id, and the hand-off to check_drive_upload. The unconnected-account error path is also covered, leaving no obvious gap for correct invocation.

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 the baseline is 3, but the description goes further by explaining the dual-mode behavior of item_id (omitting it returns a candidate list) and citing additional valid sources for the id (check_video, list_creations). That is genuine meaning beyond the schema's field description.

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 states a specific verb and resource ('Upload one of the user's own finished videos or images') and names the destination ('to the Google Drive connected to their Digital Maker AI account'). It is immediately distinguishable from siblings like create_video or generate_image, which produce assets rather than transfer them.

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 gives explicit trigger phrases ('save that to my Drive'), an explicit two-step workflow (call with no arguments first, show the list, then call again with item_id), and explicit prohibitions ('Do not skip this step', 'do not assume the newest item is the one they want'). It also names the follow-up tool check_drive_upload, so the agent knows where the flow continues.

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 mark it read-only and idempotent, yet the description adds genuinely new behavioral context: reads are cached not live, coverage is partial, every result carries an age that must be relayed to the user, and on a miss the agent should route to the website rather than fabricate numbers. It also warns against misinterpreting the 0-100 values as search volumes. This is well beyond what annotations provide.

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?

It is long, but front-loaded with purpose before caveats, and each block (usage, cache warning, metric semantics) carries distinct, non-redundant information. Slightly over-extended for a three-param read tool, but nothing is padding.

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, the description correctly compensates by explaining what the returned interest values mean (Google Trends relative scores 0-100, self-relative, not volumes) and the cached-age caveat. An agent has everything needed to call it and interpret results honestly.

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% and all three parameters are already documented in-schema (including the WW default and the include enum values), so the description adds no per-parameter syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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 a specific verb and resource ('Search interest over time, related searches and video ideas for a keyword or niche') and scopes it to a named data source (Digital Maker AI's Trend Finder cache). An agent can distinguish it from siblings like create_video or find_faceless_channels 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly enumerates the triggering questions ('is a niche growing or dying', 'what people are searching around a topic', 'which of several niches looks strongest', 'what is trending right now') and recommends calling it before create_video. Both when-to-use and the pre-condition for a sibling are stated.

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?

With no annotations, the description carries the full burden and does well: it discloses cost ('Free and unlimited'), input constraints (public HTTPS URL, JPG/PNG/WebP, up to 12 MB), a consent rule, and the crucial fact that the change is not live until update_video runs. It stops short of saying whether the existing scene image is replaced, whether failures are recoverable, or what the call returns.

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-loaded with the action and scope, then layered with constraints in descending order of importance. Every clause carries a distinct operational fact — cost, input format, outcome timing, consent — with no padding.

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 3-parameter mutation tool with no annotations and no output schema, the description covers prerequisites, input restrictions, the two-step commit requirement, and a safety constraint. What an agent needs in order to call this correctly is present.

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 67%, and the description compensates by pinning down image_url format constraints (public HTTPS, JPG/PNG/WebP, 12 MB limit) that go well beyond the terse schema text, and by pointing scene numbering at list_video_scenes. video_id remains entirely undocumented in both places, which keeps this below the top score.

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 ('Put the user's own picture on one scene') plus the scope of videos it applies to (finished multi-scene or whiteboard). It explicitly names regenerate_scene_image as the neighboring alternative, so an agent can distinguish it without opening schemas.

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 explicit when-to-use conditions (finished video, one scene, user-supplied picture) and when-not conditions (chat-pasted images cannot reach this tool, only use a picture the user has asked for). It also names the necessary follow-up step, update_video, and the sibling it complements, regenerate_scene_image.

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?

With no annotations, the description carries the full burden and does disclose the key traits: it is a preview/suggestion step rather than a creation step, and it 'costs nothing' (no credits consumed). What it does not state explicitly is that no character records are persisted and that output is a set of looks the user may later approve — both are strongly implied but not spelled out.

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-loaded with the purpose, then the trigger, then the cost note and follow-on options — a sensible order with no filler. It runs slightly long with the trailing clause about the film designing its own cast, but that clause earns its place by preventing a wrong sequencing choice.

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, zero-annotation, no-output-schema tool, the description covers purpose, sequencing, cost, and follow-on paths, which is close to what an agent needs. The remaining gap is return shape — it never says the caller receives a list of named characters with looks — though 'each with a fitting look' hints at it.

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 all eight parameters are already documented, including the preset enum default and the own-story field set. The description's only added meaning is the library-versus-own-story framing, which the schema mostly covers on its own. Baseline 3 applies.

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 concrete framing ('Who is in a 3D film') and names the exact resource produced: main characters of a library or own story, each with a look for the chosen preset. It also distinguishes itself from the related siblings by naming create_3d_character and create_3d_film, so the agent can place it in the workflow without opening a schema.

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 an explicit trigger ('when the user wants to see or approve the characters, or asks who is in the story') plus the sequencing rule ('Call it before create_3d_character'). It also covers the alternative path of skipping straight to create_3d_film and letting the film design its own cast, which is exactly the when-not guidance an agent needs.

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?

With no annotations, the description carries the behavioral burden and does real work: it discloses a hard quota (10 updates per film), expected latency (a few minutes to render), a plan restriction (music is Premium and Ultimate), and that previously kept remakes are preserved in the re-render. It stops short of saying whether prior captions/music are replaced or whether an update is consumed on failure — material for a mutation with a finite quota.

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 action and its scope land in the first clause, followed by the UI anchor, then parameter clarifications, then plan/quota/latency constraints. Dense but every clause carries information an agent needs; nothing is padding.

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 6-parameter, zero-required mutation with no output schema and no annotations, the description supplies the missing context that matters: preconditions, plan gating, quota, and render time. It is nearly sufficient, though it omits what state is reset in the re-render (existing captions/music) and any hint about what the call returns (likely a job id for check_video).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.