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

There are no annotations, so the description carries the full burden of explaining behavior. It discloses that this tool only returns a schema and implies that it does not execute tools by instructing the agent to call invoke_tool afterward. It does not cover error cases, but for an introspection tool this is adequate.

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

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

Two concise sentences provide the core behavior and the intended next action. There is no filler, repetition, or unnecessary detail.

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

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

For a one-parameter tool with no output schema, the description explains what is returned and how to continue the workflow. It could mention behavior for an invalid or unknown tool name, but the essential information for correct invocation is present.

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

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

The schema coverage is 100% and already documents the 'name' parameter with an example. The description adds only that the name should come from search_tools, which is helpful context but does not substantially enrich parameter understanding 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 clearly states the resource: 'full JSON input schema for one Premiere tool name.' It also distinguishes the tool from siblings by tying it to search_tools and instructing that invoke_tool should come next.

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 places the tool in a workflow: tool names come from search_tools, and after reading the schema the agent should call invoke_tool. It does not explicitly say when not to use this tool, but the sequential guidance is clear and actionable.

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. It says 'Run a Premiere tool' but does not disclose that this is an arbitrary passthrough capable of side-effecting operations like trim_clip, nor does it mention error behavior when the tool name is invalid.

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

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

Two sentences with the core purpose front-loaded. The host-limitation sentence is useful context but slightly jargon-heavy; still, every sentence earns its place and there is no filler.

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

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

The description covers the key prerequisite ('Use after search_tools') and exact-name matching. However, it omits guidance on using get_tool_schema to fetch the target tool's argument schema, and gives no return/error expectations despite having no output schema or annotations.

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

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

The input schema already documents both parameters: name is 'Exact tool name returned by search_tools' and arguments is 'Arguments for that tool'. The description reinforces exactness and ordering but does not add meaningful detail beyond the schema, such as how arguments should be structured per the target tool.

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 ('Run') with a specific resource ('a Premiere tool by exact name') and clarifies this is the generic execution entry point. Naming trim_clip and contrasting it with top-level MCP tools helps distinguish it from siblings like search_tools and get_tool_schema.

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

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

It explicitly says 'Use after search_tools', giving clear ordering guidance, and it explains the host limitation that makes invoke_tool necessary. However, it does not explicitly state when not to use this tool or mention alternatives like get_tool_schema for inspecting a tool's schema.

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 of behavioral disclosure. It confirms the read-only, listing nature and names returned fields, but it's vague about 'basic properties' and omits edge-case behavior (empty project, no open document, performance on large projects).

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 words. It states the action, scope, and result in one concise breath.

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 0-parameter listing tool, the description covers the essentials: scope ('all sequences in current project') and return shape (IDs, names, basic properties). The primary gap is the undefined 'basic properties' term, which matters more because there's no output schema to compensate.

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 zero parameters, the schema carries no semantics, so per the rubric the baseline is 4. The description appropriately spends its space explaining the return value instead, which is the only useful thing it could add.

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

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

The description uses a specific verb-resource-scope structure ('Lists all sequences in the current Premiere Pro project') and specifies the return payload (IDs, names, basic properties). It distinguishes itself from list_project_items naturally, though 'basic properties' is undefined and it doesn't explicitly disambiguate from get_sequence_structure/get_full_sequence_info.

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

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

No guidance is given on when to use this tool vs. the many siblings such as list_sequence_tracks, get_full_sequence_info, or get_sequence_structure. There are no exclusions, prerequisites, or alternative suggestions — a missed opportunity given the crowded sibling space.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It discloses several concrete behaviors: empty query lists categories, default 5 matches, and dual support for BM25 and regex searches. It does not explicitly state read-only status or output format, but for a search operation the disclosed behaviors provide meaningful transparency.

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

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

The description is four short sentences with no filler: purpose, usage instruction, empty-query behavior, and default limit. The critical 'use this instead' guidance is front-loaded, and every sentence earns its place.

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

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

Given no output schema and four optional parameters, the description covers tool selection rationale, query modes, the follow-up action, and important default/empty-query behavior. It does not specify the return shape, but the detail parameter schema fills that gap. This is sufficient for an agent to invoke the tool correctly in most cases.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that query and regex are alternative search modes and by revealing that an empty query produces categories—information not present in the schema. It repeats the default limit, but the added empty-query behavior justifies a score above baseline.

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

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

The description opens with a specific verb-resource pair ('Search the Premiere tool catalog') and names two concrete query mechanisms (BM25 natural-language or regex). It clearly differentiates this from siblings like invoke_tool and get_tool_schema, and the reference to the 280-tool MCP list explains its role as a discovery tool.

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

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

It explicitly instructs the agent to use this tool instead of expecting the full 280-tool MCP list, which is direct when-to-use guidance. It also tells the agent to follow up by calling invoke_tool, linking the search step to the execution step. While it doesn't enumerate exclusions in detail, the 'use this instead' phrasing is strong and actionable.

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 of behavioral disclosure, and it does well: it reveals that the tool may launch Premiere as a side effect, waits for the CEP panel, auto-starts the bridge, and exposes nextStep on failure. It does not describe the exact return shape or success/failure indicators, which would make it fully transparent.

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

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

Three sentences, each earning its place: purpose, behavior/wait semantics, and failure handling. The most important instruction ('call before any editing tool') is front-loaded, and there is zero filler or repetition.

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

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

For a one-parameter check tool with no annotations and no output schema, the description is complete: what it does, when to call it, what side effects it may trigger, and how to handle failure. The 'nextStep' reference even hints at the failure return shape. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%; the schema already fully documents launchIfNeeded including its default behavior and false-case meaning. The description refers to launching behavior but does not add parameter-level meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: a 'readiness check' for Premiere Pro and the MCP Bridge. It also frames itself as a prerequisite ('Call this before any editing tool'), which distinguishes it from the editing tools it precedes. The purpose 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?

Provides explicit when-to-use guidance ('Call this before any editing tool') and when-not-to-continue guidance ('If it fails... do not retry other tools'). It names the class of alternatives (editing tools) and instructs the agent to surface nextStep to the user instead. This is unusually actionable usage guidance.

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