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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false; the description adds the genuinely useful behavioral fact that execution is synchronous rather than queued through autonomous_edit. It does not disclose whether existing captions are overwritten (especially in 'clear'/'recreate' modes) or what the synchronous call returns, which matters for a mutation tool.

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

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

A single sentence with zero filler, and the synchronous/alternative-path distinction is front-loaded where an agent will see it first.

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 a nested 'scene' object, a six-value mode enum, and no output schema, the definition is adequate but thin: mode semantics and the return behavior of the synchronous call are unexplained. Annotations and the 75% schema coverage fill enough of the gap that this is not a serious deficiency, but the description could say more.

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 75% schema description coverage and four parameters, the schema carries most of the documentation burden. The description adds nothing about the enum values for 'mode' (the one parameter lacking a schema description) or about scene vs project_id precedence, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Apply a caption template to a scene') and explicitly contrasts with the sibling autonomous_edit path, so an agent can distinguish it from the autonomous workflow. It does not convey what applying a template actually does to existing captions, but the action 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 phrase 'synchronously (without going through autonomous_edit)' implies when to pick this over the autonomous siblings, which is useful routing context. However, it gives no guidance on the six modes (add vs recreate vs clear etc.), nor on when to use scene vs project_id, leaving key selection decisions 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?

Annotations only say readOnly=false, destructive=false, openWorld=false; the description adds the critical non-obvious behavior that this tool does NOT upload the file - the caller must PUT the bytes to the returned uploadUrl - plus the exact return shape { uploadUrl, fileUrl }. Still missing is signed-URL expiry or size/type limits, which matter for a URL-minting 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?

Front-loads the purpose in the first clause, then compactly covers body shape, return values, and next step in one tight pass. No filler sentences and no repeated schema content beyond a useful reminder of the call shape.

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 4-parameter tool with no output schema, the description covers what it returns and how to consume it, which is the key gap a missing output schema would otherwise leave. The remaining omission is operational context such as URL expiration or accepted file size constraints.

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 75% and the schema already documents fileType, projectId and contentType, so the description's inline '{ fileName, fileType?, contentType?, projectId? }' mostly restates the schema's required/optional shape. It adds no format, constraint, or default 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?

States a specific verb and resource ('Get a signed upload URL for a local file') and immediately ties it to its downstream consumer, autonomous_edit's video_url parameter. An agent can distinguish this from siblings like list_assets or delete_asset without reading any schema.

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

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

Gives an explicit three-step workflow (call this, PUT bytes to uploadUrl, then pass fileUrl to autonomous_edit) and explains the motivating condition: avoiding external hosting of video/image/audio. It does not name an explicit exclusion or a competing alternative, which keeps it just 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 only flag destructiveHint/openWorldHint; the description adds real behavioral context the annotations do not carry — the plan/execute/verify/export pipeline and that the mp4 URL returns synchronously when an export is queued. It does not say what project state the destructive edit overwrites or whether prior edits are recoverable.

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 compact sentences, front-loaded with the tool's role, then the mechanism, then the return value, then the async alternative. No filler or restatement of schema 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 15-parameter mutation tool with no output schema, the description covers the core call shape and the sync return value, and the schema itself documents the advanced resume/approval parameters well. Missing only a note on cross-call continuity via project_id, which the tool treats as an important pattern.

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 only adds the usage pattern for `prompt` (send intent verbatim, any length); it says nothing about the approval-resume flow (requirePlanApproval/workingMemory/editedPlan) or asset URL requirements, which the schema already handles.

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 'PRIMARY EDIT TOOL' and states a specific verb+resource: run a natural-language video edit end-to-end, with the backend planning, executing, verifying and exporting. That tells an agent exactly what this does and how it differs from queue_edit / autonomous_edit_streaming 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 says to prefer queue_edit + check_job_status for long renders, and gives the input range (one-liner to multi-paragraph brief) that qualifies as a call. It does not distinguish this from autonomous_edit_streaming, which remains an unaddressed alternative.

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 flag this as a mutating, destructive, closed-world operation, so the safety burden is partly carried elsewhere. The description adds genuinely non-obvious behavior: it returns only the terminal result while emitting per-step events (status, thinking, tool_call, tool_result, background_job_completed) as MCP progress notifications, and only when the client supports them. It omits the approval/workingMemory continuation loop, which the schema covers.

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

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

Three tight sentences, front-loaded with the differentiation from autonomous_edit, then return shape, then the selection rule. 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 15-parameter, nested-object, mutating tool without an output schema, the description says almost nothing about what the "final terminal result" contains or how awaiting_approval / workingMemory / project_id continuity behaves. The rich schema compensates for parameters, but the return-shape gap keeps this at adequate.

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

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

Schema description coverage is 100%, so all 15 parameters, including nested scene/assets objects and the approval resume fields, are already documented in the schema. The description adds no parameter-level guidance at all, which is acceptable here but earns only the 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?

States a specific verb and resource (edit video) and explicitly frames itself against the sibling autonomous_edit, with the distinguishing trait being SSE streaming plus progress notifications. It is slightly dependent on the reader already knowing what autonomous_edit does, but the delta 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?

"Use for long-running briefs where users expect live progress" gives a concrete selection condition and implicitly excludes short/synchronous edits (which map to autonomous_edit). It does not spell out failure modes or when streaming is unavailable, but the when-to-use signal is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that wait:true blocks until a terminal state, but it does not explain terminal states, timeout behavior, or what the poll returns; the wait behavior is also already in 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?

The description is a single front-loaded sentence with no wasted words. It communicates the core action, identifier requirement, and wait option 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 simple read-only polling tool this is minimally adequate, but because there is no output schema, the description should say more about what status values or terminal states are returned. It also omits timeout or failure behavior for wait:true.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description repeats that job_id is numeric and wait blocks until terminal, but adds no additional format or semantic detail beyond the schema.

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

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

The description states a specific verb, "Poll," and resource, "export / async job," with the required identifier. It is clear, though it does not explicitly distinguish itself from sibling tools like check_task_status or get_active_task.

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?

Polling an export/async job implies the use case, and wait:true is described. However, there is no explicit guidance on when to use this instead of check_task_status or get_active_task, nor any exclusions or 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a useful identity distinction (queue_edit task vs export job), but says nothing about what the poll returns — the set of status values, whether a terminal state carries a result payload, or how often to poll.

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, front-loaded sentences with zero filler; the disambiguation from job_id sits immediately after the core 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?

With no output schema, the description carries the burden of explaining return values, yet leaves the agent without any notion of status states or terminal conditions. Adequate for selecting the tool, thin for actually interpreting a poll response.

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

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

Only one parameter and schema coverage is 100%, with the schema already stating 'Task id from queue_edit.' The description restates the same provenance information, adding no format or mutation detail beyond it. Baseline 3 applies.

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

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

States a specific verb (poll) and specific resource (a queued edit task), and explicitly separates itself from the job_id/export flow handled by check_job_status. An agent can distinguish it from its closest sibling 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?

Explains the entry point (taskId returned by queue_edit) and implicitly routes export-job polling to check_job_status by naming job_id as a separate concept. It stops short of explicitly saying 'use check_job_status for exports' or describing what to do between polls, but the usage 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the lower bar applies, but the description still says nothing beyond field names. It never explains what 'enforcement: soft|hard' actually changes in downstream behavior, whether name must be unique, whether the call is idempotent, or what happens on conflict — the one piece of genuinely non-obvious behavior here is left entirely undefined.

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 purpose sentence followed by a compact field list, front-loaded and waste-free. The telegraphic brace notation is dense but readable for an agent and appropriate for an 8-parameter tool.

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

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

For a nested 8-parameter creation tool with no output schema, the field inventory is complete enough to construct a call, but key behavioral questions — what enforcement governs, whether the kit is immediately active, what the call returns — are unanswered. Adequate to invoke, thin on the consequences of invoking.

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 schema description coverage at 0% and nested objects, the description is the only source of parameter meaning, and it delivers: it enumerates every top-level field plus the internal shape of palette {primary,secondary,accent,neutral,extras[]} and fonts {primary,secondary}, and restates both enum value sets. It falls short of a 5 because the semantics of gradeBias and enforcement values are listed but not explained.

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

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

States a specific verb and resource: 'Create a brand profile.' The create-prefix plus the sibling set (list/get/update/delete_brand_kit) makes it obvious this is the creation entry point, though the description says 'brand profile' where everything else says 'brand kit', a small naming inconsistency. No sibling is named explicitly, but the CRUD family is self-evident.

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 when-to-use guidance, no prerequisites, no pointer to update_brand_kit for modifying an existing kit. The agent must infer entirely from the name that this is the first step before update/delete.

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=false, and openWorldHint=false, so the mutation/safety profile is covered. The description adds nothing beyond that: no auth/permission requirements, no note that name must be unique, no mention of what the call returns (e.g., the new project id) or whether brandId can be changed afterward.

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 with zero filler. The second sentence is a fragment, and the brevity here reflects under-specification rather than tight editing.

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 should say at least roughly what comes back, and it does not. For a simple three-parameter create tool the description is minimally adequate, but the unexplained `description` parameter and absent return-value note leave real gaps.

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 carries the full burden and only partially meets it. It clarifies that brandId is an 'initial' association (implying it can be changed later), but never mentions the `description` parameter at all and gives no constraints on `name`.

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

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

States a specific verb and resource ('Create a new project'), which is unambiguous against siblings like list_projects, get_project, and delete_project. It does not explicitly differentiate from create_brand_kit, but the resource noun does most of that work already.

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 create a project versus any alternative flow, no prerequisites, and no note about what happens next (e.g., whether brand association can be changed later). The agent must infer everything about invocation context.

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 annotations already declare destructiveHint=true and readOnlyHint=false, so the unsafe mutation profile is covered. The description adds practical context about where the fileName comes from but does not explain irreversibility, confirmation expectations, or post-deletion 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?

The description is a single, front-loaded sentence with no wasted language. It puts the core action first and the identifier clarification second.

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 destructive tool with annotations covering the safety profile and no output schema, the description is nearly complete. It only lacks explicit mention of permanence or any confirmation requirement.

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 compensate for the single undocumented parameter. It does this reasonably well by identifying fileName as an asset file name and tying it to the path returned by asset_upload_url, though it does not provide format examples.

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

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

The description states a specific verb and resource ("Delete an asset") and immediately clarifies the identifier needed via the parenthetical about the file name. An agent can distinguish this from sibling asset tools such as list_assets or asset_upload_url.

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 by noting the file name is the path returned by asset_upload_url, but it does not explicitly state when to use this tool versus alternatives or outline any preconditions beyond the identifier source. The usage is implied by the destructive action and parameter requirement.

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 openWorldHint=false, so the safety profile is partly covered. But the description adds nothing beyond that: it doesn't say whether the deletion is permanent, whether associated assets/captions are affected, or what permissions are needed — important for an irreversible mutation.

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

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

A single front-loaded sentence with zero padding. It is efficient, though the terseness reflects under-specification rather than disciplined editing.

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, irreversible mutation with an undocumented parameter and no output schema, the description should disclose what is removed and that the action cannot be undone. It provides none of that, so an agent cannot call it confidently without guessing.

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 required parameter, brand_id, with 0% schema description coverage, and the description never mentions it. It doesn't clarify the expected ID format or where the ID comes from (e.g., list_brand_kits).

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 ('Delete a brand profile'), enough to distinguish it from the list/get/create/update brand-kit siblings. Minor terminology drift ('profile' vs 'brand kit') is the only blemish.

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 indication of when to use this versus update_brand_kit or deleting a project, no prerequisites, no warning that the operation is permanent. The agent is left to infer everything about usage context.

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 readOnlyHint=false, so the delete semantics are covered structurally. The description adds the useful qualifier that only user-saved templates are eligible (built-ins presumably can't be removed), but says nothing about irreversibility, permission requirements, or behavior when the id is invalid or unknown.

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 with the verb and the resource front-loaded and zero filler. Nothing could be cut without losing 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 destructive tool with no output schema and no annotation details beyond destructiveness, the definition is serviceable but thin. An agent still lacks error behavior, id format expectations, and any post-deletion confirmation 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?

Schema description coverage is 0% for the single parameter, so the description carries some burden. Saying "by id" clarifies that template_id is an identifier rather than a name, but no format (UUID, slug, opaque string) or example is provided to help construct a valid call.

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

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

The description states a specific verb and resource ("Delete a user-saved caption template") and narrows scope to user-saved templates via "by id". The resource name is distinct from siblings such as delete_brand_kit, delete_asset, and delete_project, though it never explicitly contrasts with apply_caption_template or list_caption_templates.

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?

"User-saved" hints that only templates created via save_caption_template qualify, but the description gives no explicit when-to-use guidance, no mention of apply_caption_template as the non-destructive alternative, and no note about what to do if the template is missing.

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 readOnlyHint=false, so the safety profile is known without the description. The description adds nothing beyond that: it does not say whether deletion is permanent, what happens to assets or dependent resources inside the project, or whether confirmation is required.

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

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

The sentence is short but that is under-specification rather than conciseness: it has zero informational payload beyond the title. There is no front-loading problem because there is nothing to front-load.

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 irreversible destructive operation with no output schema and an undocumented parameter, the definition is far too thin. It omits consequences, prerequisites, and return behavior, leaving the agent to infer everything from the name.

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 should compensate, but it provides no information about project_id — no format, no example, no note that it is required. The only hint is the parameter's self-explanatory name.

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 restates the tool name and title verbatim ('Delete a project.'), adding no specificity about what a project is or what deletion entails. An agent learns nothing beyond the name it already has.

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 when-to-use, when-not-to-use, or alternative is mentioned, even though sibling tools like delete_asset and get_project exist and could be confused in scope. The description gives no routing guidance whatsoever.

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 openWorldHint=false; the description adds the useful fact that the call is unauthenticated, which tells the agent no credentials or token flow is needed. It does not say what a success versus failure response looks like, which is the key behavioral detail for a diagnostic.

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 core purpose, zero filler. Appropriately sized for a no-argument read-only probe.

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?

Simple zero-param read tool with no output schema, but for a diagnostic the agent still needs to know what result indicates healthy versus unreachable, and that is absent. The unauthenticated note covers the main prerequisite, leaving the outcome semantics as the 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 there is nothing for the description to disambiguate; the baseline for a no-parameter tool 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?

Names a concrete operation and target: a connectivity diagnostic against LEVEA_API_URL. That is more specific than the title and distinguishes it from status-checking siblings like check_job_status and check_task_status, though it never explicitly contrasts itself with 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?

Usage is implied by the word 'diagnostic' – an agent can infer it is for verifying reachability before or after other calls – but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as check_job_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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral facts: the lookup is project-scoped and may legitimately return nothing ('if any'). It does not describe the shape of a returned task or what happens when no task is running, which matters most for a reconnection flow.

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, with the core action front-loaded ahead of the secondary 'useful for' note. Nothing could be trimmed without losing 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 output schema, the description carries the burden of explaining what comes back, and it only says 'the currently-running edit task (if any)' — enough to signal nullability but not the fields, identifiers, or status a client needs to actually reconnect. For a small read tool this is adequate but leaves a real 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% for the single project_id parameter, so the baseline applies. The description adds only the framing that the id selects which project's active task is returned, which is a marginal restatement rather than new semantics such as format or where the id comes from.

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 ('return the currently-running edit task') scoped to a project, which is materially clearer than a bare title restatement. However, it never distinguishes itself from the closely-named siblings check_task_status and check_job_status, leaving the agent to guess which status tool applies.

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

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

The phrase 'Useful for reconnecting MCP clients' implies a usage scenario, which is more than nothing. But there is no explicit when-to-use/when-not guidance and no mention of the alternatives check_task_status or check_job_status that an agent would plausibly reach for first.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds nothing beyond that: it does not say what happens with an unknown or malformed brand_id, whether a not-found error versus empty result is returned, or what fields a brand kit actually contains.

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 short sentence with the retrieval scope front-loaded and zero padding. It is efficient, though the extreme brevity leaves room to add one clarifying clause without harming 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?

There is no output schema, so the description is the only place an agent could learn what a fetched brand kit returns, and it omits that entirely. For a simple read tool with readOnlyHint coverage the gap is not fatal, but an agent cannot tell whether it will receive assets, colors, fonts, or just metadata.

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 parameter meaning, and it only weakly does: 'by id' implies brand_id is an identifier but says nothing about expected format (UUID, slug, numeric) or validity constraints. One required parameter is effectively undocumented in both structured and unstructured text.

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 (one brand profile) qualified by 'by id', which cleanly distinguishes it from the sibling list_brand_kits. It loses a point for calling the resource a 'brand profile' while the name and siblings say 'brand kit', a small terminology mismatch an agent must reconcile.

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?

'Fetch one brand profile by id' implicitly signals single-record lookup with a known identifier, so the alternative list_brand_kits is inferable. However, it never states when this tool should be chosen over list_brand_kits, nor how an agent obtains a brand_id in the first place, so guidance 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=true and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond that — nothing about error behavior for a missing/invalid id, or what identifiers are acceptable.

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 or redundancy. It is efficient, though its brevity borders on under-specification rather than tightness.

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 read tool with annotations covering the safety profile and no output schema, the minimum needed to invoke is present. However, an agent still lacks id format guidance and any hint of the returned shape or failure mode.

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

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

Schema description coverage is 0% and the single parameter project_id is bare typed as string. The description only echoes 'by id' without clarifying format (UUID, slug, numeric?) or how to obtain a valid id, so it does not compensate for the coverage gap.

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 project') scoped by 'by id', which implicitly separates it from list_projects and delete_project. It does not explicitly name a sibling to avoid, but the singular/read nature is clear enough to select 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?

There is no statement of when to use this versus list_projects (which presumably also returns project data) or any prerequisite such as needing an existing project_id. Usage is only inferable from the word 'one' and 'by id'.

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 openWorldHint=false, so the safety profile is covered. The description adds that results are scoped to the user's own uploads, but says nothing about ordering, result caps, pagination, or whether an empty result is possible — real gaps for a listing tool even with annotations 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?

Two short sentences, front-loaded with the primary action, with zero filler. The brevity borders on under-specification rather than waste, so it is efficient but leaves obvious value unstated.

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 annotations covering safety, the essentials are present, but with no output schema the description is the only place an agent could learn what the response looks like (asset objects, IDs, pagination) — and it does not say. Adequate, 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 coverage is only 50%: fileType carries an inline description with its allowed values, while projectId has none. The description partially compensates by calling projectId an optional filter, but never explains what a project ID represents here or that filters combine (AND) rather than replace each other.

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

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

States a specific verb and resource ("List the user's uploaded assets") with the ownership scope made explicit, which separates it from list_projects and list_brand_kits by resource type. It stops short of naming a sibling or clarifying how it differs from the other list_* 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?

"Optional projectId filter" implies the scoping use case, but there is no explicit when-to-use versus when-not, no mention of when to prefer the fileType filter, and no note about whether all assets are returned unpaginated. Usage is inferable but not guided.

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 openWorldHint=false, so safety is covered. The description adds value beyond that by disclosing the shape of each returned profile (palette, fonts, logo, voice, gradeBias) and how the ids chain into autonomous_edit, though it says nothing about ordering, counts, or behavior when the user has no brand kits.

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: the first states the resource and its payload, the second states the actionable output. Everything is front-loaded and each 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 and no parameters, the description must carry the return-shape burden, and it does by naming the five profile fields. The only gap is behavior at the edges — empty results, ordering, or how many kits can exist — which keeps it short of 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No syntax or filtering concerns exist for an argument-free list call.

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

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

Specific verb plus resource ("List the user's brand profiles") with an enumeration of what each profile contains, which tells an agent exactly what data comes back. It does not explicitly position itself against the sibling get_brand_kit or list_projects, so sibling differentiation is implied by plurality rather than stated.

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

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

The second sentence gives concrete downstream context: the returned ids are fed into autonomous_edit via brandId / projectBrandId. That tells the agent when this call is a prerequisite, but there are no exclusions or explicit alternative-routing statements (e.g., when to use get_brand_kit instead).

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 openWorldHint=false, so safety is covered. The description still adds value by disclosing the result composition (builtin templates mixed with user-saved ones) and the shape of each entry, which an agent couldn't infer from the empty 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?

Two compact sentences with the resource and scope front-loaded and the return shape immediately after. No filler, no restatement of the title alone.

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

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

For a zero-parameter, read-only list tool with no output schema, the description supplies the one thing missing from structured data: what each returned entry contains (slug, display name, style summary). An agent has everything needed to call it and consume 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 tool takes no parameters, so there is nothing for the description to disambiguate. Baseline for a zero-parameter tool applies, and the description correctly avoids inventing filtering options that don't exist.

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

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

States a specific verb and resource ("List the user's caption templates") and disambiguates scope as "builtin + saved", plus names the fields returned. The verb alone separates it from the apply/save/delete_caption_template siblings, though no sibling is named 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?

Usage is only implied: mentioning that slugs are returned signals this is the discovery step before apply_caption_template, but the description never says when to use this versus list_brand_kits-style alternatives or that slugs feed other tools. No exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered structurally. The description adds nothing beyond that: no pagination behavior, no result ordering, no note about how many projects come back or whether archived projects are included.

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 short sentence, front-loaded with the verb and resource, with no filler. Its terseness is appropriate for a four-word tool, though it borders on under-specified rather than merely concise.

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 has to carry the burden of telling the agent what comes back — and it doesn't. It says nothing about return shape, pagination, ordering, or whether the list is scoped to the authenticated user; for an agent deciding whether this is the right call, that is a real 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 there is nothing for the description to explain and the baseline applies. The absence of parameters is consistent with a simple list operation.

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 clear verb and resource ('List' + 'projects'), so the basic action is unambiguous. But it does nothing to distinguish it from sibling list tools (list_assets, list_brand_kits, list_caption_templates) or from get_project, leaving scope boundaries implicit.

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 explicit guidance on when to use this versus get_project (single item) or the other list_* siblings. Usage is only inferable from the name itself, which is the minimum guidance possible.

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 destructiveHint=true and readOnlyHint=false, so safety is covered structurally; the description adds the non-obvious async contract: immediate return, a taskId, and the required polling tools. That is genuine context beyond annotations. It does not say what the edit mutates (e.g., whether an existing project_id is overwritten), which matters given destructiveHint=true.

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 no filler, and the defining trait (async, returns taskId) is front-loaded before the when-to-use guidance and the polling pointer.

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 9-parameter, nested-object tool with no output schema, the description correctly supplies the one piece of return-value information an agent needs (taskId) plus the polling loop, and the schema covers everything else. What is missing is placement within the edit family — nothing tells the agent when queue_edit loses to autonomous_edit or autonomous_edit_streaming.

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 fully documents all 9 parameters including prompt semantics, public-URL constraints, and caption template ids. The description adds nothing about parameters, so the baseline 3 applies — the schema does all 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?

The description describes an async dispatch pattern ("Fire-and-forget async path. Returns immediately with a taskId") but never states the verb+resource directly; the agent must infer "queue a video edit" from the name and title. Critically, it does not distinguish this tool from autonomous_edit or autonomous_edit_streaming, which are the obvious competing edit entry points, so the agent cannot tell from the text alone which edit path to pick.

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

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

It gives an explicit selection condition ("Use when the edit may exceed the MCP request timeout") backed by concrete examples (long viral-clip generation, multi-format export), and it explains the follow-up workflow by naming check_task_status and get_active_task. It stops short of naming the synchronous/streaming edit siblings as the alternative, which is the single most useful exclusion here.

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

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

Annotations already declare a non-read-only, non-destructive, closed-world write, so the safety profile is covered. The description adds only the persistence intent; it does not say what happens on a duplicate name, whether style is validated, or whether the saved template becomes immediately available to apply tools.

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 verb, with no filler. It is efficient, though its brevity shades into under-specification rather than tight information design.

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

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

For a 3-parameter create tool with a nested style payload and no output schema, the description covers the basic intent but omits duplicate-handling, validation expectations, and any indication of what is returned. Minimum viable, with clear gaps.

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 name, tags, and style are already documented, and the description adds nothing beyond them. The nested style object (font, color, position, animation) is left entirely to the schema, which is acceptable but earns only the 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?

States a specific verb and resource ("Save a new caption template definition") with a hint of the payoff (re-apply later). It is clear on its own, but it never distinguishes itself from the very similar sibling save_current_caption_template.

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 user can re-apply later" implies a create-then-apply lifecycle but gives no explicit when-to-use condition, no prerequisite, and no pointer to list_caption_templates, apply_caption_template, or save_current_caption_template. An agent has to infer the choice from sibling names alone.

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=false, openWorldHint=false, so the safety profile is covered. The description adds that the capture is of 'currently applied' styling (a point-in-time snapshot), but says nothing about duplicate-name handling, overwrite behavior, or whether a template id is returned.

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

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

A single front-loaded sentence with no filler. The 'project / scene' slash construction is slightly loose, but 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?

With a nested 'scene' object and no output schema, the description does the minimum: it names the sources but not what a successful call yields or how the inline scene differs from project_id in practice. Adequate for a 3-parameter tool, but not more.

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

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

Schema description coverage is 100%, so all three parameters are documented, which sets the baseline at 3. The phrase 'currently applied to a project / scene' usefully clarifies that scene and project_id are alternative sources of the snapshot, but adds no format or precedence detail beyond the schema.

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

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

The verb 'Snapshot' plus the resource 'caption styling currently applied to a project / scene' states precisely what the tool produces. It falls short of a 5 because it never distinguishes itself from the near-identically named sibling save_caption_template, leaving the agent to guess which one to call.

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

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

There is no when-to-use guidance and no mention of alternatives, despite save_caption_template being an obvious confusable sibling. The description implies the source is current project/scene styling, but never says when this should be chosen over save_caption_template or apply_caption_template.

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=false, openWorldHint=false, so the mutation/safety profile is partly covered. The word "Force" adds real signal that an existing transcript may be recomputed or overwritten, but the description never confirms that, nor whether the call is synchronous, how long it takes, or what permissions it needs.

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

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

Two short sentences, front-loaded with the action, and the return-value note is compact. Nothing is padded, though the extreme terseness leaves key operational questions unanswered rather than making those sentences earn their 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 usefully covers the return payload ("transcript words + timing") in the absence of an output schema. For a forced, potentially long-running transcription job it omits sync/async behavior, polling expectations, and overwrite semantics, which are the details an agent most needs before invoking it.

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

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

Schema coverage is 100% and both parameters (fileName, language) are documented in the schema, so the baseline is 3. The description adds only "existing asset" as a hint about the path and says nothing about the language hint's behavior.

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: "Force transcription of an existing asset." It is unambiguous about what the tool produces, though it never names a sibling or explains how it differs from edit/queue tools in the same family.

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

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

Only implied guidance: the asset must already exist. There is no statement of when to call this versus other job-oriented siblings (check_job_status, check_task_status), nor whether the call blocks, must be polled, or should be preferred over an existing transcript.

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 readOnlyHint=false, so the safety profile is covered. But the description adds no behavioral context beyond that: it never says whether omitted fields are cleared or preserved (partial vs. full replace), which is the single most consequential question for a destructive update, nor does it mention permissions or irreversibility.

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

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

Two short sentences with the core action front-loaded and no filler. It is efficient, though the second sentence is doing load-bearing work it isn't precise enough to carry.

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?

A destructive 9-parameter mutation with nested objects, zero schema coverage, and no output schema needs far more: partial-vs-replace semantics, per-field meaning, and what is returned. The description leaves an agent able to identify the tool but not to invoke it safely.

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% across 9 parameters, so the description must carry the burden and largely fails. 'Body has the same shape as create_brand_kit' is a cross-reference that gives no field-level meaning for fonts, palette, gradeBias, voiceTone, enforcement, logoAssetUrl, or forbiddenColors, and the agent has no guarantee create_brand_kit's schema is visible in 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 and resource ('Update an existing brand profile') plus the lookup key ('by id'), which separates it cleanly from create_brand_kit, delete_brand_kit, and get_brand_kit in the sibling list. It doesn't name those siblings explicitly, but the verb makes the distinction 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?

Usage is implied by 'existing ... by id' — the agent infers it must already have a brand_id from list_brand_kits or get_brand_kit. There is no explicit when-to-use/when-not statement and no mention of whether create_brand_kit should be preferred for new kits.

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