Clip Studio MCP

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

The description says to 'Arm' an inventory item, which implies a state-changing mutation, while annotations declare readOnlyHint=true. This directly contradicts the annotation and is comparable to a 'create' tool marked read-only. No other behavioral context is provided.

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 two short sentences with no filler. The core action and purpose are front-loaded, and the itemIndex clarification is useful and brief.

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?

Although the schema and output schema fully document parameters, the description omits usage context and, more importantly, the readOnlyHint contradiction makes the tool's actual behavioral contract unclear. An agent could be misled into thinking the call has no side effects.

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 per baseline the description need not add much. The description repeats 'itemIndex is 0-based' which the schema already states, and adds no new semantic information beyond what the schema 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 names a specific verb ('Arm'), a precise resource ('Last Frame inventory item'), and the purpose ('for the next move'), making the tool's function immediately clear. It is distinguishable from siblings like choose_last_frame or start_last_frame because no other sibling describes arming an inventory item.

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 gives no guidance on when to use this tool relative to alternatives, no sequence context, and no prerequisites. While the schema mentions runId comes from start_last_frame, the description itself does not explain where this tool fits in the Last Frame 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?

The description discloses the important side effect that the tool 'uses this month's generation allowance' and that it films, which is beyond what the annotations provide. Annotations declare non-read-only and non-destructive; no contradiction exists.

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 filler. The main action is front-loaded and the cost/side-effect follows naturally in the second 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 cost-incurring action with only two well-documented parameters, the description gives the essential workflow context and side-effect. It does not spell out the run lifecycle prerequisites, but the schema reference to start_last_frame and the presence of an output schema make the tool usable.

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 documented (runId origin and 0-based optionIndex). The description adds little parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource combination ('Pick a numbered Last Frame option') and states the concrete effect ('films the next shot'). It is clear about what the tool does, though it does not explicitly name sibling tools or contrast itself with start/type/end Last Frame 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?

Usage context is implied rather than spelled out: picking a numbered option and filming the next shot suggests it is called after a run has produced options, and the runId parameter references start_last_frame. The description does not state explicit conditions, prerequisites, or alternatives such as quote_last_frame or end_last_frame_clip.

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?

The description's operative verb 'Mark ... ready' is a state-changing write, yet the annotations declare readOnlyHint=true. An agent relying on the annotation would assume this call has no side effects, which is the opposite of what finalizing an upload does. This is a direct description/annotation conflict, so the rubric's score of 1 applies.

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, zero filler, with the action front-loaded before the return values. 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 one-parameter finalization call with an output schema present, the description covers the essential action and even summarizes the return (asset id, width, height), which is not required. The remaining gap is the unstated upload prerequisite and the mis-signalled side-effect profile, not missing return-value documentation.

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 is a single parameter with 100% schema description coverage, and the schema already explains that assetId comes from presign_generation_asset. The description adds nothing about the parameter, so the baseline of 3 for fully documented schemas is correct.

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 concrete verb+resource ('Mark a source image or MP4 upload ready') and scopes it to three destination labs (Video Lab, Image Lab, Paint Lab), so an agent knows exactly what state transition it performs. It stops short of naming the sibling it pairs with (presign_generation_asset) in the description text itself, so it is clear but not fully sibling-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?

'Mark ... ready' implies the tool belongs at the end of an upload flow, but the description never states the prerequisite explicitly (that the file must already be uploaded via presign_generation_asset) or when not to call it. The prerequisite only surfaces in the schema's assetId description, so usage is implied rather than 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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the description doesn't need to restate those. The description adds valuable behavioral context: it bills under the same plan as the site, it quotes remaining first when quoteId is omitted, it generates an idempotencyKey when omitted, and it explicitly says not to wait for the full render. This goes beyond the annotations and helps the agent understand side effects and async behavior.

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-loaded. The first sentence states the action and scope. The following sentences cover billing, prerequisites, optional parameters, and async behavior without redundancy. 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?

Given the tool's complexity (async submit-and-poll, optional quote, idempotency), the description covers the key operational details: prerequisite, billing, quote behavior, idempotency, and polling. The output schema exists, so return values don't need to be described. The sibling list shows related tools, and the description clearly differentiates this from quote_character_film and generate_character_film.

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 three parameters. The description adds meaning by explaining the relationship between quoteId and the tool's quoting behavior, and by clarifying that idempotencyKey is generated when omitted. It also ties projectId to the prerequisite that the opening must be completed. This is meaningful added value 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 ('Continue') and resource ('Character Film'), and clarifies the exact scope: 'film the remaining blocks after the opening is completed.' This distinguishes it from related tools like generate_character_film and quote_character_film. The title is null, but the description itself 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?

The description explicitly states when to use it: after the opening is completed, and it names the prerequisite ('Requires a completed opening'). It also explains the optional quoteId behavior and directs the agent to poll get_character_film. It even gives a workflow instruction: 'Submit and poll — do not wait here for the full render.' This is strong usage 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?

Annotations declare readOnlyHint=true, but the description says 'Create a Stripe Checkout URL' and describes the operation as creating a checkout artifact. This mirrors the create_record contradiction: an operation described as creating something cannot be read-only. The additional pricing guidance and 'Does not take card data' are useful but do not resolve the annotation conflict.

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-loaded with the core purpose, then adds pricing guardrails and return behavior. It repeats some price guidance already present in the schema, which is slightly redundant, but every sentence serves a real decision-making purpose.

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 essential context: purpose, HTTP 402 trigger, acceptable prices, forbidden prices, return value, and the fact that card data is not collected. The output schema exists, so return-type detail is available separately. The main gap is the unresolved read-only annotation contradiction.

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 path, source, and priceId. The description adds domain guidance on which priceId values are preferred or forbidden, but this largely repeats the schema's own parameter description rather than adding substantial new semantic 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 action ('Create a Stripe Checkout URL') and resource ('for a plan'). This clearly distinguishes it from the generate/quote/list siblings and makes the tool's role immediately understandable.

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 triggering context ('After HTTP 402'), names the preferred price IDs, and explicitly forbids the Content Creator prices as wall or post-value offers. It also points to get_account.offerCheckout as the source of valid offers, which routes the agent to the correct supporting 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?

Annotation Contradiction: The description states 'Create' which implies a write/mutation operation, while annotations declare readOnlyHint=true. This is a fundamental inconsistency that leaves the agent unable to trust either the description or 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 description is a single, front-loaded sentence with no filler words. It earns its place by stating the core action, though it could be slightly more informative without losing conciseness.

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?

The tool has only one parameter and an output schema, so the basic shape is simple. However, the contradiction between the 'Create' description and readOnlyHint annotation leaves the behavioral contract ambiguous, which is a significant completeness 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 description coverage is 100%, and the sole parameter 'description' is already documented in the schema. The tool description adds no meaningful semantic detail beyond what the schema provides, so the baseline score 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?

The description clearly states a specific verb ('Create'), a concrete resource ('custom Last Frame world'), and the input basis ('from a description'). This distinguishes it from sibling tools like list_last_frame_worlds or start_last_frame.

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?

No guidance is given about when to use this tool versus alternatives such as list_last_frame_worlds, choose_last_frame, or start_last_frame. The verb 'Create' implies some usage context, but no explicit conditions, exclusions, or alternative routing are provided.

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 declare readOnlyHint=true, but the description says 'Start a Story project,' which implies a creation/write operation. This directly contradicts the read-only annotation and gives an agent conflicting safety signals. Additional behavioral notes about not writing a part or film cannot compensate for this contradiction.

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-load the core action, state an important exclusion, and provide the next steps. There is no filler or redundant explanation.

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?

The description covers the initiation semantics and downstream workflow well, and an output schema exists so return values do not need prose. It loses a point because the read-only annotation conflict is unresolved and no guidance distinguishes this from estimate_storyboard or create_topic_short_story, though the latter may be out of scope.

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 each parameter already has detailed descriptions, including enums and defaults. The tool description adds workflow context about pasting the whole story and continuing later, but most parameter meaning is already handled by the schema, so a 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 uses a specific verb and resource ('Start a Story project') and clearly states what it does not do ('Does not write a part or film'). It also names the next tools in the workflow, which distinguishes it from generate_storyboard_part and render_storyboard.

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 explicitly gives the workflow: call this with a full story or script, then generate_storyboard_part, then render_storyboard. It even clarifies the branching decision between generating the first part and continuing on an existing projectId.

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?

The description says the tool starts/creates a series, a state-mutating operation, while annotations declare readOnlyHint=true and destructiveHint=false. This is a direct contradiction that would mislead an agent into treating a write as a safe read. The one useful disclosure ("Free: each episode is quoted and generated like any short") does not offset the conflict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action and example, then the follow-up tool, then billing. No filler, though the closing "Free" sentence is somewhat tangential.

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?

An output schema exists so return values need not be explained, and inputs are fully schema-documented. But the annotation contradiction plus the absence of any prerequisite guidance (e.g. requiring a pre-saved style) leaves the definition not fully trustworthy for a mutating creator tool.

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 name, niche, and styleId are already documented, including that styleId comes from save_topic_short_style or list_topic_short_styles. The description repeats the two main concepts (saved style, niche) without adding format or constraint detail beyond the schema, so the 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 ("Start a Topic Short series") plus its inputs (a saved style and a niche) with a concrete example. It clearly is not a generation tool, but it doesn't sharply differentiate itself from nearby siblings like create_topic_short_story or generate_topic_short beyond the word "series."

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 routes the agent forward by naming queue_topic_short_episodes for adding episodes, which is useful follow-up guidance. However, it gives no when-to-use versus alternatives (e.g. create_topic_short_story) and no exclusions or prerequisites such as needing an existing styleId.

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=true and destructiveHint=false, and the description usefully reinforces this with 'Does not render.' Beyond that it discloses real behavior: the fail-open chain for Pexels misses, the 2-minute AI-shot deadline fallback to stock, and the never-reuse rule. Mostly about the produced artifact's internals rather than call semantics, but still substantial added context.

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 key purpose, but the body is a dense wall of text whose final sentence crams many unrelated argument behaviors ('Does not render. Choose any storyFormat...; edit the returned plan...') into one run-on paragraph. Information density is high, but the lack of structure and heavy redundancy with the schema hurt readability.

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 24-parameter, nested-schema tool with an output schema present, the description covers formats, language limits, sourcing, seeding, and rendering behavior adequately. Return values need not be explained given the output schema, but the description could route more clearly between the plan/preview/quote/generate lifecycle.

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 24 params and the baseline is 3. The description adds some cross-parameter meaning (sourceUrl/Urls/Text imply sourced, storyFormat wins over format, hookTemplateId seeds the topic), but much is restated and the nested storyPlan semantics largely duplicate 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 first clause states a specific verb and resource: 'Preview a Topic Short story with hook, setup, reveal, and payoff beats, narration, and English Pexels search terms.' It enumerates the concrete outputs (beats, narration, search terms) and implicitly separates itself from render/generate siblings by noting it 'Does not render.'

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 context: 'edit the returned plan before quoting and generating,' and conditionals for seeded topics ('Required unless hookTemplateId seeds it or seriesEpisodeId supplies it. An explicit topic wins'). However it never states when NOT to use this vs. generate_topic_short or edit_topic_short explicitly, so exclusions are 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?

The description announces a destructive operation ('Delete') while the annotations declare readOnlyHint=true and destructiveHint=false. That is a direct, serious inconsistency between description and structured metadata. Although the description does add genuine side-effect context (no charge or refund, existing results preserved), the contradiction with the annotations forces the floor score.

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, zero filler: scope first, then precondition, then cost behavior, then retention behavior. Each sentence carries distinct, 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 one-parameter delete with an output schema, the description covers preconditions, billing impact, and what is retained, which is close to complete. The one thing it fails to resolve is the conflict with its own annotations, which is why it is not a 5.

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 styleId parameter is already documented in the schema, including where to obtain the id. The description adds no format or sourcing detail beyond that, so the 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?

Specific verb+resource ('Delete ... trained Paint Lab styles') with an explicit scope qualifier ('ready or failed'). An agent can distinguish it immediately from the nearby siblings get_paint_lab_trained_style, rename_paint_lab_trained_style, and train_paint_lab_style.

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 clear precondition ('A style that is still training cannot be deleted yet'), which tells the agent when this call will fail. It does not explicitly route to a sibling (e.g., list_paint_lab_trained_styles to find a deletable id), so it stops short of full when/when-not/alternatives 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?

Annotations only cover the safety profile (readOnlyHint false, destructiveHint false, openWorldHint false), and the description adds substantial behavior beyond that: HTTP 402 with requiredCredits/availableCredits on shortfall, each edit creating a new version that must be polled via get_topic_short, published pages staying pinned until publish_generation, restoration happening on the clip page, and a 20-free-edit cap.

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 purpose before diving into kind-specific detail, and nearly every sentence carries operational information (quote flow, 402 semantics, versioning, polling). The main weakness is that the middle is one dense run-on paragraph, which costs scannability, but there is little filler to cut.

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 multi-kind mutation tool with an output schema already present, the description covers what an agent still needs: the free/paid split, the quote prerequisite, error behavior, versioning and publication semantics, and the follow-up polling loop. Nothing material about invoking 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 goes further by mapping each kind to its relevant fields (captionStyle for captions, trackId from editCapabilities.musicOptions, beatIndex/shotIndex/alternateId for swap_shot, quoteId for paid kinds) and clarifying that nl takes an instruction. It stops short of documenting idempotencyKey usage beyond what the schema already states.

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 ('Edit a finished Topic Short') and immediately distinguishes itself from generate_topic_short by operating on an existing generation. It then enumerates the exact kinds of edits it supports, so an agent can tell it apart from siblings like quote_topic_short_edit or get_topic_short 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 partitions usage into free kinds (captions, music, swap_shot) versus paid kinds (revoice, regenerate_shot) and states the prerequisite that paid edits must be quoted first via quote_topic_short_edit and run on that quoteId. It also names the alternative path for natural language (nl returns a proposal to be applied step-by-step) and points to quote_topic_short_edit and get_topic_short as companion tools.

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?

The description describes an event notification that advances Last Frame's state ('so the next choice can appear'), which implies a meaningful side effect. However, the annotations declare readOnlyHint: true, suggesting the tool performs no state-changing work. This is an annotation contradiction, and the description does not resolve or clarify the mismatch.

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 no filler or repeated information. Every phrase earns its place: the target, the triggering event, and the resulting outcome are all conveyed efficiently.

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 an output schema, the description provides enough context to understand when and why to invoke it. It does not explain ordering relative to other Last Frame tools or how to obtain the runId, but those details are partly inferable from the parameter schema and sibling 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?

The parameter schema already fully describes runId as 'Last Frame run id whose current shot finished playing,' so schema coverage is 100%. The description adds no additional parameter-level detail beyond that, making the baseline score of 3 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 uses a specific action ('tell Last Frame') tied to a concrete event ('current shot finished playing') and a clear outcome ('so the next choice can appear'). This uniquely distinguishes it from sibling tools like start_last_frame, type_last_frame, and timeout_last_frame based on the trigger condition.

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 clearly states the usage context: it should be called when the current shot has finished playing. It does not explicitly contrast with alternatives like timeout_last_frame or type_last_frame, so it stops short of full exclusion guidance, but the triggering situation 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?

Annotations already provide readOnlyHint=true and destructiveHint=false, covering safety. The description adds the key behavioral trait 'Does not render,' clarifying that this is a non-rendering estimation step, which is useful 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?

Two sentences with no fluff. The purpose and the critical 'does not render' fact are front-loaded, followed by clear usage direction. Every word 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?

An output schema exists, so return values are covered. The description explains when to use it and its relationship to render_storyboard. It doesn't define what 'estimate' returns, but that's handled by the output schema. It is complete for an agent to invoke 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?

All parameters are described in the schema (100% coverage), so the description does not need to add parameter details. It implicitly refers to the script parameter but adds no extra meaning beyond the 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?

The description states a specific verb ('Estimate'), a specific resource ('the next Story part from a script'), and explicitly distinguishes from render_storyboard by noting it does not render. This clearly separates it from sibling tools.

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 instructs 'Use this before render_storyboard when you continue my story,' and adds 'Does not render,' which implies when not to use. This is direct, actionable guidance with an alternative named.

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 a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description nonetheless adds real behavioral context: exports are free, video and cover may come back still rendering, and callers must poll using retryAfterMs until status is 'ready (url)' or 'unavailable'.

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 capability statement is front-loaded and every sentence carries information (format meanings, polling behavior). It runs long across multiple clauses, but there is little filler and no repetition of the schema.

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 an output schema present, return values need not be explained, yet the description still conveys the async rendering contract (retryAfterMs, ready/unavailable). Combined with cost, input preconditions, and format semantics, an agent has everything needed to call and handle results 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 goes well beyond the schema's bare enum list by defining each value: no_music = voice+captions without music, clean = voice+music without burned-in captions, srt/vtt = subtitle file as text, cover = opening frame still. This meaningfully disambiguates the single most consequential parameter choice.

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 first sentence states a specific verb and resource: 'Get a posting export of a finished Topic Short,' immediately distinguishing this from generate_topic_short (creation) and get_topic_short (metadata). The 'finished Topic Short' scope plus the format enumeration makes the tool's output unambiguous 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?

'Finished Topic Short' and 'at no cost' imply when the tool is applicable, and the per-format notes hint at intent (e.g., use no_music if you want to 'add a trending sound in the app'). However, there is no explicit when-to-use/when-not guidance, no statement of prerequisites beyond 'finished,' and no routing to a sibling.

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 annotations, the description discloses non-obvious behavior: the call consumes monthly generation allowance and requires a follow-up poll to get_ad_generation. It also surfaces the quote prerequisite. This is meaningful behavioral context that the annotations alone do not 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?

The description is short, front-loaded with the core purpose, and contains no fluff. The layout sentence is somewhat redundant with the schema but is still compact and useful. Structure is strong, if slightly informal with the lowercase 'layout.'

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 that an output schema exists and the input schema covers all parameters, the description is mostly complete: it covers the async polling pattern, quota usage, and quote prerequisite. It could be slightly richer by naming sibling alternatives, but 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description largely repeats what the schema states, such as layout values and the optional quoteId flow. It adds no new parameter-level meaning beyond the structured definitions.

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 ('Generate') and resource ('Ad Lab stills'), and it clarifies the output format via the layout options. It doesn't explicitly distinguish this from sibling tools like generate_ad_studio or generate_ad_proof_pack, though 'stills' narrows the scope considerably.

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 gives useful context: it consumes the monthly generation allowance, requires polling get_ad_generation, and implies quotes should be generated first when quoteId is omitted. However, it never explicitly says when to use this tool versus alternatives or when not to use it, so usage guidance remains mostly implied.

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 convey readOnly=false and destructive=false, but the description adds meaningful behavioral context: this operation consumes a monthly quota ('Uses this month’s generation allowance'), is asynchronous ('Poll get_ad_generation'), and the final stitched film is available on the job rather than immediately. This goes well beyond the structured 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?

Three short, dense sentences. The core action is front-loaded, followed by allowance/asynchrony and result-location guidance. Every sentence contributes either to selecting the tool or to invoking it correctly; there is no 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?

Given the 100% schema coverage and the presence of an output schema, the description supplies the missing operational essentials: quota consumption, the polling endpoint, and where the final film appears. Nothing an agent needs to correctly invoke this tool is omitted.

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 parameters are already fully documented. The description only echoes what the schema already states by mentioning 'a product photo and a brief' and 'Optional style still.' It adds no new parameter semantics, warranting the baseline score of 3.

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 uses a specific verb and resource: 'Generate an Ad Lab Explain film from a product photo and a brief.' It clearly distinguishes this from siblings like generate_ad by naming the Ad Lab Explain artifact and adding the operational note to poll get_ad_generation. An agent can tell what this tool does and roughly how it differs from related ad-generation tools.

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 clearly states what inputs trigger this tool ('from a product photo and a brief') and gives post-invocation guidance: 'Poll get_ad_generation.' It also warns the agent to 'Stay on Ad Lab; the stitched film is on the job,' which provides context about where results live. It does not explicitly describe when not to use this tool versus other ad generation siblings, so it stops 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?

Beyond the sparse annotations (all false), the description discloses real behavioral traits: it consumes this month's generation allowance, requires polling a sibling job and downloading slides/zip, and forbids inventing fake UIs with a text-CTA fallback. This is exactly the kind of non-obvious context an agent needs and far exceeds 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?

Three sentences with no filler. The purpose is front-loaded, followed by optional inputs/workflow, then critical behavioral constraints. Every sentence contributes essential 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?

Despite 8 parameters and an async job workflow, the description covers the output format, optional inputs, resource cost, retrieval method, and a key edge-case fallback. With an output schema present, no return-value details 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 100%, so the baseline is 3. The description adds value by mapping key optional parameters (product name, screenshot asset or URL, CTA URL) and clarifying behavior around them — specifically the fallback to a text CTA when no screenshot is provided, which is not 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?

The description names a specific verb and resource: 'Generate an Ad Lab Proof pack' with explicit contents (hook, niche in-the-life stills, soft CTA) and aspect ratio (4:5). This clearly differentiates it from siblings like generate_ad_studio and generate_ad_tip_pack even without seeing their 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?

The description gives useful context (generation allowance, polling get_ad_generation) and implies this tool is for creating proof packs, but it never explicitly states when to choose this over alternative generate_* tools or what conditions would route elsewhere. The guidance is inferred rather than 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?

Beyond the sparse annotations, the description discloses critical behavior: the operation consumes paid generation allowance, is asynchronous, and has a specific failure-refund policy. This is exactly the kind of behavioral context an agent needs before invoking a paid 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?

Three short sentences, each earning its place: what the tool does, the cost implication, and the required follow-up behavior. No filler or repetition of schema content.

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 13-parameter tool with nested objects and an output schema, the description plus schema covers the essential workflow: start generation, poll via get_ad_studio, and know the failure cost behavior. Nothing critical 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%, so the schema already documents every parameter. The description adds no extra parameter-level meaning, which is acceptable because the schema carries the burden. 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 opens with a specific verb and resource ('Start a paid Ad Studio clip'), which clearly identifies the action and target. It also distinguishes itself from quote/research/get siblings by emphasizing that this tool starts the actual paid generation.

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 gives clear operational context: it uses this month's allowance, requires polling get_ad_studio, and hard failures return the allowance. It does not explicitly name alternatives or say when not to use it, but the paid-generation context makes the intended use obvious.

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 only signal readOnlyHint=false, openWorldHint=false, destructiveHint=false, so the description carries the burden of behavioral disclosure. It adds meaningful context: consumption of a monthly generation allowance, async job semantics requiring polling, and a download step. No contradiction with 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, each earning its place: the deliverable definition, the quota side effect, the retrieval workflow, and the key parameter deviation. Front-loaded with the purpose and zero 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?

An output schema exists, so return values need no explanation. The description covers the essential usage loop (generation, polling, download) and the quota impact. A minor gap: it never references the quote step that the schema hints at ('Use the same value as the quote'), though the schema itself carries that 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?

Schema coverage is 100%, so the baseline is 3; the schema already documents all six parameters. The description adds marginal value by re-explaining uniquePlates behavior ('reuse one image across the pack') but contributes no new semantics for slideCount, aspectRatio, or ctaUrl beyond what the schema already states.

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 an Ad Lab tip pack') and defines the deliverable's structure (hook, numbered tips, soft CTA), which distinguishes it from siblings like generate_ad or generate_ad_proof_pack. It doesn't explicitly name sibling alternatives, but the content breakdown makes the tool's identity clear.

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 workflow context — 'Poll get_ad_generation; download slides and zip from the job' and 'Uses this month's generation allowance' — which tells an agent what to do after invoking. However, it never states when to choose this tool over siblings (generate_ad_studio, generate_ad_proof_pack) or when not to use it.

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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, but they say nothing about cost. The description adds genuinely new behavioral context: this is a paid operation that consumes the monthly allowance and is asynchronous (must be polled). It stops short of stating quota-exhaustion behavior or duration expectations.

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 covering action, cost, and follow-up, with the core purpose front-loaded. No filler or 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?

With a full input schema and an output schema present, the description does not need to explain parameters or return values. It covers the operation's cost and async nature, leaving only minor gaps such as auth requirements or what happens when the allowance is exhausted.

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 voice, script, and quoteId in detail (including the quoteId/voice mutual exclusion). The description adds no further parameter semantics, so the 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?

The description opens with a specific verb and resource: 'Start a paid Audio Lab narration,' which is clearly distinguishable from siblings like quote_audio_lab, generate_image_lab, and generate_video_lab. It does not explicitly name the sibling it is not, so it falls short of the top score, but the action 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 gives lifecycle guidance by naming the follow-up tool ('Poll get_audio_lab_generation until it finishes') and states the cost model ('Uses this month's generation allowance'). It lacks an explicit quote-first prerequisite or exclusions, which the schema hints at, so it is clear context but not a full when/when-not statement.

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

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

Annotations already mark this as a non-read-only, non-destructive, non-open-world write, so the safety profile is covered. The description adds real behavioral context on top: it is an async submit-and-poll operation ('do not wait here for the full render'), idempotencyKey is auto-generated, and omitting quoteId triggers an implicit quoting step (a hidden side-effect/cost). It does not cover failure or retry behavior, so not 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 action and then the workflow, which is the right order. It is slightly redundant — 'same plan as the site' appears twice and 'Submit and poll — do not wait here' overlaps with the earlier 'Poll get_character_film' — so a small amount of trimming is possible.

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?

An output schema exists, so return values need not be described, and the description supplies the full call sequence (quote → submit → poll → continue). For a 3-parameter async generation tool this is nearly complete; only error/retry handling on an ambiguous submit is left implicit.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description's parameter notes ('this tool quotes the opening first when omitted', 'generated when omitted') effectively restate what the schema already says for quoteId and idempotencyKey, adding no new syntax, format, or constraint 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 with scope: 'Start the Character Film opening (block 1, at most 8 seconds)'. It separates itself from the sibling quote_character_film (quoting) and continue_character_film (the rest of the film) inside the same sentence, so an agent can distinguish it 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?

Explicit when-to-use and what-to-do-next: poll get_character_film, do not block for the full render, and call continue_character_film once the opening completes. It also names the alternative to supplying quoteId (omit it and the tool quotes first), which is exactly the routing decision an agent must make.

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=false, destructive=false, openWorld=false; the description adds the behavior the annotations cannot: the call is billed against a monthly generation allowance and is asynchronous (poll a sibling until it finishes). That is meaningful non-schema context, though quota-exhaustion and failure behavior are unstated.

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 polling instruction are front-loaded and useful, but the first sentence is dominated by an 18-item model name dump that largely duplicates list_image_lab_models rather than earning its place inline. Two sentences are appropriately short overall, yet a third of the token budget is a catalog listing.

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 an output schema present, return values need not be explained, and the description covers the two things structured fields omit: cost/allowance semantics and the async poll flow. It is close to complete for this tool, missing only prerequisite ordering (quote first vs supply modelSlug+prompt).

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 eight parameters (mode vs inputMode aliasing, quoteId-vs-modelSlug/prompt exclusivity, aspectRatio derivation) are already fully documented in the schema. The description adds only the model-slug vocabulary, not any parameter syntax or constraints beyond it.

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?

Starts with a specific verb+resource ('Start a paid Image Lab generation'), scopes it as the paid generation entry point, and names the sibling used to follow up (get_image_lab_generation). An agent can distinguish it from quote_image_lab and list_image_lab_models from the description alone.

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 tells the agent the operation is paid, consumes this month's allowance, and requires polling get_image_lab_generation until finished, which is genuine workflow guidance. However it never states when to use this versus quote_image_lab first, nor what happens if the allowance is exhausted — prerequisites live only in the schema's quoteId description.

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?

Adds real behavioral context beyond the annotations: the call is paid and draws down this month's generation allowance, a failed job refunds that allowance, and polling is required after submission. Annotations only declare the generic safety triad, so this cost/refund/polling disclosure is the valuable part, though rate limits and latency are not mentioned.

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 dense sentences, front-loaded with the action and scope, each carrying distinct information (what it does, cost, quoting paths, polling/refund). No filler or 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?

For a 12-parameter paid generation tool with an output schema present, the description covers the essential workflow — quoting, allowance consumption, refunds, and polling — so return-value explanation is rightly delegated to the output schema. It is complete enough to call correctly, with only minor omissions like timeout expectations.

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 cross-parameter meaning the schema doesn't state on its own: the quoteId-vs-op mutual dependency ('when omitted, op is required and this call quotes first') and the fact that one quote covers every variation and that a quoteId is single-use.

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 ('Start a paid Paint Lab AI action') and enumerates the six concrete ops (finish, edit, fill, colorize, upscale, remove_background), which lets an agent distinguish this from siblings like quote_paint_lab and get_paint_lab_generation 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?

Explicitly routes the agent: pass a quoteId from quote_paint_lab, or supply op settings to quote and generate in one call, then poll get_paint_lab_generation until completed/failed. It names both the upstream and downstream sibling tools and the condition selecting each 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?

Annotation contradiction: annotations set readOnlyHint=true while the description repeatedly describes a write operation ('write the next Story part', 'Clip Studio writes the next part'). This inconsistency is serious and would mislead an agent about side effects.

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-load the core action, add source-of-truth guidance, and close with a useful exclusion and next step. No 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 tool with an output schema and full schema coverage for parameters, the description covers purpose, invocation context, continuity behavior, and the correct next tool. The only real gap is the annotation contradiction, which is scored separately.

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 parameters thoroughly. The description adds the continuity behavior and projectId provenance, but doesn't materially extend parameter meaning beyond the schema, making baseline 3 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?

Description states a specific action ('write the next Story part') and resource ('existing project'), and differentiates from create_storyboard by covering the first-part case and from render_storyboard by explicitly saying it 'does not film.' An agent can see what this tool does and what it is not.

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?

Explains exactly where projectId comes from ('Pass projectId from create_storyboard or get_storyboard') and names the successor step: 'Does not film — call render_storyboard after.' This is explicit when-to-use and follow-up 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?

Annotations only declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, which are not very informative. The description compensates by disclosing important behaviors: 'Uses this month's generation allowance,' 'hook burns Current karaoke,' and 'hookTemplateId ... does not change consume or refund.' It also explains the captionMode nuances. No contradictions found.

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 highly efficient, packing critical facts into a few sentences. It front-loads the main action and immediate follow-up (poll), then clarifies key parameters without redundancy. Every sentence adds new information, and the structure is streamlined.

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 the complexity (17 parameters, nested objects, enums) and the presence of an output schema, the description provides sufficient context for correct invocation. It covers the most complex behavioral aspects (captionMode, hookTemplateId, idempotency) and directs the agent to the right polling tool. The output schema handles return values, so nothing critical 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?

With 100% schema description coverage, the schema already documents each parameter well. However, the description adds extra context for specific parameters like hookTemplateId ('seeds the brief from Opening hooks, script opening, not caption style') and captionMode details about operator-email limitation. This goes beyond the schema, justifying a score above baseline 3.

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 states the tool's action: 'Start a paid Talking Short.' It specifies the resource (a paid Talking Short generation) and differentiates it from siblings like generate_topic_short, generate_ad, and the other generate_* tools. It also mentions key constraints like using the monthly allowance and polling get_talking_short for completion.

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 provides explicit guidance on when and how to use the tool: 'Poll get_talking_short until it finishes.' It also explains conditional behavior like captionMode defaults and the operator-email restriction for the Phrase chip. This is clear enough for an agent to know exactly what to do.

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 annotations only covering readOnly/destructive hints, the description carries the real behavioral load: quota consumption ('this month's generation allowance or complimentary quota'), fail-open stock matching and caption burn (captionBurn.verdict = fallback), 2-minute AI-shot deadlines, narration length never failing generation, and legacy captionMode aliasing. One tension: the description depicts external Pexels/AI interaction while openWorldHint=false, but the write/read/destructive profile is consistent.

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?

Core behavior (generate from plan, auto-plan, source of narration) is front-loaded in the first two sentences and the volume is defensible for a 32-parameter tool. It loses a point because several later sentences restate defaults already carried by the schema (captionStyle='spotlight', transitionMode='dynamic') and repeat the short/long-plan expansion rule.

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?

An output schema exists so return values need no explanation, and the description still covers quota, polling, fail-open paths, and the quote/generate pairing. Nothing an agent needs to invoke this correctly appears 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 cross-tool semantics the schema does not: the shared setup list with quote_topic_short, that hookTemplateId seeds the topic without affecting consume/refund, and that hookTemplateId is a script opening rather than a caption look. These are genuine disambiguations between easily confused 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 opening sentence names a specific verb and resource and states the two accepted inputs (a reviewed storyPlan or auto-planning from topic + storyFormat), which no sibling like quote_topic_short or create_topic_short_story does. An agent can distinguish this as the terminal render step from quote (pricing) and get_topic_short (polling) 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?

It routes the agent explicitly: 'Poll get_topic_short' after submitting, reuse 'the same setup as quote_topic_short ... pass the same values on both', and the schema notes quoting first when quoteId is omitted. It never states a when-not case, so it falls short of full alternative/exclusion 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?

Annotations establish this as a non-read-only, non-destructive, closed-world write, so the description's job is to add cost and lifecycle context. It does: "paid" plus "uses this month's generation allowance" signals consumption/irreversibility, and the polling directive discloses the async nature. It does not discuss idempotency/retry behavior, which is left to 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?

Four tightly packed sentences with no filler: purpose, cost, lifecycle, then the one mode-specific caveat. The most decision-relevant facts (paid, poll, mode constraint) are front-loaded.

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 an output schema present, return values need not be explained, and the schema covers all 24 optional parameters. The description supplies the cost, async, and mode caveats an agent needs, though the quote-first prerequisite and the meaning of the zero-required-parameter surface are largely delegated to the 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 the parameter baseline is 3. The description goes beyond the schema by stating the edit_video constraint (use mode=edit_video plus the same source clip used on the quote, duration/aspect follow source, 720p output, source audio retained) — genuine semantic context that constrains how sourceClipId, mode, durationSeconds, and aspectRatio must be supplied.

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 first sentence gives a precise verb and resource ("Start a paid Video Lab generation") and the word "paid" plus the allowance note distinguishes it from the free quote_video_lab step. The FLUX 3 Edit sentence further scopes one mode. An agent can tell this apart from quote_video_lab, get_video_lab_generation, and list_video_lab_models 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?

"Poll get_video_lab_generation until it finishes" gives the required follow-up action after invocation, and the edit_video note tells the agent when a special input path applies. It stops short of an explicit "call quote_video_lab first when quoteId is absent" instruction in the description (that lives only in the schema), so the when-to-use routing is clear but not fully closed.

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 the read-only, non-destructive, closed-world profile, so the description adds value beyond them by explaining field semantics: resetsAt is an ISO timestamp that is null when there is no reset window, and checkout price IDs appear in the 402 path. That is meaningful behavioral context, though return handling is not fully described.

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 with the purpose front-loaded, then field semantics. No filler, though most of the length is devoted to describing output fields that a dedicated output schema may already cover.

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 annotations and an existing output schema, the description covers what it is and why the notable fields behave as they do. Auth is only implied by 'signed-in', and no error/pagination behavior is mentioned, leaving a small 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly does not invent parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely — the plan and usage for the signed-in Clip Studio account — which is a noun-phrase but unambiguous about what is retrieved. It does not name or contrast against any sibling tool, so it falls short of the differentiation a 5 requires.

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 explicit when-to-use statement or named alternative, but the sentence about offerCheckout price IDs being included 'after a 402' implies the scenario in which the returned data matters. Usage is inferred rather than 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds the singular retrieval scope but does not mention error cases, job-state requirements, or idempotency, all of which are minor for a simple getter.

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 no filler. Every word contributes to specifying the action and the resource.

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?

The definition is mostly complete for a single-parameter getter: output schema covers return values, annotations cover safety, and the parameter is well documented. It lacks explicit guidance on preferring this over list_ad_generations, but the core call information is sufficient.

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 schema documents the only parameter with 100% coverage. The parameter description adds meaningful provenance by specifying that jobId must come from generate_ad, generate_ad_tip_pack, generate_ad_proof_pack, or generate_ad_explain, which helps the agent supply a valid value.

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 uses a specific verb, 'Fetch', and a specific resource, 'one Ad Lab generation'. This distinguishes it from list_ad_generations and from other lab-specific getters like get_image_lab_generation or get_video_lab_generation.

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 itself does not explicitly state when to use this tool versus alternatives. However, the schema's parameter description implies follow-up use after generate_ad-family calls, and the singular 'one' lightly contrasts with list_ad_generations. This is implied usage rather than explicit 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?

Annotations already mark this as read-only and non-destructive. The description adds valuable context about the async polling pattern and the relationship to generate_ad_studio, which annotations do not convey. It could add more about what states the generation may be in, but the output schema likely covers return structure.

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 with zero filler: first states the operation, second gives the critical usage caveat. Information is front-loaded and every word 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, read-only fetch with an output schema and clear polling guidance, the description is complete. An agent knows what to call, when to call it, and how it relates to the generation workflow without needing 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% and the sole parameter id is already described as 'Ad Studio generation id from generate_ad_studio.' The description adds no further semantic detail beyond what the schema provides, 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?

The description states a specific verb ('Fetch') and resource ('an Ad Studio generation'), clearly distinguishing it from the sibling generate_ad_studio and related generation tools. Even with many similar get_* siblings, the 'Ad Studio' qualifier makes the scope 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?

The description gives explicit workflow guidance: submit via generate_ad_studio, then poll this tool, and do not block on generate_ad_studio for the full render. This directly tells the agent when to use this tool versus the alternative it is paired with.

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 and destructiveHint, so no contradiction. The description adds meaningful behavioral context beyond annotations: it refreshes from the provider and does not charge again, which is useful cost and freshness information.

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, no filler. The core fetching purpose is front-loaded, and the cost note is a valuable bonus that 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 read tool with an output schema and readOnly annotations, the description covers the essential behavior: what it fetches, how it identifies the generation, that it refreshes, and that it does not incur a charge. Nothing needed 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?

The schema covers the single parameter fully with a clear description of where the id comes from. The tool description itself adds only 'by id', but with 100% schema coverage, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Fetch') and resource ('Audio Lab generation') and uniquely identifies one generation by id. It distinguishes itself from list_audio_lab_generations and generate_audio_lab by using 'one' and 'by id'.

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 clearly indicates when to use it: when you need a single Audio Lab generation by its id. The refresh and non-charge details add context about what invoking it does, though it does not explicitly name sibling alternatives or state when not to use them.

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 non-destructive behavior. The description adds the polling behavior, the terminal statuses to watch for, and the exact returned fields, which is useful behavioral context beyond the structured annotations. No contradiction.

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 tight sentences, zero filler. It front-loads the purpose, then gives parameter wiring, return fields, and the polling instruction – 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?

The description covers the complete usage pattern: submit, pass the right ID, poll to terminal states, and what the result contains. Combined with the output schema and annotations, nothing essential is missing for an agent to call this tool 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 both parameters are already documented. The description adds provenance for the IDs, linking renderId to generate/continue and projectId to plan, plus reiterating that projectId includes canContinue – this helps the agent wire the asynchronous workflow correctly.

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 first sentence, 'Fetch a Character Film render or project,' states a specific verb, resource, and the two modes (render vs. project). It further names the sibling tools that produce the required IDs, distinguishing it from other get_* and generation tools.

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 explicitly tells the agent where to get the IDs ('from generate_character_film or continue_character_film' and 'from plan_character_film') and gives the polling workflow ('Poll until status is completed or failed'). It lacks explicit alternatives/exclusions, but the context is clear enough for an agent to know when to call this 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the singular-fetch behavior ('one') and otherwise provides no extra behavioral context such as not-found behavior or access requirements.

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 efficient sentence with no filler or repetition. It is front-loaded with the action and resource, though it is minimal enough that it does not add much contextual richness beyond the structured fields.

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 getter with an output schema present and full parameter documentation in the schema, the description is nearly sufficient. It lacks only a small amount of usage context, but nothing critical 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 description coverage is 100%, and the single parameter clipId is already well documented in the schema as coming from list_library or a generate tool. The description adds no additional parameter meaning, so it stays at the high-coverage baseline.

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 uses a specific verb ('Fetch') and a specific resource ('one library clip'), clearly distinguishing it from sibling getters that target other entities. The singular 'one' also signals a single-object retrieval rather than a list operation.

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 gives no guidance on when to use this tool versus alternatives such as list_library or the other get_* tools. The only usage-related hint, that clipId comes from list_library or a generate tool, lives in the parameter schema rather than the description.

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=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by noting the conditional nature of the public URL ('if it is'). This goes slightly 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 description is a single, front-loaded sentence that states the primary purpose first and adds the conditional detail. Every word earns its place 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?

The tool is simple, has one well-documented parameter, safe read-only annotations, and an output schema. Nothing essential is missing for an agent to correctly invoke and interpret the result.

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 input schema has 100% coverage with a clear description of clipId, so the schema does the heavy lifting. The tool description adds no extra parameter meaning, which matches the baseline of 3.

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 specific action ('Get whether...is public, and its public URL'), the resource ('library generation'), and the conditional output. This distinguishes it from broader getters like get_public_generation and write tools like publish_generation.

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 clearly implies the tool is used when checking the publication status of a library clip and retrieving its public URL. It does not explicitly exclude alternatives, but the context is specific enough that an agent knows when to select it.

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 readOnlyHint=true and destructiveHint=false, so the description needn't restate safety. It adds meaningful behavioral context beyond annotations: the call refreshes from the provider and is explicitly not a repeat charge, which is valuable for an agent deciding whether to call it.

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 filler: the first states the action and resource, the second preempts a cost concern. The most important scoping information is front-loaded.

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, read-only getter with an output schema, the description plus annotations cover input source, safety profile, refresh side effect, and billing. Nothing an agent needs to invoke 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?

The input schema fully documents generationId, including its source, so the description adds no necessary parameter semantics beyond the word 'by id'. The baseline of 3 applies because schema coverage is 100%.

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 ('Fetch'), a precise resource ('one Image Lab generation by id'), and an additional behavior ('refresh it from the provider'), making it clearly distinct from enumeration siblings like list_image_lab_generations and from getters of other generation types.

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 clearly implies this is the singular-getter path when you already have a generationId, and the schema description tells the agent where IDs come from (generate_image_lab or list_image_lab_generations). It doesn't explicitly exclude listing, but the contrast with the list sibling is evident.

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=true and destructiveHint=false, so safety is covered. The description adds the useful fact that the response includes the latest shot and choices, but does not disclose any additional behavioral traits such as error cases, freshness guarantees, or whether a missing runId yields an error.

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 clear sentence with no filler. It front-loads the action and resource, then adds one useful qualifier about the returned content. Every word 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, read-only getter with one well-documented parameter, a rich output schema, and annotations covering side effects, the description is complete. The agent has enough information to call the tool correctly without further explanation.

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 runId parameter is already described as coming from start_last_frame. The description does not add parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Get a Last Frame run" names a specific verb and resource, and "including the latest shot and choices" clarifies what the run object contains. This is clearly distinct from other getters like get_clip or get_storyboard, and the Last Frame domain is reinforced by siblings such as start_last_frame.

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: the agent should call this after starting a Last Frame run, using a runId from start_last_frame. However, the description gives no explicit when-to-use guidance, no exclusions, and names no alternative tools, so it does not fully help the agent route between the many get_* 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?

Annotations cover the safety profile (readOnly, non-destructive, closed-world), and the description adds meaningful extra context: it refreshes from the provider, completed results expose a public PNG outputUrl per variation, and it does not incur a new charge. This is useful behavioral detail beyond the annotation set, though it doesn't cover failure/pending states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action and followed by output and billing notes. No filler; every sentence 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 a full output schema present, the description need not explain return values, yet it still hints at outputUrl. Combined with annotation coverage and complete parameter docs, an agent has enough to call it correctly; only provider-refresh timing/error 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 the single generationId is fully documented in the schema, including its origin tools. The description adds no further syntax or format meaning, 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 ('Fetch one Paint Lab AI result by id') and distinguishes itself from list_paint_lab_generations by making the singular/by-id nature explicit. It does not name a sibling directly, so it stops short of the top of the scale.

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 implies the use case (retrieve and refresh a single result), but gives no explicit when-to-use vs. when-not, nor does it point to list_paint_lab_generations or generate_paint_lab as prerequisites/alternatives.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds two non-obvious traits the annotations do not: the call refreshes training status (a side effect on a read-flagged tool) and it 'does not charge again,' which is real billing context.

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 with zero filler. The core action and its status-refresh behavior are front-loaded before the downstream routing and billing note.

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?

An output schema exists, so return values need not be explained. Purpose, polling intent, downstream consumption, and the no-recharge guarantee are all covered. It stops short of describing the status lifecycle (e.g. pending/ready/failed) or what happens if training has not finished.

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 styleId parameter is already fully documented in the schema, so baseline is 3. The description earns an extra point by explaining where the returned id flows next (trainedStyleId for quote/generate), which the schema does not say.

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: 'Fetch one trained Paint Lab style and refresh its training status.' The word 'one' explicitly separates it from the plural sibling list_paint_lab_trained_styles, and the naming makes it distinct from delete_/rename_ variants.

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 downstream routing: once status is ready, pass the id to quote_paint_lab or generate_paint_lab (finish or edit). It implies the polling use case well, but never states when to prefer this over list_paint_lab_trained_styles or what to do if status is not ready.

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=true and destructiveHint=false, so the safety profile is covered. The description adds the 'public published' constraint, which clarifies that private or unpublished generations are not accessible, though it does not disclose error behavior or return details beyond what the output schema provides.

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 states exactly what the tool does and how the target is identified. No filler or redundant explanation, so every word 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?

With one required parameter, full schema coverage, safety annotations, and an output schema present, the definition covers the essential call contract. The only notable gap is the lack of explicit differentiation from get_generation_publication, but the overall context is sufficient for a simple read tool.

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 clipId parameter is already fully documented in the input schema. The description only repeats 'by clip id' and adds no additional semantic information 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 uses a specific verb ('Fetch'), a specific resource ('one public published generation'), and the identifier ('clip id'), making the core action unambiguous. It does not explicitly differentiate from the similar sibling get_generation_publication, but the resource phrase and retrieval-by-clip-id scope are clear enough for basic selection.

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 parameter description gives clear sourcing context: the clipId comes from a /p/{id} URL or list_public_generations, which tells an agent when this tool is appropriate. It does not state exclusions or name alternative tools, but the context is sufficient for a simple public read.

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=true and destructiveHint=false, covering the safety profile. The description adds the mode-switching behavior (fetch vs list) and implies the output includes parts, but does not detail pagination, error handling, or auth, which is acceptable given the read-only nature and existing output 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?

The description is two sentences with zero fluff, front-loads the primary action, and efficiently covers both modes of operation. Every word 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 read-only tool with one optional parameter and an output schema, the description covers the essential behaviors and use case. It does not explain the return structure, but that is handled by the output schema. The dual-mode behavior is clearly communicated.

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 schema description for projectId is already descriptive and covers 100% of the parameter meaning. The tool description essentially repeats the same info, so it adds minimal new semantic value beyond what the schema provides. 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?

The description uses the specific verb 'Fetch' with a clear resource 'Story project and its parts', and explicitly distinguishes the dual behavior (fetch by ID vs list recent projects). This clearly differentiates it from creation/generation tools like create_storyboard and generate_storyboard_part.

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 provides a direct use case: 'Use this to pick up a story and continue the next part.' This implies when to use it, but does not explicitly state when not to use it or mention alternatives, leaving that to inference from sibling names.

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?

The description is consistent with the readOnlyHint/destructiveHint annotations and adds no behavioral claims that would surprise the agent. It does not go beyond the annotations to disclose things like failure behavior, polling semantics, or authentication requirements, 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?

One short, front-loaded sentence with no filler; every word carries meaning. The description is appropriately sized for the tool's simplicity.

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 only one required parameter, a documented output schema, and annotations covering the read-only safety profile, the description provides the necessary anchor for an agent to select and call the tool. Nothing essential 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%: the single id parameter is already documented as 'Talking Short generation id from generate_talking_short.' The description itself adds no additional parameter nuance, so the high-coverage 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?

The description uses a specific verb, 'Fetch', and names the exact resource, 'a Talking Short generation', which separates it from generation/quote tools and from other domain getters like get_topic_short or get_ad_generation. It does not explicitly contrast with generic publication retrieval tools, 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?

The one-line description alone only implies usage, but the id parameter description states the id comes from generate_talking_short, giving a clear workflow context. It does not, however, state when not to use this tool or mention alternatives such as get_generation_publication.

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, non-destructive, closed-world), and the description adds real behavioral value beyond them: the full status state machine (queued → in_progress → composing → completed/failed) and the explicit instruction to keep polling during composing, which prevents premature abandonment. It does not mention auth scope, rate limits, or what happens for an unknown id.

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 first sentence is front-loaded and efficient, but the remainder is a long enumeration of returned fields (setup, sources, shots, versions, editCapabilities, publication, postingPack, coverUrl, exports) that largely duplicates the output schema. Roughly two-thirds of the text is redundant with structured data that the agent already receives.

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 read-and-poll endpoint with one required parameter, the description is more than sufficient: it explains the lifecycle, what triggers continued polling, and how to read the completed payload. Since an output schema exists, the field-by-field listing is surplus rather than a gap, and only error/not-found behavior 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 'id' parameter is already documented in the schema as coming from generate_topic_short. The description repeats that same fact rather than adding format, constraints, or validity semantics, so the baseline 3 for a fully-covered schema 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?

The opening clause states a specific verb and resource ('Fetch a Topic Short generation'), which separates it cleanly from write siblings like generate_topic_short and edit_topic_short. It never names the closest read alternative (get_talking_short or get_public_generation), so the differentiation is by name only rather than explicit routing.

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?

'keep polling through composing' is genuine operational guidance that tells the agent this is a re-invoked status endpoint, not a one-shot fetch. There is no explicit when-not or alternative-tool routing, which keeps it out of the top band.

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