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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds concrete return content (plan, credits left, biggest upload, AI spend cap, one-time AI consent) and implies key-scoped auth via "this key belongs to", which is value 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?

A single front-loaded sentence that spends its length on the returned fields rather than filler. It is a touch long as a colon-list, but every item listed is meaningful output 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?

With no parameters and no output schema, the description carries the burden of describing the response, and it does so by enumerating the key fields. Minor gaps remain (format of credits, behavior on missing/invalid key), but it is sufficient for a simple read-only account query.

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 of 4 applies. There is nothing for the description to disambiguate or clarify.

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

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

Names a specific verb ("Show") and resource ("the JustClip account this key belongs to"), then enumerates exactly which fields are returned. None of the sibling tools query account-level state, so an agent can distinguish it 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?

Usage is implied — reach for it when plan, credit balance, or AI-consent status is needed — but there is no explicit when-to-use statement, no exclusions, and no named alternative. Adequate but not directive.

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 destructiveHint=true, idempotentHint=true, and openWorldHint=true, so safety is partly covered. The description adds genuinely new context: the refund of credits and the hard precondition that the job must not have started, which the annotations do not convey.

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

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

A single sentence that front-loads the action, states the precondition, and closes with the user-visible payoff (credits returned). 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?

No output schema exists, and the description covers the key outcome (cancellation plus credit refund) so an agent knows what success means. It stops short of describing the failure path when a generation has already started, which is the main remaining gap.

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

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

Only one parameter ('id') with 0% schema description coverage; the description's reference to 'an AI generation' lets the agent infer that id identifies the generation/job, but it never states this or gives a format. Adequate inference rather than real added meaning.

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

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

States a specific verb (cancel) and resource (an AI generation), plus a meaningful scope qualifier ('hasn't started at the provider yet'). That distinguishes it from siblings like ai_status, ai_list, and ai_download without naming them explicitly.

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 precondition 'hasn't started at the provider yet' implicitly tells the agent when this applies, but there is no guidance on what to do when the generation has already started (e.g., fall back to ai_status) or when to prefer letting a job finish.

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 supply the safety profile (idempotentHint=true, destructiveHint=true, openWorldHint=true), so the bar is lower. The description adds that both image and video generations are supported, but it never explains the destructive aspect implied by destructiveHint — namely that writing to outputPath can overwrite an existing local file — nor what happens if the generation is not finished.

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

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

A single front-loaded sentence with no waste; the verb, resource, and destination all appear immediately. It is perhaps slightly under-specified rather than verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, no-output-schema tool the definition is minimally viable, but it omits the meaning of 'id', any preconditions about generation completion, and the overwrite behavior that the destructive annotation implies.

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 only 50%: outputPath is well documented in the schema, but 'id' has no description in either the schema or the tool description. The parenthetical '(image or video)' loosely gestures at file type but adds nothing beyond the schema's existing extension 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?

States a specific verb (Save) and resource (a finished AI generation, image or video) written to a local file, which distinguishes it reasonably well from the clip-oriented download siblings like download_clip and download_beat_edit. It stops short of explicitly naming which sibling it supersedes.

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 word 'finished' implies the generation must be complete before calling (i.e., after ai_status reports done), which is useful implied guidance, but there is no explicit when-not statement and no routing to or away from download_clip/download_all_clips.

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 it is a non-idempotent, open-world write; the description adds the economically critical behaviors: it SPENDS credits, requires a prior price check and user consent, and that provider-failed, blocked or cancelled jobs refund credits. That is substantive context not derivable from the annotations or 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?

Three dense sentences with zero filler, front-loaded with the action and the credit-spend warning before the follow-up tool chain. Nothing is repeated from the title or 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?

For an 11-parameter, nested-object, no-output-schema tool this covers the essentials: what it returns (generation ids), the required workflow, and the credit risk. It stops short of clarifying required-vs-optional parameter combinations or the recipe/model exclusivity in prose, which the agent must infer from 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 description coverage is 91%, so parameter meaning is already largely documented (refs kinds, model/recipe distinction, expectedCredits refusal, ownFootage/productAuthorized consent flags). The description adds no parameter-level syntax or format detail beyond what the schema states, 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 an AI image or video generation') and immediately distinguishes it from the sibling tools that handle its lifecycle (ai_price, ai_status, ai_download, ai_cancel). An agent can identify the tool's role without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives explicit sequencing: price with ai_price, get the user's OK first, then follow ids with ai_status and save with ai_download. It names the alternatives and the conditions that select them, which is exactly the routing an agent needs.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds value by disclosing what comes back (each idea carries prompts, timing and price) and that the call is 'Free' – a cost trait absent from the annotations. It says nothing about latency or whether the result is cached, which keeps it from 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?

A single, front-loaded sentence enumerating the output types; nothing is redundant. The trailing 'Free.' is terse but earns its place as cost information, though its placement is slightly abrupt.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only generator with no output schema, the description does describe the returned items and cost, and annotations cover safety. However, it leaves real ambiguity about whether it lists pre-existing ideas or generates new ones, and gives no clipId sourcing guidance.

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 one parameter (clipId) with 0% schema description coverage, so the description must carry it. 'AI ideas for a clip' implies clipId identifies the target clip, but no format, source, or example is given. With a single obvious required param, this is just adequate.

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 concrete output for a specific resource: AI ideas for a clip, itemized as B-roll moments, a hook opener, a cover and product shots. That is far more specific than a tautology, but it never distinguishes itself from AI siblings (ai_generate, ai_models, more_moments), so an agent must infer the boundary on its own.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The word 'Free' hints at a cost consideration but does not tell the agent when to prefer this over ai_generate or more_moments.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description usefully discloses the status-scoping rule (any status for a clip, finished-only account-wide), but says nothing about pagination, result limits, or ordering.

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

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

A single sentence, front-loaded with the verb and resource, with the two modes following immediately. 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?

With no output schema, the description should hint at what comes back (IDs, statuses, pagination), and it only conveys the status filter. Adequate to call the tool correctly, but thin on return-shape and volume 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 0% and clipId is completely undocumented in the schema, so the description carries the burden — and it does: including clipId changes both scope and status filtering. It never states the parameter name or type, keeping it just short of a 5.

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

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

The description gives a specific verb+resource ('List AI generations') and distinguishes two scopes: per-clip results and account-wide finished results. It doesn't explicitly contrast itself with the nearest sibling (ai_status), but the listing intent is unmistakable.

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 implicitly defines when each mode applies: pass a clip to get that clip's generations in any status, or omit it to get the account's finished ones. That is clear usage context, though no alternative tool is named and no explicit 'use this instead of X' routing is given.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered; the description adds real behavioral content beyond them by disclosing that the payload includes credit balance, model pricing, templates and consent state. It does not mention rate limits, auth requirements or output shape, but for a zero-parameter read tool the added content is substantive.

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 dense sentence plus a short imperative, with the 'call before ai_generate' instruction front-adjacent rather than buried. The opening label 'The AI Studio:' is decorative rather than informative, a small waste in an otherwise tight definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining what comes back, and it does so by enumerating models, templates, credits and consent. Combined with a zero-parameter schema and full annotation coverage, an agent has enough to invoke it correctly, though nothing is said about response size or structure.

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

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

The tool takes no parameters, so there is no argument semantics to document and the baseline is 4. The description correctly implies a no-argument, whole-catalog fetch rather than a filtered query.

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 enumerates exactly what the call returns: every image/video model with its inputs, settings and credit price, ready templates, spendable credits, and one-time consent status. It is clearly a read-only discovery endpoint and is distinguishable from siblings like ai_price, ai_list and ai_generate, though it opens with a noun phrase ('The AI Studio') rather than a verb+resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives explicit ordering guidance with 'Call this before ai_generate,' which tells the agent the sequencing relative to its most important sibling. It does not mention the other nearby alternatives (ai_price, ai_list) or state any when-not-to-use conditions, so the coverage is clear but not exhaustive.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds a meaningful behavioral fact those annotations cannot express: no credits are consumed, i.e. this is a free evaluation path. It does not describe the returned price shape, but that is a minor gap given the read-only annotations.

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

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

Two short sentences, zero filler, with the credit-free guarantee front-loaded before the input contract. Every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description does not explicitly say what is returned (a credit cost), though 'price ... in credits' strongly implies it. With 10 nested parameters and 0 required fields, the 'same as ai_generate' pointer is the key completeness aid and is present, so the definition is sufficient without exhaustively enumerating inputs.

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 90%, so the schema already documents nearly all 10 parameters. The description adds a genuinely useful cross-reference ('same inputs as ai_generate'), telling the agent the parameter contract mirrors that sibling tool rather than being a reduced set. It adds no per-parameter detail beyond this, which is acceptable at this coverage level.

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 (price) and resource (an AI generation) with an explicit scope qualifier: 'without spending anything'. It also directly relates itself to the sibling ai_generate ('Same inputs as ai_generate'), so an agent can tell these two apart without opening either 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?

The dry-run framing ('without spending anything') clearly implies when to use this instead of ai_generate: check cost before committing credits. However, there is no explicit when-not or named alternative, so the routing 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description adds real value by disclosing the result domain (queued/running/done/failed/nsfw/canceled) plus the wait estimate. It does not cover behavior for an unknown id or whether polling is required, but the key behavioral context is present.

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 sentence, front-loaded with the action and resource, then the outcome set and the wait estimate. No filler and nothing redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates the returnable statuses and the wait estimate. Combined with annotations covering the safety profile, this is close to complete for a one-parameter status check; only id semantics and error behavior are 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?

The single 'id' parameter has 0% schema description coverage, so the description carries the burden. 'Check an AI generation' implicitly identifies the id as a generation id rather than a clip or project id, which is the main ambiguity resolved, but no format or accepted-value guidance is given.

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 ('Check') and resource ('an AI generation') and enumerates the possible states, so the agent knows exactly what is returned. It is clear on its own but never names how it differs from siblings like ai_list or ai_cancel, which also operate on AI generations.

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 only implied: mentioning a 'wait estimate' hints that this is a polling tool to call after ai_generate. There is no explicit statement of when to use it versus ai_list (enumerate generations) or ai_cancel, and no stated prerequisites.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, non-idempotent, openWorld), and the description adds genuinely new behavioral facts: it costs 1 credit, requires a paid Clipper plan, and is asynchronous with results fetched via beat_edit_status. It does not mention failure modes or how long an edit takes, but the important operational traits are disclosed.

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 no filler: what it does and the plan gate first, then input requirements, then cost and return value. Every clause carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fills the key gap by stating the return value (edit id) and naming the polling tool. Cost and plan requirement round it out. A minor gap remains around turnaround time or what beat_edit_status ultimately yields, but an agent has enough to invoke and follow up 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 78%, with detailed per-parameter descriptions for music, video, projectId, length, fill, style, and musicStart. The description only reiterates the file-vs-projectId choice for the two media inputs and adds no meaning for style, fill, captions, captionStyle, or musicStart beyond what the schema already provides, 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?

States a specific verb+resource ('Cut a video to the beat of a song') and immediately scopes plan eligibility ('Clipper plan and up'), so an agent can distinguish it from sibling tools like beat_edit_status and download_beat_edit.

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 the two accepted input modes (local music file + local video file OR an existing projectId) and points to the next step in the workflow ('Returns the edit id for beat_edit_status'). It stops short of explicit when-not-to-use guidance or naming alternative tools for related tasks, but the operating context is clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered externally. The description adds genuinely new behavioral information: the request returns a single edit's status when an id is supplied, but degrades to a recent-list when it is omitted. It says nothing about polling frequency, terminal states, or how progress is reported.

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 sentence that front-loads the primary use (check progress) and appends the conditional variant. No filler, nothing redundant with 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?

For a minimal one-optional-parameter tool this covers the core contract, but with no output schema and no parameter documentation, the description leaves the return shape and possible status values entirely unspecified for what is inherently a polling 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 coverage is 0% and the single optional parameter has no description, so the description must carry the meaning — and it does: the id selects a specific Beat Edit, and omitting it switches the call into a list operation. It still doesn't say what the id looks like (job id vs. edit id) or its format.

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 (check) and resource (a Beat Edit's progress), and additionally covers the list mode when no id is given. It doesn't explicitly contrast with sibling tools like beat_edit or download_beat_edit, so it falls short of full sibling differentiation.

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?

"With no id, list the recent ones" implies how to get the two different behaviors, which is useful routing within the tool. However, there is no guidance on when to call this versus beat_edit (start an edit) or download_beat_edit (fetch the result), which are the most likely confusions.

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 mark this as a non-readonly, non-idempotent write with openWorldHint, and the description usefully adds that each copy gets a new clip id — the key behavioral consequence for an agent tracking outputs. It also discloses the plan gating and the 3-per-clip bound. It omits whether the operation is synchronous or whether copies cost credits quota.

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

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

Two short sentences, front-loaded with the action and bounded by the key constraints (plan tier, count limit, new clip id). No wasted words and no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 3-parameter mutation with no output schema, the description covers what is produced ('each copy is a new clip id'), the eligibility gate, and the quantity cap. It lacks any mention of async behavior, rate limits, or error conditions, which is the only meaningful gap given this tool's complexity.

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

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

Schema description coverage is 0%, so the description must carry the load. It clarifies styleIds implicitly ('caption styles', at most 3), but says nothing about clipId or projectId beyond their names. The enum of valid styles and the maxItems/minItems bounds live only 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?

States a specific verb and resource: 'Render copies of a clip in up to 3 other caption styles.' An agent can distinguish this from make_clip or rename_clip from the description alone. It stops short of explicitly naming sibling tools that also create clips, but the caption-style framing is precise.

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 real usage context: Pro/Studio plan requirement and a hard cap of 3 styles per clip. However, it never says when to prefer this over make_clip or other clip-creation siblings, nor does it mention failure modes when the plan lacks entitlement or the clip already has variants.

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 what the annotations declare, the description discloses several high-value behaviors: videos are downloaded on the local machine before upload, live Twitch/Kick clipping runs continuously until stopped with stop_live, and the operation costs 1 credit per minute of video length. Cost and side-effect disclosure is exactly the context annotations (readOnlyHint=false, openWorldHint=true) cannot convey.

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

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

Purpose is front-loaded and each subsequent sentence adds a distinct fact (input formats, local download, live behavior, cost, return value). The one soft spot is the parenthetical 'own lane — YouTube always works', which is idiomatic and slightly ambiguous for an agent, costing a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, multi-parameter mutation tool with no output schema, the description covers the essentials an agent needs: valid inputs, VOD-vs-live branching, the cost model, the stop mechanism, and the returned project id for polling. Nothing operationally necessary 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 focus, source, liveFrom, template, and subtitleStyle. The description reinforces source input and the live-clipping path, but adds little syntax or meaning beyond the schema fields, matching the baseline of 3 when the schema does the heavy lifting.

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

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

The description opens with a specific verb+resource ('Turn a video or a live stream into short clips') and pins down the accepted input sources (YouTube/Twitch/Kick URL or local file path). It never names or distinguishes a near sibling such as make_clip, so an agent must still infer which of the two to pick, which keeps this just under a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives clear context for when the tool applies: URL/path for VODs, a live Twitch/Kick channel URL for live clipping, and it routes the agent to stop_live for termination and project_status for polling. It does not state when NOT to use this tool versus alternatives like make_clip, so it stops short of full routing guidance.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true), and the description's file-writing behavior is consistent with that. It usefully adds that only 'ready' clips are bundled and covers are included, but says nothing about overwriting an existing file at outputPath, auth/plan requirements, or behavior when some clips are not ready.

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

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

A single front-loaded sentence with no wasted words; scope, contents, and output form all land in one pass.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should carry the full load, and it does explain what the artifact is (one .zip with covers). It omits, however, the return value, overwrite/error behavior, and what happens to non-ready clips, leaving gaps for a bulk mutation 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 coverage is 50%: outputPath is documented in the schema, projectId is not. The description's 'of a project' and 'as one .zip' loosely map to the two parameters but add no format or validation detail (e.g., whether the path must end in .zip, what happens on collision), 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 (download) plus resource and scope: 'every ready clip of a project the plan can export, with covers, as one .zip.' The word 'every' implicitly contrasts with the single-clip sibling download_clip, but no sibling is named, so the differentiation is inferred rather than explicit.

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?

'Ready clip ... the plan can export' implies the precondition for use, but the description never states when to choose this over download_clip or download_beat_edit. Usage is implied by scope rather than spelled out.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is largely covered. The description adds only the 'finished' precondition and says nothing about why a download would be flagged destructive, whether it overwrites an existing file at outputPath, or auth/rate constraints.

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 tight sentence with the artifact and format front-loaded; no wasted words. It is efficient, though brevity here partly reflects under-specification rather than discipline.

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 two required params, no output schema, and no explanation of the download destination behavior, an agent lacks enough to invoke confidently: the meaning of 'id', overwrite behavior, and error handling are all unaddressed for this open-world download 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 coverage is 50%: outputPath is documented in the schema, but the required 'id' parameter has no description anywhere. The phrase 'to a local .mp4' loosely reinforces outputPath, yet the description does nothing to clarify what 'id' identifies or its format.

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 (Download), a named resource (Beat Edit), and the output artifact (.mp4), which clearly distinguishes it from siblings like download_clip and download_all_clips. It does not, however, explicitly name those siblings or contrast its scope against them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The word 'finished' hints at a prerequisite (the edit must be complete, likely per beat_edit_status), but there is no explicit when-to-use, no mention of the beat_edit/beat_edit_status workflow, and no guidance on how to choose this over download_clip or download_all_clips.

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 destructiveHint=true and idempotentHint=true, so the safety profile is partly covered. The description adds genuinely non-structured behavioral context: the operation fails with an unlock message when the clip is blocked by the plan's export cap. It still doesn't explain the destructive aspect (e.g. overwriting an existing file at outputPath), which is the main remaining gap.

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, with the core action front-loaded and the failure condition as the second clause. 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?

With no output schema the description should carry more weight, and it does cover the primary failure mode. However a 5-parameter mutation-style tool leaves 'template' semantics, overwrite behavior, and relative vs absolute path handling unaddressed, so it is sufficient but not complete.

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

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

Schema description coverage is only 40%, so the description must compensate. It does clarify that the 'video'/'srt' format branch maps to the output file type, but the 'template' enum (blurred/clean) is undocumented in both the schema and the description, and the output overwrite/extension rules are left implicit.

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 ('Download a rendered clip') and extends it to a second artifact type ('or its captions as .srt'), which helps an agent understand the format branch. It does not differentiate itself from the sibling 'download_all_clips' or 'download_beat_edit', so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied by the presence of sibling download tools (download_all_clips, download_beat_edit) but the description never says when to pick this single-clip variant over them, nor any prerequisite such as the clip being rendered first. Adequate but with a clear routing gap.

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 a safe read (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, and the description adds real value beyond them: it lists the returned attributes and discloses a non-obvious behavior — that clips locked by the plan's export cap get marked. That locking disclosure is genuinely useful behavioral 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?

Two front-loaded sentences with no filler: purpose first, then the notable locking behavior. 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?

With no output schema, the description carries the return-value burden and does so by enumerating the clip fields (hook, score, duration, render status). Combined with annotations covering the safety profile, an agent has enough to call it correctly; only the projectId format 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?

There is a single parameter (projectId) with 0% schema description coverage, so the schema does no explanatory work. The description only implies project scoping via "a project's clips" without defining format or source of the id. The meaning is fairly intuitive but under-specified.

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

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

The description gives a specific verb+resource ("List a project's clips") and even enumerates the returned fields, so the resource is unambiguous against siblings like list_projects. It does not explicitly name a sibling it differs from, but the scope is clear enough for 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?

There is no guidance on when to use this versus alternatives (e.g., project_status or download_clip), nor any prerequisites or exclusions. Usage is only weakly implied by the mention of a project's clips and render status.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value beyond that by disclosing ordering semantics (newest first) and the shape of each returned row, which matters since there is no output schema. It does not address pagination or whether the list is truncated at the limit.

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 sentence, no filler, with the subject (account's projects) and the most decision-relevant detail (newest first) front-loaded. 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 simple read-only list tool with rich annotations and a fully documented parameter, this is nearly complete; it even compensates for the absent output schema by naming the returned fields. Minor gap: no mention of pagination behavior or whether more than the limit exists.

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 optional parameter with 100% schema description coverage, so the schema already explains 'limit (default 20)'. The description adds no further meaning about the parameter, 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 (List) and resource (account's projects) plus scope qualifiers: recency ordering (newest first) and the fields returned (status, length, clip count). No sibling tool overlaps this resource, so an agent can select it on the name and 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?

Usage is only implied by the phrase 'recent projects' — an agent can infer this is a browse/overview call, but there is no explicit when-to-use statement and no named alternative (e.g., list_clips or project_status) for drilling in. No exclusions or prerequisites are given.

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 the safety profile (non-read-only, non-destructive, non-idempotent, open-world), so the burden is lower. The description adds genuinely useful context beyond that: the operation is free and the render happens in the background, which tells the agent there is no immediate artifact to expect.

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

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

One tight sentence front-loads the core transformation, then a compact clause discloses cost and async rendering. Nothing is redundant and every phrase 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 two-required-param creation tool with no output schema, the description discloses the important async/render-in-background behavior so the agent knows nothing returns synchronously. However, with 0% schema coverage it leaves both parameter semantics unaddressed, which is a meaningful gap for a mandatory-input mutation.

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

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

Schema description coverage is 0% and both parameters are required, so the description carries full responsibility. 'a moment from more_moments' loosely maps candidateId to a moment, but projectId is never explained and the id formats/sources are absent, leaving both params effectively undocumented.

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 verb+resource are specific ('turn a moment ... into a finished clip') and it names the source sibling more_moments plus the clip's constituent parts (hook, captions, render). It stops short of distinguishing itself from other clip-producing siblings like clip_video or beat_edit, which would earn a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied: the mention of a 'moment from more_moments' signals the workflow feeds from that sibling, so an agent can infer the prerequisite. There is no explicit when-to-use, no exclusion, and no routing against the many clip-related 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 already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuine value beyond that: the result ordering ('best first'), the fact that these are unmatched/leftover moments, and a cost signal ('free'). It doesn't cover pagination behavior, but with annotations carrying the safety profile a 4 is fair.

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, no filler, and the scoping/ordering constraint is front-loaded ahead of the next-step pointer. 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 read-only list tool with no output schema, the description says what the list contains and how it is ordered, plus the follow-up action. The one gap is the shape of a returned moment — it doesn't indicate what identifier to hand to make_clip — but the essentials are present.

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

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

Schema coverage is 50%: limit is documented with its default, projectId has no description at all. The description implies project scoping ('in a project') but adds no format, ID source, or default detail. Baseline 3 is appropriate given the schema does most of the work.

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

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

States a specific verb (list) and a precisely scoped resource: moments found in a project but not turned into clips, ordered best first. The 'did not make into clips' qualifier inherently distinguishes it from list_clips and other clip-oriented siblings without the agent needing to open a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly routes the agent forward: 'Turn one into a clip with make_clip (free).' That tells the agent this is the discovery step in a make_clip workflow. There is no when-not guidance or exclusion of alternatives, 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered; the description's "Nothing is published" reinforces rather than adds to that. Its real contribution is describing what the returned artifact contains (hook line, caption, hashtags, platform-specific drafts, file names), which is meaningful since no output schema 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?

A single tightly-packed sentence that front-loads what the tool produces and closes with the key non-action ("Nothing is published"). Every clause carries information; 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?

With no output schema, the description usefully enumerates the returned content, and the annotations carry the safety semantics, so an agent knows what it gets back and that nothing is published. Minor gaps remain (whether drafts are generated on demand or cached, and no handling of the clipIds default beyond the schema), but overall it is complete for a simple two-parameter 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 50% (clipIds is documented, projectId is not). The description only obliquely touches parameters via "a project's clips," implying projectId scoping and clip-level relevance, but adds no formats, defaults or behavioral nuance beyond what the schema already states. Baseline 3 for mid coverage is appropriate.

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

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

The description clearly states the resource (ready-to-post text drafts for a project's clips) and enumerates the concrete outputs (hook line, caption, hashtags, X/LinkedIn drafts, file names). It is a noun phrase without a verb, and it never distinguishes itself from the adjacent sibling caption_variants, so an agent must infer the difference between draft generation and caption 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?

"Nothing is published" implies this is a retrieval/draft-generation step rather than a publishing or mutating one, which gives implicit usage context. However, no alternative tool is named and no explicit when-to-use or when-not-to-use condition is provided, so the agent still has to infer the routing vs siblings like caption_variants.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds the useful detail that the response includes both processing status and ready-clip count, but says nothing about possible status values, whether it must be polled, or rate-limit 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?

A single tight sentence with the essential information ('processing status' and 'clips ready') front-loaded. No filler or redundant restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries the return-value burden and partially meets it by naming status and clip count. For a status-polling tool it should ideally mention status values or polling semantics, leaving a moderate 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?

There is a single required parameter, projectId, with 0% schema description coverage, so the description must compensate and it only weakly does ('a project's'). It conveys that the ID names a project but adds no format or source guidance (e.g., where to obtain it, as with list_projects).

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

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

States a specific verb and resource ('Check a project's processing status') plus the payload detail ('how many clips are ready'). An agent can distinguish it from list_projects/list_clips, but it never explicitly differentiates itself from those siblings or from beat_edit_status/ai_status, which use similar 'status' naming.

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 on when to call this versus list_projects, list_clips, or the other status siblings, and no mention of polling behavior for a status endpoint. The usage context (check after creating/uploading to a project) is only 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 already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that – it does not say the existing title is overwritten, nor anything about permissions or 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?

A single front-loaded sentence with no wasted words. It is efficient, though its brevity is partly under-specification rather than disciplined 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?

For a mutation tool with three required parameters at 0% schema coverage and no output schema, the description is too thin. It omits which identifiers are needed and what the rename affects.

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

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

Schema description coverage is 0%, so the description must carry the burden, but it only hints at the 'title' parameter and says nothing about clipId or projectId. It adds no format, length, or constraint information beyond what the parameter name implies.

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 (change/rename) and resource (a clip's title), which is clear enough for an agent to know what it does. It does not, however, differentiate itself from any sibling or clarify scope beyond the obvious.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use it. The agent must infer usage entirely from the name.

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 disclose the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true), so the bar is low, but the description adds almost nothing beyond them: it does not say that setting a cover replaces an existing one, that clearing removes the thumbnail, or that generationId/key must be mutually exclusive. It is at least consistent with the destructive hint via 'clear 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?

A single sentence with the modes front-loaded and no filler. Slightly telegraphic ('an uploaded image key') but every clause maps to a distinct behavior, so nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, 4-parameter mutation tool with no output schema, the description should say what changes on success and how the three modes interact. It covers the modes but leaves replacement semantics and mutual exclusivity of generationId/key/clear 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?

With only 50% schema description coverage, the description carries real weight by mapping each mode to its parameter: 'finished cover generation' -> generationId, 'uploaded image key' -> key, 'clear it' -> clear. Only clipId is left unexplained, which is self-evident from context.

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 (set) and resource (clip's cover/thumbnail) and enumerates the three input modes, so the agent knows exactly what the tool mutates. It does not name or contrast any sibling, but none of the siblings (upload_media, make_clip, ai_generate) directly overlap with this 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 implies three usage paths (finished generation, uploaded key, clear) and indirectly points at upload_media/ai_generate outputs, but it never states when to prefer one mode, whether modes are mutually exclusive, or any prerequisites for calling 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 declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond them: it discloses that a final recording pass runs and the project then finishes, which tells the agent this is a terminal, finalizing operation rather than an instantaneous halt.

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 padding, and the effect of the call is front-loaded immediately after the action statement. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter terminal tool with no output schema, the description covers the action, its aftermath, and the project end state, while annotations carry the destructive/idempotent profile. The only real gap is the unaddressed projectId semantics.

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 single projectId parameter has 0% schema description coverage and the description never mentions it at all, so neither source explains which project is being stopped or what identifier format is expected. With one undocumented parameter, the description should have compensated but does not.

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 (Stop) plus resource (watching a live stream) with a clear scope statement. It distinguishes itself adequately from siblings like list_projects or project_status, though it does not name those siblings explicitly or explain its relationship to them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

"Stop watching a live stream" implies the context in which the tool applies, but there is no explicit when-to-use versus alternatives (e.g., how this differs from project_status or canceling via another tool) and no stated preconditions or exclusions.

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=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description's one genuine addition is that it 'Returns its key' — essential here because there is no output schema — but it says nothing about size enforcement failures, account/permission requirements, or the fact that repeated uploads create new objects (non-idempotent).

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

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

A single front-loaded sentence with no filler: verb and resource first, then the two use contexts, then the return value. Nothing redundant with the schema is repeated beyond the brief format list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema, the description covers what the tool does, the accepted media types, and — critically — that the result is a key usable as an AI ref or clip cover. What is missing is any note on where the returned key is consumed or what happens on failure/duplicate upload, but the essentials are present.

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

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

There is only one parameter and the schema already documents it exhaustively with absolute-path requirement plus per-format size ceilings (100% coverage). The description adds only that the file is 'local', which is already implied by 'path'; baseline 3 is appropriate when the schema carries the parameter semantics.

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 ('Upload a local image, song or short video to the account's media') and names the two consumer contexts for that media (AI inputs via refs kind 'media', or a clip cover). That framing lets an agent separate it from siblings like set_cover (which acts on already-uploaded media) and ai_generate (which consumes it).

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 supplies the two downstream purposes ('for AI inputs ... or a clip cover'), which implies when an agent should reach for it, but it never names an alternative tool or an exclusion. There is no guidance on prerequisites (must the file exist locally? which account?) or on what to do if the upload fails or a duplicate exists.

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