levea-mcp-server

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

With no annotations, the description carries the full behavioral burden, and it only discloses that execution is synchronous. It says nothing about permissions, whether applying overwrites existing captions, whether modes like "clear" or "recreate" are destructive, or what happens on failure.

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 no filler; the synchronous constraint and the autonomous_edit contrast are both front-loaded.

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

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

For a mutation tool with six undocumented mode behaviors, an inline nested scene object, and no annotations or output schema, the description is too thin. An agent cannot infer the effect of each mode or how scene and project_id interact.

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 75%, so the baseline is 3. The description adds no information about the mode enum values (add, recreate, style, translate, clear, remove_fillers) or the scene-vs-project_id alternative, leaving important parameter semantics to the schema.

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

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

The description states a specific verb and resource ("Apply a caption template to a scene") and explicitly distinguishes the operation from the autonomous_edit sibling. It does not clarify what applying a template actually does to the scene, which keeps it 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?

It gives one useful routing signal: use this for synchronous application rather than going through autonomous_edit. However, it offers no guidance on when to choose this over queue_edit or other caption-related siblings, and no conditions for selecting among the mode values.

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

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

With no annotations, the description does useful work by disclosing the return shape and the required two-step behavior: PUT the file bytes to uploadUrl, then pass fileUrl to autonomous_edit. It does not mention auth requirements, upload URL expiry, rate limits, or file-size constraints, 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?

The description is compact and front-loaded: it states the purpose, then the body shape, then the return values and required next action. Every sentence contributes useful information without padding.

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

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

For a tool with no output schema and four parameters, the description explains the return fields and the follow-up workflow needed to use the result. It is nearly complete, but additional behavioral details such as upload constraints or URL expiry would improve callers' readiness.

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 description repeats the body parameter names and marks the optional ones, while the schema already documents fileType, projectId, and contentType. With 75% schema description coverage, the schema does most of the parameter documentation, and the description adds only modest semantic value.

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

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

The description states a specific verb and resource: getting a signed upload URL for a local file. It also distinguishes the tool from the downstream sibling autonomous_edit by framing it as the preparation step for passing fileUrl into autonomous_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?

It clearly says to use this when a user has a local video/image/audio file instead of hosting it elsewhere before calling autonomous_edit. It does not explicitly name when not to use it or list alternative tools for hosting, so it falls just short of the top score.

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

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

With no annotations, the description carries the burden and does well: it discloses the backend plan/execute/verify/export pipeline and that the final mp4 URL returns synchronously when an export is queued — behavioral facts not in the schema. It omits failure modes, cost/timeout expectations, and reversibility, 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?

Front-loads 'PRIMARY EDIT TOOL' and the core action, then layers scope, return behavior, and the long-render alternative across four tight sentences with zero waste.

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

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

For a 15-param tool with nested objects, no annotations, and no output schema, it covers intent, routing, and synchronous return well, and the schema handles param detail. Minor gaps remain around failure/permission/limit behavior that an agent might want before committing.

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

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

Schema description coverage is 100%, so the schema already documents all 15 parameters thoroughly. The description reinforces the prompt semantics ('send intent verbatim') but adds little beyond what the schema provides, 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 ('run a natural-language video edit end-to-end'), names itself as the PRIMARY EDIT TOOL, and contrasts with queue_edit + check_job_status. An agent can tell exactly what it does and how it differs from siblings.

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 recommends queue_edit + check_job_status for long renders, giving a clear when-to-use alternative. It does not address the autonomous_edit_streaming sibling, leaving one routing decision to inference, but the core guidance is strong.

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

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

With no annotations, the description carries real weight: it discloses that only the final terminal result is returned, that per-step events arrive as MCP progress notifications, and critically that this only happens when the client supports them. That conditional is exactly the kind of behavioral caveat an agent needs before choosing this over the plain sibling. It doesn't address mutation scope or the approval/resume loop (left to the schema).

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

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

Three tight sentences: differentiation first, return/progress behavior second, usage guidance last. Nothing is repeated from the schema and no sentence is filler.

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

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

For a complex 15-parameter mutation tool with no annotations and no output schema, the description covers the key unknowns an agent faces: what comes back (terminal result only), how progress is surfaced, and its client-support dependency. The approval/resume flow and scene-mutation effects are only in the parameter descriptions, so a little context is missing at the top level.

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

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

Schema description coverage is 100% across all 15 parameters, including long explanations for prompt, requirePlanApproval, workingMemory, and editedPlan, so the schema does the heavy lifting. The description itself adds no parameter semantics beyond what the schema already states. Baseline 3 applies.

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

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

The description defines the tool by explicit contrast with a named sibling ('Same as autonomous_edit but consumes the SSE event stream'), so the agent knows this is the streaming variant of the editing tool and what differs. It never states the editing verb/resource directly, relying on the reader knowing autonomous_edit, which keeps it short of a self-contained 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?

'Use for long-running briefs where users expect live progress' gives a concrete selection condition, and the 'same as X but...' framing implicitly routes everything else to autonomous_edit. It stops short of naming the alternative and exclusion explicitly, so it's a strong 4 rather than a 5.

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

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

With no annotations, the description carries the burden, and it does disclose a meaningful trait: wait:true blocks until a terminal state, implying a potentially long-lived request. It omits timeout behavior, poll intervals, what terminal states exist, and what errors occur for unknown/expired job IDs.

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

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

Two compact sentences with no filler, and the core purpose is front-loaded ahead of the optional wait behavior. Slightly telegraphic phrasing ('Supports wait:true') but efficient.

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

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

For a polling tool with no output schema and no annotations, the description should say what the response looks like (status values, terminal states, timing hints). It leaves that entire burden to inference, so it is only minimally 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 coverage is 100%, so both parameters are already documented in the schema (including 'numeric' and 'Block until terminal state'). The description adds no meaning beyond that, 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 and resource ('Poll an export / async job by jobId'), so the agent knows exactly what the tool does. However, it does not differentiate from the sibling 'check_task_status', which appears to serve an overlapping purpose, leaving ambiguity about which one applies to a given job.

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

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

The 'Supports wait:true to block until terminal' clause hints at how to use the wait flag, but there is no explicit guidance on when to poll versus block, how often to poll, or when 'check_task_status' should be used instead. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses very little. "Poll" implies a repeated read, but the description never says whether the call blocks, what status values come back, whether a task can expire or fail, or how often polling is safe — all essential for a polling tool with no output schema.

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

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

Two short sentences, zero filler, with the operation and its provenance front-loaded and the disambiguation clause second. Nothing could be removed without losing routing 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 annotations and no output schema, the description should explain what a poll returns and what to do with it (keep polling vs. stop). It covers identity and origin of the task but leaves the entire result-handling side unspecified.

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

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

Schema coverage is 100% and the single parameter is already documented as "Task id from queue_edit." The description's parenthetical adds only the same provenance, so it does not meaningfully extend parameter meaning beyond the schema.

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

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

States a specific verb and resource ("Poll a queued edit task by taskId") and ties the resource back to its producer, queue_edit. It also carves out the boundary against the export job_id concept, though it never names the sibling tool check_job_status that a confused agent would actually reach for.

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

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

"Poll a queued edit task... returned by queue_edit" tells the agent exactly when this tool applies: after queue_edit. The note that this id is separate from job_id (exports) is a useful negative condition, but it is implicit rather than a direct "use check_job_status for exports" routing instruction.

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

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

With no annotations, the description carries the full behavioral burden. It never says what permissions are needed, whether creation is idempotent, what happens on name collision, or what the call returns (no output schema either). It does at least surface the soft|hard enforcement concept, but without explaining what either mode does.

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

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

Front-loaded one-line purpose followed by a dense but compact field list; nothing is padded. The run-on field dump is slightly hard to scan and 'brand profile' vs 'brand kit' naming drifts from the tool name.

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

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

For an 8-parameter mutation with nested objects, zero annotations and no output schema, the definition gives structure but not semantics: what each field controls, which are practically required, and what the caller gets back are all unstated.

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 schema defines palette and fonts merely as untyped objects, so the description's disclosure of palette {primary,secondary,accent,neutral,extras[]} and fonts {primary,secondary} adds real meaning the schema lacks. The enum values for gradeBias and enforcement are restated from the schema and no parameter is explained semantically (e.g. what gradeBias influences).

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

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

Specific verb+resource ('Create a brand profile') with an enumeration of the fields it accepts. The verb distinguishes it implicitly from update_brand_kit/get_brand_kit/delete_brand_kit, though it never names a sibling to route away from.

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 statement of when to use this vs update_brand_kit for modifying an existing kit, no prerequisites, no mention of whether a kit must not already exist, and no guidance on which of the optional fields matter for which use case.

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

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

No annotations are provided, so the description carries the full burden. Beyond implying a write, it says nothing about required permissions or scope, whether the caller becomes owner, what defaults are applied, or what happens if brandId is invalid — significant gaps for an unannotated 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?

Two short fragments with no filler and the core action front-loaded, but the terseness comes at the cost of substance — the second fragment is the only informational payload.

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

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

For a three-parameter mutation tool with no annotations and no output schema, the description is too thin: it omits return value expectations (e.g., the new project ID), permission requirements, and the semantics of two of three parameters.

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, and it only clarifies that brandId is optional and establishes an initial brand association. The required 'name' and the free-form 'description' parameters get no explanation at all.

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 and clearly distinct from siblings like get_project, list_projects, and delete_project. It does not explicitly name or contrast with a sibling, so it falls short of a 5.

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

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

There is no guidance on when to create a project versus using an existing one, no prerequisites, and no mention of alternatives. The only hint is that brandId is optional, which is parameter-level rather than usage-level.

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

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

No annotations are provided, so the description carries the full behavioral burden for a destructive operation. It does not disclose irreversibility, permission requirements, failure behavior, or what happens if the named asset does not exist.

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. The operation and the parameter provenance are both stated immediately.

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

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

For a simple one-parameter tool this is enough to identify what to call it with, but for a destructive tool with no annotations and no output schema, the description leaves out important behavioral context such as irreversibility and expected outcomes.

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 add parameter meaning, and it does: fileName is identified as the path returned by asset_upload_url. It still does not specify the exact string format or whether a bare filename is accepted, keeping it below 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 states a specific verb and resource: delete an asset. It also identifies the key input source, the path returned by asset_upload_url, which clearly distinguishes it from sibling tools such as list_assets, asset_upload_url, and transcribe_asset.

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 usage is implied by the tool name and the mention that fileName comes from asset_upload_url, but the description gives no explicit when-to-use guidance, no alternatives, and no exclusions or prerequisites.

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

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

No annotations are supplied, so the description carries the full burden of behavioral disclosure. "Delete" implies mutation and destruction, but the description says nothing about irreversibility, required permissions, cascade effects on associated assets, or error behavior for a nonexistent ID.

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

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

One short, front-loaded sentence with no wasted words, but the terseness is under-specification rather than efficiency. It fits easily in a glance but says almost nothing beyond the name.

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

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

For a destructive, unannotated tool with no output schema and an undocumented parameter, the description is not complete enough: an agent cannot tell whether the delete is recoverable, what happens to dependent assets, or how to obtain a valid brand_id.

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 parameter brand_id has 0% schema description coverage, so the schema defines only its type. The description adds no meaning about where the ID comes from (e.g., list_brand_kits or get_brand_kit) or its format, leaving the coverage gap uncompensated.

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?

"Delete a brand profile" gives a specific verb and resource, so an agent can infer this removes a brand kit. However, it uses "brand profile" rather than the tool's own "brand kit" vocabulary, and it never distinguishes itself from sibling deleters like delete_project or delete_asset beyond the resource name.

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

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

There is no statement of when to use this versus alternatives such as delete_project, and no mention of preconditions (e.g., whether the kit must be empty, whether capacities/assets are released). For a destructive operation, the absence of any when-to-use or caution context leaves everything 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?

No annotations are provided, so the description carries the full behavioral burden. 'Delete' signals a mutation, but the description says nothing about irreversibility, permission requirements, whether templates in active use can be removed, or what happens on a missing id — all material for a destructive operation.

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

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

A single front-loaded sentence with no filler; the verb and target appear immediately. Nothing is wasted, though brevity here coincides with under-specification.

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 delete with no annotations, no output schema, and an undocumented parameter, the definition is too thin. An agent cannot tell whether deletion is permanent, recoverable, or restricted, which is exactly the context a destructive tool needs.

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. 'By id' confirms that template_id identifies the target, but it adds no format, source, or lookup guidance (e.g. how to obtain the id via list_caption_templates).

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 ... caption template'), which clearly distinguishes it from save_caption_template, list_caption_templates, and apply_caption_template. The 'user-saved' qualifier adds useful scope, though it does not explicitly name the sibling alternatives.

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 such as apply_caption_template or save_caption_template, and no stated preconditions. The only implied usage is 'you have a template_id', which the schema already makes mandatory.

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

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

No annotations are provided, so the description carries the full disclosure burden for a destructive, high-consequence operation. It says nothing about whether deletion is permanent, whether associated assets or jobs cascade, what permission the caller needs, or what the response contains. With zero annotation support this is a critical 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?

It is one short sentence with no wasted words, but the brevity is the result of under-specification rather than efficient phrasing. Nothing is front-loaded 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 a destructive mutation with no annotations, no output schema, and an undocumented parameter, the description supplies nothing about safety, side effects, permissions, or returns. An agent cannot determine whether calling this is safe or what will happen.

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 parameter, project_id, has 0% schema description coverage, so the description is the only place semantics could be added. It says nothing about how to obtain a valid project_id, its format, or whether it must be an owned project, leaving the caller to guess.

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

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

The description restates the tool name almost verbatim: 'Delete a project' adds no information beyond the name 'delete_project'. It does identify the resource and the mutation type, but a sibling like delete_asset makes clear that this is generic naming; nothing here distinguishes it or clarifies what a 'project' is in this system.

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 delete a project, an explicit statement that the operation is irreversible, or what alternative exists. With siblings like create_project, get_project and list_projects, the agent could infer this is the destructive counterpart, but the description offers no context, prerequisites, or warning.

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

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

With no annotations provided, the description partially carries the behavioral burden by stating that the check is unauthenticated and targets LEVEA_API_URL. It does not explicitly state that the operation is read-only, what it returns, or whether it has any side effects, leaving gaps for a no-annotation tool.

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

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

Two short sentences deliver the key facts: what the diagnostic checks, the target endpoint, and the authentication expectation. There is no wasted text and the core purpose is front-loaded.

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

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

For a simple health-check tool this is minimally adequate: it identifies the endpoint and unauthenticated nature. However, because there is no output schema and no annotations, the description should ideally say what a successful or failed diagnosis returns or how failures surface.

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 and the schema is empty, so there are no parameter semantics to document. The description introduces no misleading parameter information, and the baseline for zero-parameter tools is appropriately met.

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 diagnostic purpose against a named endpoint (LEVEA_API_URL), so an agent can tell this is a health/connectivity check rather than an editing or asset operation. It does not explicitly differentiate itself from the many sibling tools, but no sibling provides a health diagnostic.

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 'Connectivity diagnostic' implies when to use it: checking whether the editor API is reachable. However, the description gives no explicit when-to-use guidance, prerequisites, or alternatives, so the usage condition 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the result may be empty ('if any') and that this is a non-mutating lookup implied by 'return', but it says nothing about required permissions, polling behavior, or what a returned task 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?

Two compact sentences, purpose front-loaded, no filler. Every clause contributes (subject, scope, and the reconnect use case).

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 lookup with no output schema and no annotations, this covers the essentials: what is returned, the scoping key, and the emptiness case. Missing only a hint about the returned task shape and its relationship to the status-checking siblings.

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

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

There is a single parameter with 100% schema coverage, so the baseline is 3. The description adds only that the id scopes to a project, which the schema already conveys via 'Project id.'

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 for a given project. The scope ('currently-running', 'if any') is precise. However, it doesn't distinguish itself from lookalike siblings such as check_task_status or check_job_status, so an agent can't tell them apart from this text 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?

'Useful for reconnecting MCP clients' gives an implied usage context but never states when to choose this over check_task_status or autonomous_edit. No exclusions or prerequisites are mentioned, leaving the agent to infer selection.

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

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

No annotations are provided, and the description adds zero behavioral context. It doesn't mention if the fetch is read-only, what happens if the ID is invalid, or any rate limiting behavior.

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

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

The definition is a single, tight sentence. It avoids any unnecessary fluff and front-loads the core function 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?

Given the lack of structured data (annotations/output schema), the description is only adequate as a bare minimum definition. It lacks the necessary context regarding potential errors or specific constraints needed for robust agent behavior.

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 0% schema description coverage, the description adds minimal value by merely stating the parameter is an 'id.' It does not elaborate on the expected format, type constraints, or domain specifics of the brand_id.

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 action (fetch) and the resource (brand profile), distinguishing it from sibling tools like 'list_brand_kits' and 'update_brand_kit'.

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 this tool should be used versus an alternative, such as when a list of kits is available in a sibling tool. No constraints or preconditions are mentioned.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Fetch' implies a read operation, but the description does not disclose permission requirements, behavior when the id is not found, or what a successful response 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?

The description is a single front-loaded sentence with no filler. It is tightly scoped to the tool's action, though its brevity leaves gaps that are penalized in other dimensions rather than here.

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

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

For a simple one-parameter read tool with no output schema, the description should at least indicate what is returned or how missing/invalid ids behave. It does not cover those points, and without annotations there is no safety or auth context to fall back on.

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 description only repeats that the lookup is 'by id' without specifying format, source, or validation expectations for project_id. The single parameter's name and required status are already in the schema, so the description adds little beyond that.

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

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

The description uses a specific verb (Fetch) and resource (one project) and states the lookup key (by id). It is clear that this is a single-resource read tool, though it does not explicitly distinguish itself from list_projects or create/delete_project by naming an alternative.

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 'by id' implies the calling condition: use this when you already have a project_id and need one project. However, the description does not explicitly say when to use this versus list_projects or other sibling tools, nor does it state 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?

With no annotations, the description is expected to carry the burden of disclosure. It provides no information regarding scope, rate limits, or specific behavioral traits beyond simple listing.

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

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

The definition is very concise, using two short sentences to convey the core function and primary parameter capability. It is efficient and readable.

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

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

Given the lack of an output schema, the description lacks completeness. It does not specify what information is returned for each asset (e.g., name, size, status), making the agent's expectation ambiguous.

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 description only mentions the 'projectId' filter. Since the schema defines 'fileType' as a second parameter/filter which is not mentioned in the description, the description fails to add value to the semantics of the full input structure. Coverage is weak.

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 defines the action (List) and the resource (user's uploaded assets). It distinguishes the intent from generic listing actions, although it does not explicitly name the sibling tools it is distinct from.

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 merely notes that a 'projectId' filter is optional. It offers no guidance on when to use this tool versus others (like `list_projects`) or under what conditions the filters apply.

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?

As no annotations are provided, the description must carry the full weight of behavioral disclosure. It provides necessary context about the complexity of the returned profiles (listing specific attributes like 'gradeBias'), which is helpful for the agent's internal reasoning.

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

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

The definition is highly efficient. It uses two sentences to define the content of the list and immediately explain the critical utility of the result for task flow.

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

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

Given the lack of an output schema, the description successfully provides the most critical piece of behavioral context: the nature of the data returned and its integration into the autonomous editing workflow. It is highly complete for a zero-parameter listing function.

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. Following the rule for zero parameters, a score of 4 is appropriate as there is no parameter semantics to assess.

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 explicitly states the verb ('List'), the resource ('the user's brand profiles'), and the specific content returned (palette, fonts, logo, etc.). It is clearly differentiated from sibling tools like 'get_brand_kit'.

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

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

It provides clear operational guidance by explaining the downstream use of the returned IDs—they must be passed to the 'autonomous_edit' tools. This tells the agent exactly when this output is useful for task completion.

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

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

With no annotations, the description carries the full burden; it partially discharges this by disclosing the return contents (slugs, display names, style summaries), which is valuable since there is no output schema. However, it says nothing about permissions, whether builtin templates are always included, ordering, or pagination behavior.

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

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

Two short sentences, zero waste, with the resource and scope front-loaded and the return shape immediately following. 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 simple zero-parameter read tool with no output schema, the description covers what is listed and roughly what comes back. It falls slightly short on whether results are ever filtered or ordered, but an agent has enough to call it correctly.

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

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

The tool takes zero parameters, so per the baseline this scores 4. The description adds no misleading parameter expectations, and the parenthetical 'builtin + saved' clarifies scope rather than parameters.

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

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

The description uses a specific verb ('List') with a precise resource ('the user's caption templates') and clarifies scope as builtin + saved. This distinguishes it from siblings like apply_caption_template, save_caption_template, and delete_caption_template, 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: an agent would infer this is the discovery step before apply_caption_template or delete_caption_template, but the description never states when to use it or what alternatives exist. No prerequisites or exclusions 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?

With no annotations, the description carries the full burden and discloses almost nothing beyond the verb. It doesn't state ordering, pagination, whether archived or shared projects appear, or what a caller should expect from an empty account — all relevant for a list operation.

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

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

A single front-loaded sentence with zero filler — it is efficient rather than padded. Brevity here reflects thin content covered under other dimensions, not wasted prose.

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

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

For a simple zero-param list tool this could be adequate, but with no output schema and no annotations the description should hint at the return shape (e.g. a collection of project objects with IDs). As written, the agent knows the verb but not what it gets back.

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. The description correctly implies no filtering inputs are available.

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' + 'projects') and scopes it to the user's own projects, so the operation is unambiguous. It does not distinguish itself from siblings like get_project or list_assets, nor does it say whether shared/archived projects are included.

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 get_project for a single project, nor any prerequisite or exclusion. The agent must infer that this is the browse-all counterpart to get_project from the sibling name 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?

No annotations are provided, so the description must carry the full behavioral disclosure; it does the most important part by stating the fire-and-forget contract, the immediate taskId return, and the polling follow-up. It omits failure/cancellation behavior and says nothing about the awaiting_approval resume 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?

There are three short sentences with no padding: the async contract comes first, the timeout trigger comes second, and the polling next step comes last. Each sentence earns its place, and the content is front-loaded.

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

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

For a 15-parameter tool with no output schema, the description covers the async contract and the polling path, which is the critical missing context. However, it does not position the tool against autonomous_edit or autonomous_edit_streaming, or against the awaiting_approval/workingMemory resume path, which is a substantial part of this tool's behavior.

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

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

Schema description coverage is 100%, and all 15 parameters are documented in the schema, including requirePlanApproval, workingMemory, and brandId. The description adds no parameter-level meaning beyond noting that a taskId is returned, so the baseline of 3 applies.

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

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

The description states that this is a fire-and-forget async editing path that returns immediately with a taskId, and it frames the tool's role clearly enough to distinguish it from synchronous edit tools. Sibling tools such as autonomous_edit and autonomous_edit_streaming are not named, so the statement that it is a 'different kind' of edit tool is only implied.

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?

This is where 'Use when the edit may exceed the MCP request timeout (long viral-clip generation, multi-format export)' appears, and it provides concrete triggers. It does not say when not to use this tool; for example, when to choose the streaming or synchronous sibling instead remains unstated.

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

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

No annotations are provided, so the description carries the full burden. It confirms creation/persistence but says nothing about auth requirements, name-collision behavior (overwrite vs error), whether an ID is returned, or whether the stored template is immutable once saved.

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. It is efficient, though it leaves room to add a differentiating clause without becoming 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 create operation with a nested object parameter, no annotations, and no output schema, the description is thin. An agent cannot tell whether the call returns the new template's identifier, what happens on duplicate names, or how this differs from save_current_caption_template.

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

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

Schema description coverage is 100%, so name, tags, and the nested style payload are already documented in the schema. The description adds no extra semantics about required name uniqueness or what fields style accepts, 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?

Clear verb+resource: 'Save a new caption template definition' states exactly what is created. It does not differentiate from the close sibling save_current_caption_template, leaving ambiguous which one an agent should pick when a template already exists in the editor.

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

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

The description gives no conditions for when to use this versus save_current_caption_template, apply_caption_template, or list_caption_templates. 'the user can re-apply later' hints at persistence but does not describe when this tool is the right call.

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

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

No annotations are provided, so the description carries the full behavioral burden for a write/create operation. It conveys point-in-time capture semantics, but says nothing about whether an existing template with the same name is overwritten, whether the operation is idempotent, what permissions are needed, or what happens if neither scene nor project_id is supplied.

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 the key qualifier ("currently applied") placed before the outcome. No filler, no redundancy with 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?

With no annotations and no output schema, the description is the only place to learn side effects and failure modes for this create operation, and it stays silent on both. The fully documented schema covers parameter meaning, but an agent still cannot tell how this differs operationally from save_caption_template or what the tool returns.

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

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

Schema description coverage is 100%, so all three parameters are already documented, and the schema itself notes that scene is an "alternative to project_id." The description's reference to "project / scene" lightly reinforces that either a project or an inline scene can be the source, but adds no format or constraint detail beyond the schema. 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?

"Snapshot the caption styling currently applied ... as a reusable template" gives a specific verb (snapshot) and a precise resource (currently applied caption styling), which meaningfully distinguishes it from save_caption_template (saves supplied styling) and apply_caption_template. However, it never names those siblings, so the differentiation must be inferred rather than read.

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 "currently applied" implies the trigger condition: use this when styling already exists on a project/scene and you want to preserve it. There is no explicit when-not guidance and no mention of save_caption_template as the alternative for authoring a template from scratch, so an agent must reason about the choice.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return payload (words + timing), which is helpful, but leaves out critical behavior: whether this is synchronous or queued as a job, whether it overwrites an existing transcript, what happens when transcription already exists, and any cost/latency implications of the word "Force".

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 no filler; the only weakness is that the compactness comes at the cost of the unexplained "Force" qualifier.

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

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

The tool is simple (2 params, flat schema) and the description names the output payload, but with no annotations and no output schema an agent still cannot tell whether invocation is synchronous or asynchronous, nor whether re-running destroys prior transcript data.

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

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

Schema coverage is 100%, with both fileName and language documented in the schema, so the baseline of 3 applies. The description adds nothing about how the language hint affects results or what happens if it is omitted.

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") and adds what comes back ("transcript words + timing"). "Force" hints it re-runs transcription regardless of existing state, but that nuance is never made explicit; still, no sibling tool does transcription, so the agent can identify 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 alternatives, no preconditions (does the asset need to be uploaded first? must it lack a transcript?), and no mention of related tools like check_job_status or check_task_status for tracking completion.

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

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

With no annotations, the description carries the full burden, and it leaves the most important behavioral question unanswered: is this a partial patch or a full replace of the kit body? It says nothing about whether omitted fields are cleared, what permissions/plan requirements apply, or what happens to assets referenced by the kit.

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

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

Two short sentences with no padding, and the identifying verb+resource lead. The second sentence is efficient shorthand, though it offloads explanation to a sibling schema rather than delivering it here.

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 mutation with nested objects, no annotations and no output schema, the definition is far too thin. An agent cannot determine update semantics (partial vs full), field meanings, or the result of the call without opening create_brand_kit's schema and 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?

Schema description coverage is 0% across 9 parameters, so the description must compensate and largely does not. It conveys only that brand_id is the identifier and that all other fields mirror create_brand_kit, leaving gradeBias, voiceTone, enforcement, forbiddenColors and the nested fonts/palette objects completely undefined.

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 by id'), which distinguishes it from create_brand_kit, get_brand_kit and delete_brand_kit. Minor friction: it calls the resource a 'brand profile' while the tool and siblings call it a 'brand kit', and it never says what aspects are updatable.

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 'existing' implies this is for modifying a kit that already exists, so the create-vs-update boundary is implicitly covered. However, it gives no prerequisites (does the agent need to call get_brand_kit first?), no exclusions, and no guidance on when to prefer create_brand_kit.

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