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

With no annotations, the description carries full burden but only states the basic action. It does not disclose side effects (e.g., whether it replaces existing effects), error behavior on invalid names, or if any permissions are 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?

Single sentence with no wasted words. Front-loaded with the core action and effect identification method.

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

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

Despite 4 parameters and no output schema, the description lacks information on return values, success/failure indicators, handling of invalid inputs, or how to discover available effect names.

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 documentation covers all parameters with 100% coverage. The description adds minimal extra meaning (e.g., reiterating matchName vs display name) but does not compensate for any gaps. 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?

Description clearly states the verb 'Add' and resource 'any After Effects effect' to a layer, specifying two identification methods (matchName or display name). This distinguishes it from siblings like 'remove-effect' or 'list-available-effects'.

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 tool versus alternatives such as 'apply-effect' or 'apply-preset'. Lacks context about prerequisites or typical use cases.

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 exist, so the description carries the burden. It mentions 'Add a marker' (a write operation) and lists optional properties, but does not disclose behavior like overwriting existing markers, prerequisites, or side effects. Basic transparency is present.

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

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

Two sentences: first states the core action, second lists optional properties. No redundant information. Front-loaded with key action, concise and 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?

Given 10 parameters and no output schema, the description is functional but could be more complete. It does not explain the difference between layer and comp markers, which is critical for correct usage. With many sibling tools, more context would improve completeness.

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 baseline is 3. The description lists optional properties (comment, label, chapter, URL, duration) but does not add significant meaning beyond the schema. It does not clarify the difference between layer and comp markers or the relationship between layerName and layerIndex.

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 'Add a marker to a layer or composition at a specified time' with a clear verb and resource. It distinguishes from sibling 'add-markers-bulk' by implying single marker addition. The optional properties are listed, making the purpose specific.

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 when-to-use or when-not-to-use guidance is provided. The description implies use for single marker addition, but given sibling 'add-markers-bulk', explicit comparison would help. Context is implied but not clearly 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 provided, the description bears full responsibility for behavioral disclosure. It does not mention side effects (e.g., whether it appends or replaces existing markers), error handling, or permission requirements. This lack of detail is a significant gap 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?

The description is extremely concise at two sentences, with no unnecessary words. The key verb ('add') and object ('markers') are front-loaded, and the use case is efficiently stated.

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?

While the input schema is rich and covers parameters fully, the description lacks information about return values, potential failure modes, or limits on marker count. It is adequate for basic usage but incomplete for robust agent decision-making.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds minimal value beyond the schema, only hinting at integration with 'analyze-audio-waveform' output. It does not elaborate on parameter semantics further.

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 'Add multiple layer or composition markers at once,' which clearly distinguishes from the sibling tool 'add-marker' by emphasizing bulk addition. It also provides a specific use case ('after analyze-audio-waveform'), enhancing clarity.

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 advises using this tool after 'analyze-audio-waveform' or for any set of markers, giving clear context. It implies the alternative for single markers is 'add-marker,' but does not explicitly exclude other scenarios or state when not to use.

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 full burden. It mentions that compName is 'most reliable' and that templates must exist, but it does not disclose error behavior (e.g., if comp not found or template missing), whether existing output files are overwritten, or required permissions for adding to the render queue. For a mutation tool, this is insufficient.

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 three short sentences, with the purpose stated first. Every sentence adds necessary context: purpose, selection mechanism, and prerequisite. No extraneous words. Excellent conciseness.

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

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

The description adequately covers composition selection and template requirement, but it lacks information about return values, error handling, and confirmation that the item was added to the queue. Given the tool has 7 parameters and no output schema, some additional context about the outcome would improve completeness.

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%, but the description adds meaningful context beyond the schema: the priority between compName and compIndex, the fallback to active comp, and the prerequisite of template existence. This extra guidance justifies above the baseline of 3.

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

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

The description clearly states the action: 'Add a composition to the After Effects render queue and configure its output.' It identifies the specific resource (composition) and distinguishes from siblings like 'render-aerender' (external) and 'start-render' (likely begins rendering). However, it doesn't explicitly contrast with close siblings like 'render-queue' or 'start-render', which slightly reduces precision.

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

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

The description provides explicit guidance on selecting a composition: prioritize compName, fallback to compIndex, or leave both empty for active comp. It also notes that 'templates must already exist', a key prerequisite. It does not explicitly state when to avoid this tool versus alternatives, but the selection guidance is helpful.

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 provided, so description carries full burden. It discloses that uncompressed PCM WAV is read natively, other formats are transcoded via ffmpeg if installed, and mentions the AE_FFMPEG_PATH env var override. Also describes return values: normalized amplitude values (0-1) and peak times.

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

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

Three sentences with clear front-loading of purpose. The second sentence is instructional but not verbose. Could be slightly more structured, but overall concise with no wasted words.

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 no annotations, the description comprehensively covers dependencies, format handling, env var, and output structure. Addresses all needed context for agent to invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context: filePath should come from get-audio-info, numPoints default is 200 and max 100000. It also explains return values beyond schema, but the schema already covers parameter details well.

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?

Clearly states the tool analyzes audio to extract waveform amplitude data and detect peaks/transients. The verb 'analyze' paired with resource 'audio-waveform' is specific and distinguishes it from sibling tools like set-audio-levels or add-any-effect.

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 instructs to first call get-audio-info to obtain the sourceFilePath, then pass it here. Also details format handling (WAV native, others need ffmpeg) and env var override, providing clear when-to-use guidance.

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

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

With no annotations, the description carries the full burden. It explains key behavioral aspects like normalization with auto-detected input range, mapping to output range, response curve, and smoothing. However, it omits the default destructive behavior of clearing existing keyframes (clearExisting defaults to true in the schema), which is a significant side effect not disclosed in the description.

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 well-structured and front-loaded, starting with the core purpose and then progressively adding necessary detail. It is concise for the complexity, covering input modes, normalization, and targeting in a few sentences without unnecessary fluff, earning its length.

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

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

Given the tool has 22 parameters with comprehensive schema descriptions, the description provides a solid high-level overview that ties concepts together. It covers the main usage patterns and normalization logic, but could mention default behaviors like clearExisting and the max 2000 points limit (though that is in the schema). Overall, it is adequate for a complex tool with rich schema support.

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 baseline is 3. The description adds significant meaning by explaining the normalization logic that ties inputMin/inputMax to outputMin/outputMax, and clarifies the relationship between data vs values+interval modes. It also introduces the concept of targeting effect properties, enriching the schema's existing parameter descriptions.

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

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

The description clearly states it 'Generate After Effects keyframes for a layer property directly from an arbitrary numeric data series', specifying the action, resource, and input type. It also distinguishes itself from the sibling tool animate-to-audio by explicitly stating 'not audio; see animate-to-audio for that', providing clear differentiation.

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

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

It provides explicit usage guidance by contrasting with animate-to-audio and explaining the two mutually exclusive input modes (data vs values+interval). It also clarifies when to target effect properties versus plain layer properties, offering clear when-to-use and when-not-to-use instructions.

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?

Despite no annotations, the description discloses key behavioral traits: it modifies layer properties (creates keyframes), clears existing ones by default, handles multiple audio formats, and explains mode-specific behaviors (e.g., peaks mode keyframe count depends on transients). It lacks explicit mention of whether the operation is reversible or if it has side effects beyond keyframe creation.

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 dense paragraph that covers all essential information without unnecessary repetition. However, a more structured format (e.g., bullet points for modes) could improve readability for agents, especially given the parameter complexity.

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

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

The tool has 22 parameters, two modes, and nested objects, but no output schema. The description explains parameter usage and mode differences thoroughly but omits what the tool returns (e.g., success/failure, keyframe count). This gap may leave agents uncertain about how to verify the tool's effect.

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 coverage, the description still adds substantial value by explaining parameter interactions (e.g., numPoints for waveform vs peaks, smoothingWindow only for waveform), providing examples ('ADBE Opacity'), and clarifying ambiguous fields like propertyPath and effect selectors. This goes well beyond the schema's concise descriptions.

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

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

The description clearly states the tool's purpose: generating After Effects keyframes from an audio waveform in one call, directly contrasting with the sibling tool 'analyze-audio-waveform'. It uses specific verbs ('Generate... keyframes') and resource ('layer property from audio file'), making it unmistakable.

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

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

The description explicitly compares two modes ('waveform' and 'peaks') with real-world examples (VU-meter, beat-pop), and explains when to use this tool over the sibling 'analyze-audio-waveform'. However, it does not explicitly state when not to use it or list alternative tools for other scenarios, slightly reducing clarity.

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 carries the full burden of behavioral disclosure. It merely says "Apply an effect" without mentioning side effects (e.g., overwriting existing effects), required state (e.g., composition must exist), or behavior when parameters conflict (e.g., both effectName and effectMatchName provided). This is a severe omission.

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 consists of a single sentence that directly states the action. It is front-loaded and avoids unnecessary words. However, efficiency does not compensate for the lack of content, slightly reducing the score from a perfect 5.

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

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

Given the tool's complexity (9 parameters, many siblings, no output schema), the description is far from complete. It does not explain what the tool returns, how it handles multiple effect identifiers, or what happens when a preset path is combined with effect parameters. Essential context for correct invocation is missing.

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

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

While the input schema has 100% coverage with descriptions for each parameter (e.g., effect: "Generic effect identifier"), the tool-level description does not add any extra context or clarify parameter relationships. For example, it does not explain the precedence among effect, effectName, effectMatchName, and effectIdentifier. 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 "Apply an effect to a layer in After Effects" clearly states the verb (apply) and resource (effect to layer), making the tool's purpose understandable. However, it does not differentiate from sibling tools like "add-any-effect" or "apply-preset", which could cause confusion.

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

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

The description provides no guidance on when to use this tool versus alternatives such as "add-any-effect", "apply-effect-template", or "apply-preset". There is no mention of use cases, prerequisites, or exclusions, leaving the agent without decision-making support.

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 carries full burden for behavioral disclosure. It fails to mention whether applying a template replaces or merges existing effects, if there are side effects on layer properties, or error conditions (e.g., invalid template name). This is insufficient 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?

Single sentence, no redundant information, efficient and front-loaded with the core action. Every word contributes value.

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 4 parameters including a nested object and no output schema, the description is too sparse. It omits critical context: what constitutes a template, how to discover available templates, the role of customSettings, and expected return values or confirmation. The agent lacks enough info to use the tool correctly.

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

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

Schema coverage is 100% with adequate property descriptions. The description adds no additional meaning beyond the schema, which already documents all parameters. Baseline of 3 is appropriate as the schema does 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 clearly states the action (apply) and resource (predefined effect template) and target (layer in After Effects). It is specific and distinguishes from sibling tools like apply-effect and apply-preset, but does not explain what a 'template' is versus a preset or raw effect, preventing 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?

No guidance on when to use this tool vs alternatives such as apply-effect or apply-preset. The description does not specify prerequisites, appropriate contexts, or exclusions, leaving the agent without decision criteria.

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 alone must disclose behavioral traits. It only says 'apply', omitting details such as whether the preset overwrites existing effects, side effects on the layer, required permissions, or error handling for invalid preset paths. This is insufficient 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?

The description is a single sentence that is front-loaded with the core purpose. It contains no superfluous words or tangential information, making it highly concise and 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?

Given the tool's simplicity (applying a preset file), the description is minimally adequate. However, it lacks information about return values (likely void), success indicators, or behavioral details that would help an agent understand the outcome. With no output schema, the description should be more complete.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond 'to a layer', which is already implied by the 'layerIndex' parameter. Therefore, the baseline score of 3 applies, as the description provides minimal added 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 clearly states the action (apply), the resource (After Effects .ffx preset file), and the target (layer). It effectively distinguishes from sibling tools like 'apply-effect' (which applies an effect directly, not a preset file) and 'apply-effect-template' (different format).

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

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

The description provides no guidance on when to use this tool versus alternatives. It lacks information about prerequisites (e.g., layer must be compatible), when not to use, or suggestions for related tools like 'list-presets' or 'search-presets' to find preset paths.

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 full burden. It discloses that setting position clears existing keyframes first, a critical behavioral trait. However, it does not mention behaviors for other properties (e.g., whether scale or rotation also clear keyframes).

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, front-loaded with purpose and list, followed by a crucial behavioral note. No wasted words; every sentence earns its place.

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

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

For a batch operation with no output schema and no annotations, the description covers the basic functionality but omits details like return values, partial failure handling, or error conditions (e.g., layer not found). Adequate but not fully comprehensive.

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 parameters are already well-described. The description adds value by noting the keyframe-clearing behavior for position, which goes beyond the schema. The list of settable properties also reinforces parameter meanings.

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 it sets transform/visibility properties on MANY layers in one call, listing the specific properties (threeDLayer, position, etc.) and targeting methods (layerIndex or layerName). This distinguishes it from sibling tools that operate on single layers or single properties.

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

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

The description implies batch usage by emphasizing 'MANY layers' and listing what can be set, but does not explicitly state when not to use or mention alternatives. It provides clear context for when to use it over single-layer tools.

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

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

The description fails to disclose critical behavioral traits such as whether centering affects keyframes, works on 3D layers, or permanently modifies position. With no annotations, the burden is entirely on the description, which is insufficient.

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 extremely concise at 10 words, with no wasted language. However, it lacks structure (e.g., grouping parameters by function) that could improve readability. Still, it earns a high score for efficiency.

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 5 parameters, no annotations, and no output schema, the description is too sparse. It doesn't explain return behavior, error handling, or edge cases (e.g., no layers selected). The agent lacks enough context to invoke the tool reliably in all scenarios.

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 each parameter already has a description. The tool description adds minimal extra meaning, implying that layerName/layerIndex target a single layer while allLayers/selectedOnly control scope. Baseline 3 is appropriate as schema does the heavy lifting.

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

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

The description uses a specific verb ('center') and resource ('layers'), and clearly defines the scope: 'one layer, selected layers, or all layers'. It effectively distinguishes this tool from sibling tools like 'add-marker' or 'delete-layer' which perform different actions.

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 provided on when to use this tool versus alternatives, or when not to use it. It doesn't clarify parameter interactions (e.g., what happens if both layerName and allLayers are specified) or prerequisites like ensuring a composition exists.

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

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

The description discloses what the tool checks and reports (version, bridge folder, open project/active comp) and implies it is read-only with no destructive actions. With no annotations, it carries the full burden and does so well, though it could explicitly state it is non-destructive.

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 packed with purpose and usage guidance. Front-loaded and no wasted words.

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 parameters, no output schema, and no annotations, the description covers the tool's purpose, expected outputs, and troubleshooting context. It could detail the return format but is adequate for a simple health check.

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

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

The input schema has zero parameters, so the description adds no parameter semantics beyond the schema. Baseline 4 for 0 parameters is appropriate.

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

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

The description clearly states the tool performs a health check on the After Effects MCP Bridge, verifying its panel is open and responding and reporting version and project info. It distinguishes from siblings like run-bridge-test and get-help by being the first diagnostic 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?

Explicitly instructs 'Run this FIRST when anything times out or behaves oddly' and provides a recovery action for version mismatches, giving clear when-to-use guidance and 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?

Without annotations, the description carries the full burden of behavioral transparency. It states that the tool renders frames and composites them into a single image, implying a non-destructive read operation. It does not mention side effects, auth needs, or rate limits, but the behavior is straightforward and clearly described. A score of 5 would require explicit statements about no side effects or read-only nature.

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 extremely concise (two sentences) and front-loaded with the main purpose. The first sentence states the action and outcome, the second provides usage context and a use case. Every sentence is necessary and earns its place.

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

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

Given the tool's simplicity and full schema coverage, the description is fairly complete. It explains what the tool does, how to select the composition, and the purpose. However, it omits details about the output image format (e.g., labeling scheme, grid layout) and does not mention that it is a read-only operation. With no output schema, these details would be helpful.

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 baseline is 3. The description adds minimal extra value: for 'comp' it explains it can be omitted for active comp, and for others it restates schema info. It does not provide additional context beyond what the schema already describes, such as examples or constraints.

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

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

The description clearly states the tool's purpose: rendering N frames sampled across a composition's duration and compositing them into a single labeled thumbnail grid. It uses specific verbs ('render', 'composite') and resource ('composition timeline') and distinguishes from sibling tools like 'see-frame' by emphasizing the overview nature ('one image instead of many').

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

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

The description provides clear usage context: it is for perceiving motion, timing, and easing cheaply. It explains how to select the composition (by name, index, or leave empty for active comp). However, it does not explicitly state when not to use this tool (e.g., for high-resolution frames or specific frame extraction) or mention alternative tools, though siblings are available.

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 bears full burden. It does not disclose side effects, permissions, or system impacts. For a mutation tool, this is insufficient.

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 concise sentence with no wasted words. However, it could be slightly more detailed without losing conciseness.

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

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

With 6 optional parameters, no annotations, and no output schema, the description lacks essential context such as return behavior, error handling, and parameter usage beyond names. It is incomplete for a mutation tool.

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

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

The input schema has 100% coverage with inline descriptions for each parameter. The tool description adds no additional meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states the action ('Create') and the resource ('adjustment layer'), with a qualifier ('in the specified composition or active comp'). It distinguishes from sibling tools like 'create-camera' or 'create-text-layer'.

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 tool over alternatives (e.g., other layer creation tools or effects). The description does not mention prerequisites, conditions, or when not to use it.

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

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

No annotations are provided, so the description bears full responsibility. It only states the creation action and selection method, but fails to disclose side effects (e.g., whether it modifies the active comp), error handling (e.g., if compName doesn't exist), or system impacts. Essential behavioral traits are missing.

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 sentence with a clarifying clause, making it concise and front-loaded. It avoids unnecessary words, but could benefit from slightly more structure (e.g., separating selection options from creation act).

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 7 parameters and no output schema, the description should at least hint at return values (e.g., the created camera layer). It also lacks behavioral completeness (e.g., default positions, interaction with existing layers). The description is adequate for a simple creation tool but not fully 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 100%, providing baseline of 3. The description adds value by explaining the composition selection logic (compName/compIndex/active comp fallback), which is not fully captured in the schema. However, other parameters like 'zoom' or 'position' remain schema-dependent without extra 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?

The description clearly states the action ('Create a camera layer') and the resource ('in a composition'). It distinguishes from sibling tools like 'create-adjustment-layer' or 'create-text-layer', making the purpose unambiguous.

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

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

The description explains how to select the composition (by compName, compIndex, or active comp), providing clear context. However, it lacks explicit guidance on when not to use this tool or alternatives for similar tasks (e.g., using 'create-adjustment-layer' for other layer types).

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 provided; the description does not disclose side effects (e.g., whether the comp is opened in the timeline), required project state, or error conditions. It only states what the tool does, not behavioral traits.

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?

Single sentence, no filler. However, the brevity sacrifices detail that would improve completeness. Still well-structured for its length.

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 and description omits return value, prerequisites (must have an After Effects project open), and default behaviors. For a tool with 7 parameters including nested objects, this is insufficient.

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 descriptions for all 7 parameters. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the action ('create') and the resource ('a new composition') within the context of After Effects. It distinguishes from sibling tools like 'create-text-layer' or 'create-camera', but could be more explicit about the scope (e.g., creation vs modification).

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

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

No guidance on when to use this tool versus alternatives (e.g., 'set-composition-properties' for existing comps). No prerequisites or exclusions 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 provided, so description must bear full burden. It discloses auto-direction and alignment behavior, but omits side effects (e.g., error handling for invalid comp, layer naming, or potential overwriting). Lacks discussion of performance or undo impact.

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: first states core function, second adds key behavioral detail. No redundant information. Efficient and 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?

Given 10 parameters and no output schema, description covers core behavior and Arabic support well. Lacks info on return values, error cases (e.g., invalid comp), and layer naming conventions, but adequate for a creation tool of moderate complexity.

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

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

Schema coverage is 100%, so parameters are well-documented. Description adds value by explaining auto-direction defaults and Arabic font recommendations, which are not in schema. Some defaults like position and font size are mentioned, enhancing clarity beyond raw 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?

Description uses specific verb 'Create' and resource 'text layer', adds Arabic/RTL support detail, and distinguishes from sibling creation tools like create-composition. Clearly states it works on After Effects.

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?

Description implies when to use (when creating a text layer, especially with Arabic/RTL), but does not explicitly state when not to use or mention alternatives. It provides direction auto-detection context but lacks exclusion cues.

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 present, so the description bears full burden. It correctly labels the action as destructive but omits details about side effects (e.g., irreversible, effect on subsequent layers) or error handling (e.g., missing layer or ambiguous targeting). Minimal disclosure beyond the core action.

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 redundancy. Every word adds value. Efficient structure.

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 low complexity and complete schema, the description covers the essential usage. Missing return value explanation, but not critical for this simple destructive tool. Overall 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 baseline is 3. The description adds 'Target the layer by layerIndex or layerName' which reinforces the alternative targeting, but does not provide new semantic meaning beyond the schema descriptions.

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

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

The description clearly states the action (delete), the resource (layer from a composition), and the targeting methods (by layerIndex or layerName). It distinguishes this tool from siblings, which focus on adding, setting, or inspecting layers.

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 when-to-use or when-not-to-use guidance is provided. However, the purpose is straightforward, and there are no sibling tools for deletion, so usage is implied. Lacks contrast with alternatives or prerequisites like requiring composition existence.

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 full burden. It does not specify what happens to the duplicated layer (e.g., position, effects, transformations) or behavior when both layerIndex and layerName are provided.

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

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

Two sentences with no unnecessary words. Front-loaded with the core action and optional renaming, then targeting methods.

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?

Moderately complete for the core task, but lacks details about duplication behavior (placement, properties) and no output schema. With 5 parameters and no annotations, more context would help.

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%, baseline is 3. Description adds context that renaming is optional and targeting can be by index or name, adding some value beyond the schema.

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

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

Clearly states the action ('Duplicate a layer in a composition') and the resource (layer). Distinguishes from sibling tools like delete-layer or create-text-layer.

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 clear context for when to use (duplicate a layer) and mentions optional renaming. Does not explicitly state exclusions or alternatives, but the purpose is self-evident.

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

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

No annotations are provided, so the description bears full responsibility. It explains the execution environment (function body), error handling (message and line number), and that the script runs inside an undo group. It implies destructive potential by calling it 'the most powerful tool', but could be more explicit about possible side effects.

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

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

The description is a single, well-structured paragraph. It front-loads the main purpose and provides details without redundancy. Every sentence adds value, covering usage, constraints, and examples. It is concise yet comprehensive.

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

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

Given the tool's complexity (arbitrary code execution) and the absence of an output schema, the description thoroughly explains input parameters, return value expectations, error handling, and execution context. It includes a practical example, making it complete for an AI agent to use.

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 significant value beyond the schema: it explains the script parameter runs as a function body, provides an example, and clarifies timeoutMs for long-running scripts. This enriches understanding.

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

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

The description clearly states the tool executes arbitrary ExtendScript in After Effects and returns results. It explicitly distinguishes itself from sibling tools by stating it covers anything not covered by dedicated tools, listing many examples like masks, track mattes, 3D layers, etc.

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

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

The description provides explicit guidance: 'use it for anything the dedicated tools do not cover', implying when to use it. It also gives usage instructions like running as a function body, returning JSON-serializable values, and not calling app.beginUndoGroup. This effectively separates it from sibling tools.

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

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

The description clearly indicates a read-only retrieval operation ('Get'), listing the exact data returned. Since no annotations are provided, the description adequately discloses the tool's behavior without contradictions.

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?

Single, concise sentence that is front-loaded with the action and resource, containing no redundant 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?

Given the moderate complexity (3 parameters, no output schema), the description adequately lists all returned data types (metadata, source file path, markers, keyframes), providing sufficient context for an agent to understand what the tool does.

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 does not add additional meaning beyond the schema; it only lists what the tool retrieves without explaining parameter usage or constraints.

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 verb 'Get' and the resource 'audio metadata, source file path, existing markers, and audio level keyframes for a layer in After Effects', which is specific and distinguishes it from siblings like 'analyze-audio-waveform' or 'set-audio-levels'.

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 tool versus alternatives (e.g., analyze-audio-waveform). The description implies it's for retrieving audio info but does not provide context for when to choose it over other tools.

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

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

No annotations are provided, and the description does not disclose any behavioral traits such as whether the tool returns text, opens a browser, or performs any side effects. This is a significant gap for a help 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?

The description is extremely concise at one sentence, with no wasted words. It is front-loaded and directly states the 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?

Given that there is no output schema, no annotations, and the tool has no parameters, the description is too minimal. It does not explain what the output format is or how to interpret the help, leaving the agent with insufficient context.

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

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

The tool has no parameters, and the schema coverage is 100%. The description does not need to add parameter information. Baseline score of 4 is appropriate.

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

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

The description clearly states the tool's purpose is to get help on the After Effects MCP integration. It is specific about the resource (After Effects MCP) but could be more precise about the type of help provided.

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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives like 'get-results' or 'mcp_aftereffects_get_effects_help', nor does it give context on prerequisites or limitations.

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 exist, so the description must carry the burden. It lists the returned data but does not disclose any side effects, permissions, or error handling behavior. It adds value beyond the schema by explaining the output.

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?

Single sentence that is clear and free of unnecessary words. It is front-loaded with the essential information.

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

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

With 3 parameters, no output schema, and no annotations, the description is minimal. It could be improved by specifying the return format or behavior when inputs are invalid.

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 baseline is 3. The description does not add additional meaning beyond the schema for parameters; it only summarizes what the tool returns.

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 specifies the verb 'Get', the resource 'layer's clip frames', and details what is returned (start/end frames, source frame range, duration). It clearly distinguishes from sibling tools like 'inspect-layer' or 'get-audio-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 explicit when-to-use or when-not-to-use guidance is provided. While the context implies it's for clip frame information, it doesn't mention alternatives 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?

With no annotations, the description carries full burden. It discloses that results are from the last script executed, implying a read-only operation. However, it lacks details on behavior when no script has been run or if results are cleared, leaving some transparency gaps.

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 concise sentence (11 words) that front-loads the core functionality with zero waste. Every word is necessary.

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, the description should explain the format or type of results returned. It does not, leaving a completeness gap. Also missing mention of prerequisites like script execution. For a simple tool with no parameters, the description is too sparse.

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

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

The input schema has 0 parameters with 100% schema description coverage. The description adds value by explaining the tool's purpose, which is sufficient given no parameters to document.

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 verb 'Get' and the resource 'results from the last script executed', which precisely defines the tool's functionality and distinguishes it from siblings like execute-script or run-script.

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 implicitly suggests using this tool after executing a script, but it does not explicitly state when to use it, alternatives, or any prerequisites like needing a prior script execution.

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 discloses batch error handling ('Files that don't exist are reported individually without failing the rest of the batch'), which is helpful. However, it does not mention success behavior, side effects (e.g., project panel updates), or whether items are always newly created. This is partial transparency, not comprehensive.

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 sentence that is clear, front-loaded with purpose, and includes a crucial behavioral note about error handling. No fluff or redundant 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?

Given the moderate complexity (batch import, optional sequence, folder placement) and the lack of annotations, the description covers key behavior (batch error handling) and ties to usage context. It could mention return values, but no output schema exists and the tool is straightforward. The description is sufficiently complete for an agent to use it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add extra parameter semantics beyond what the schema provides. 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 a specific verb+resource: 'Import one or more files into the project as footage items.' It also clarifies the intended use ('ready to use as a layer source or in populate-template's footage bindings'), which differentiates it from sibling tools like relink-footage and create-composition.

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

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

The description implies clear usage context by mentioning the items are for layer sources or populate-template bindings, but it does not explicitly say when not to use it or contrast with alternatives like relink-footage. Still, the purpose is distinct enough that the guidance is adequate.

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 disclose behavior. It describes in detail the output (comp settings + layer summaries with many fields) and the selection mechanism. It does not mention side effects, but it implies a read-only operation. The description is transparent about what the tool returns, which is sufficient.

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

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

The description is two sentences, but the first is a very long list. It is front-loaded with the key information. The structure is logical: output description, then usage guidance. Could be slightly more concise, but it earns its sentences.

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, the description fully explains the return values with a comprehensive list. The two parameters are optional and the selection logic is clear. The sibling tools are mentioned via 'inspect-layer' differentiation. It is complete for an overview tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds 'leave both empty for the active comp' and clarifies the 1-based index, adding meaning beyond the schema properties descriptions.

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

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

The description states it maps a composition's settings and every layer with a useful summary, listing specific attributes. It clearly distinguishes from the sibling tool 'inspect-layer' by indicating that this is for an overview and 'inspect-layer' is for one layer's full detail.

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 this to navigate a comp and decide what to edit, then call inspect-layer for full detail. This provides when-to-use guidance. It also explains how to select the comp (by name, index, or leave empty for active comp). No explicit when-not, but the context is clear enough.

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 transparency. It details the information returned (type, enabled, properties, effects, masks, etc.), implying a read-only operation. It does not explicitly state that it is non-destructive, but the context 'SEE its exact state' suggests inspection. No contradictions, but lacks explicit behavioral traits like rate limits or security requirements.

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

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

The description is a single paragraph that packs a lot of information without fluff. Every sentence contributes to understanding the tool's output and usage. However, it could be better structured with bullet points for readability, especially given the long list of returned properties.

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

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

Despite having no output schema, the description comprehensively lists what the tool returns: type, enabled state, in/out points, transform properties with keyframes, effects, masks, markers, source, and text details. It also covers parameters for keyframe limits. Missing details on error handling (e.g., if layer not found) but overall complete for a read-only inspection tool.

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

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

The input schema covers 100% of parameters with descriptions. The description adds context on how to use the parameters (e.g., 'Select the comp by compName/compIndex (or active comp) and the layer by layerIndex or layerName') and explains defaults for maxKeyframes and includeKeyframes. This goes slightly beyond the schema but does not add substantial new meaning.

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

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

The description clearly states the tool's purpose: 'Deeply inspect ONE layer' to see its exact state before making edits. It specifies the resource (a single layer) and the action (inspect). This distinguishes it from sibling tools like 'inspect-comp' which inspects a composition, not a layer.

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 indicates when to use the tool ('before making precise edits') and provides guidance on selecting the comp and layer via compName/compIndex and layerIndex/layerName. However, it does not explicitly state when not to use it or compare with alternative inspection tools like 'inspect-comp' or 'list-layer-effects'.

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 notes the tool lists effects with an optional filter, but does not explicitly state that it is read-only, has no side effects, or describe any performance implications. While the name implies a safe operation, more transparency would be beneficial.

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 sentence that immediately states the purpose and optional filter. It is efficient, front-loaded, and contains no redundant information.

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

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

With no output schema and no annotations, the description should explain what the returned data contains (e.g., effect names, match names, categories). It does not, leaving the agent to infer the output format. For a simple list tool, this is a noticeable 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%, so the schema already documents all three parameters (query, maxResults, includeObsolete) well. The description adds minimal value beyond summarizing the filter functionality, but does not introduce new semantic clarity.

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 'List all effects available in this After Effects installation', clearly defining the scope (all effects installation-wide) and distinguishing it from sibling tools like list-layer-effects which list effects on a specific layer.

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 does not provide explicit guidance on when to use this tool versus alternatives such as apply-effect or add-any-effect. It is implied that this is for browsing available effects before applying them, but no direct comparison or when-not-to-use advice.

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 full responsibility for behavioral disclosure. It states the tool lists effects and optionally includes property details, but fails to describe the return format, whether effects are ordered, or the behavior when parameters are omitted. This leaves significant uncertainty for an AI agent selecting or invoking the 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?

The description is concise at 9 words, front-loading the core purpose. It avoids unnecessary words, but could benefit from slightly more detail without sacrificing brevity, such as mentioning that effects are listed as an array of effect objects.

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

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

The tool has 5 parameters and no output schema. The description does not explain what the tool returns (e.g., a list of effect names, IDs, or full objects). It fails to provide enough context for an AI agent to fully understand the input-output behavior, making it incomplete.

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 adds no new meaning beyond what the schema already provides for parameters like includeProperties and maxDepth. The phrase 'optional recursive property details' loosely hints at these parameters but does not enhance understanding.

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 verb 'List' and the resource 'effects on a layer', specifying the primary action. The phrase 'with optional recursive property details' adds specificity, distinguishing it from a simple enumeration. However, it does not explicitly differentiate from sibling tools like 'inspect-layer' or 'list-available-effects', which have overlapping functions.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where other tools like 'inspect-layer' would be more appropriate, nor does it suggest prerequisites or conditions for effective use.

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 burden. It only states the purpose, missing details like return format (file paths? names?), ordering, or any side effects. The behavioral traits are under-disclosed for a tool with no annotations.

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

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

Single sentence that is front-loaded and contains no unnecessary information. Every word earns its place.

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

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

The tool has 4 optional parameters, no output schema. The description covers the basic scope but does not explain return values or format. For a listing tool, it is minimally complete but lacks detail needed for optimal agent usage.

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 adds no extra meaning beyond the schema; it repeats the idea of folders but not specifics of parameters. No additional 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 clearly states the verb 'list' and the resource 'After Effects .ffx presets', with scope 'from common or provided folders'. This distinguishes it from sibling tools like 'search-presets' which would involve filtering or querying.

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 tool versus alternatives like 'search-presets' or 'apply-preset'. Usage is implied by the description: listing presets from folders. For a simple tool, this is adequate but lacks explicit when/when-not 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 description implies a read-only operation but does not explicitly state side effects or permissions. Given the absence of annotations, it carries the burden well by describing the returned data and the intended use, which are sufficient for typical listing behavior.

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

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

The description is concise, two sentences, and well-structured. It packs purpose, differentiation, and usage examples without redundancy, making it easy to parse.

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 provides sufficient context: what the tool returns (including source paths, missing status, and IDs), and typical use cases. While there is no output schema, the description hints at key fields, making it fairly complete for a list operation.

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 descriptions already cover each parameter effectively (type, limit, missingOnly). The tool description adds minimal extra semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: listing items in the project panel with detailed attributes. It explicitly differentiates from getProjectInfo by highlighting the full, filterable nature and the ability to find broken links and relink footage.

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

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

The description provides explicit when-to-use guidance: finding broken links before render and looking up footage IDs for relink-footage. It also contrasts with getProjectInfo, indicating when not to use this tool (when summary-only is sufficient).

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 fully discloses key behaviors: duplication preserves originals, nested precomps are safely duplicated, Arabic detection and RTL alignment, and non-text layers unchanged. This meets the full burden.

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, well-structured paragraph of four sentences. Each sentence serves a purpose: core action, preservation of other content, nested precomp handling, and caller responsibility. No redundancy or 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 input, behavior, nesting, and caller duty. However, it does not explicitly state that the duplicated composition appears in the project (implied by 'create'), nor mention error conditions for missing layers or invalid paths. For a tool with no output schema and moderate complexity, this is very good but slightly incomplete.

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%, but the description adds significant context: explains path resolution, safe duplication, default behaviors (active comp if omitted, name defaults), and interaction between layerName/layerIndex vs path. This enriches 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 tool creates a localized duplicate of a composition by swapping translated text, preserving other layers/effects. It distinguishes from siblings like create-text-layer by specifying the duplication aspect and nested path handling.

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 explains the caller's responsibility for translation and mentions auto-detection logic, but lacks explicit comparison to sibling tools for when to use alternatives. The guidance is clear but not comprehensive in differentiating usage scenarios.

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 alone must convey behavioral traits. It mentions rendering the current frame and returning outputs, but does not disclose whether rendering has side effects (e.g., cache, project modification), auth needs, or rate limits. The description is moderately transparent but lacks full disclosure.

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

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

The description is two sentences, front-loaded with the primary action and output, followed by concise parameter guidance. Every sentence earns its place with no superfluous words.

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 4 parameters and no output schema, the description covers the main workflow and parameter usage. It lacks details on error handling (invalid path, missing comp) but is sufficient for typical use.

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%, baseline is 3. The main description adds context for the 'referencePath' (on-disk image path) and 'comp' (omit for active comp), but the schema already provides clear parameter descriptions. The description does not significantly enhance understanding beyond what the schema provides.

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

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

The description clearly states the tool compares a composition against a reference image, rendering the current frame and returning a side-by-side comparison and a difference map. This specific verb-resource mapping distinguishes it from sibling tools like 'see-frame' or 'inspect-comp'.

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 explains when to use the tool (to see deviations from a reference) and how to specify the reference path and composition. However, it does not explicitly mention when not to use it or suggest alternatives, which would merit 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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. However, it only states the purpose without describing what happens when invoked (e.g., return format, side effects, required permissions). For a tool with zero annotation coverage, this is insufficient.

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 sentence with no wasted words. It is appropriately concise for a simple tool. However, it lacks any structural elements (e.g., headings, examples) that might aid readability. Still, it earns a high score for brevity.

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 absence of an output schema and annotations, the description should compensate by explaining what help is returned (e.g., text, links, tutorials). The current description is too brief to provide complete context for an agent to understand the tool's full behavior and output.

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

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

The input schema has no parameters and schema description coverage is 100% (vacuous). According to the rubric, a baseline of 3 applies when coverage is high. The description adds no parameter-specific information, but none is needed. The score reflects adequacy without additional 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 'Get help on using After Effects effects' clearly states the verb ('get help') and the resource ('After Effects effects'). It indicates that the tool provides assistance or documentation, though it lacks specificity about the type of help (e.g., parameter descriptions, tutorials). This is better than vague or tautological descriptions but does not fully distinguish from related tools.

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

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

The description provides no guidance on when to use this tool versus its siblings, such as 'get-help', 'list-available-effects', or 'list-layer-effects'. There are no explicit when-to-use or when-not-to-use conditions, leaving the agent to infer the context from the 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?

With no annotations provided, the description fully carries the transparency burden. It discloses non-destructive behavior ('safely duplicated per row (never edited in place)'), RTL auto-detection, file import behavior, and precomposition duplication logic. This gives the agent a solid understanding of side effects and system interactions.

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, information-dense paragraph. It is logically structured: purpose, capabilities, precomp behavior, and recommended follow-up action. Every clause adds value, with no filler. While it could be broken into bullet points, the flow is natural and efficient for the tool's complexity.

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 all critical aspects: data binding for text, footage, and properties, handling of precompositions, safety guarantees, and integration with rendering. It also anticipates common use cases (personalized ads, product cards). Given the tool's complexity, nothing significant is missing, and the absence of an output schema is immaterial here.

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 already has 100% description coverage, so the description wisely avoids redundancy. Instead, it adds conceptual meaning by explaining the row-to-composition mapping, the kinds of values that can be driven (text/footage/property), and the reuse of targeting schemes from sibling tools. This enriches the agent's mental model without repeating schema details.

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 concrete, specific action: 'Duplicate a template composition once per row of a data table' – this is a clear verb+resource+scope. It further distinguishes itself from siblings by calling itself 'the batch/bulk version of manually editing one composition' and references sibling tools (localize-comp, animate-to-audio) for comparison, making the purpose unmistakable.

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

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

The description clearly implies when to use this tool (batch operations) versus alternatives by labeling it the 'batch/bulk version' and noting that it reuses logic from other tools. It also gives explicit chaining advice: 'Chain with render-aerender afterward'. It doesn't explicitly state when NOT to use it, but the context is strong enough for an agent to decide.

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 discloses that layers are replaced in the source comp with a single layer referencing the new precomp, which is a mutating action. However, it does not detail side effects like whether original layer properties are preserved, or the impact of moveAllAttributes. The behavior is partially transparent but lacks full detail on consequences.

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, well-structured sentence that immediately communicates the purpose and key behavior. It is concise with zero wasted words, fitting the 'appropriately sized and front-loaded' ideal.

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 moderately complex tool with a rich schema describing all parameters, the description covers the core action and its effect on the source comp. It does not mention return values (no output schema) but successfully conveys the essential operation. It is nearly complete for its complexity 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?

The input schema provides 100% coverage with descriptions for all parameters. The tool description adds no extra semantic meaning beyond the schema, so it meets the baseline for high coverage. It does not need to elaborate further.

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: 'Bundle one or more layers into a new nested composition', and explains the outcome of replacing layers in the source comp. It distinguishes itself from sibling tools like create-composition or duplicate-layer by specifically referencing the 'Layer > Precompose' feature, making the purpose unambiguous.

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

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

The description implies usage—when you need to precompose layers—but does not explicitly contrast with alternatives or state when not to use it. There is no mention of alternative tools for similar tasks (e.g., creating a composition manually), so guidance is limited to the implied 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?

No annotations are provided, so the description carries the burden. It discloses that the operation doesn't affect composition usage, which is a key behavioral trait. It also mentions the selection ambiguity resolution (itemName must match exactly one item). However, it doesn't mention potential side effects like file path validation or whether the operation is reversible.

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 concise and front-loaded with the core purpose. It uses two sentences effectively: the first explains what the tool does, the second explains how to select the item. No wasted words.

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

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

Given the tool's moderate complexity (3 params, no output schema), the description is fairly complete. It explains the core behavior, selection methods, and the non-destructive nature regarding compositions. It could mention what happens if the new path is invalid, but that's a minor 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 schema already provides 100% coverage with descriptions for all three parameters. The description adds context about itemId being preferred and unambiguous, and itemName requiring exact match, which reinforces the schema. However, it doesn't add much beyond what the schema already states.

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

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

The description clearly states the tool's purpose: relink a footage item's source to a different file on disk, with the key detail that it doesn't affect composition usage. It distinguishes itself from sibling tools like import-footage by focusing on relinking existing footage rather than importing new.

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

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

The description provides clear guidance on when to use this tool (to change a footage item's source file) and how to select the item (by itemId preferred, or itemName with exact match). It doesn't explicitly mention when not to use it or alternatives, but the context is clear enough.

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 full responsibility for behavioral disclosure. It only states the removal action, without mentioning side effects, undo behavior, permission requirements, or that modification is permanent. This is insufficient for a destructive 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?

The description is a single sentence with 11 words, very concise and to the point. However, for a tool with 6 parameters and conditional logic, a slightly more structured description could improve clarity without sacrificing brevity.

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

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

Given the tool's complexity (6 parameters, removal action, conditional behavior when removeAll is true), the description is incomplete. It does not explain parameter interactions, return value, or error conditions. The absence of annotations further reduces completeness.

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 parameters are well-documented in the schema. The description adds minimal additional value beyond stating that removeAll removes all effects. It does not clarify the relationship between effectName, effectMatchName, and effectIndex, or which parameters are mutually exclusive.

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

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

The description clearly states the tool's purpose: removing one specific effect or all effects from a layer. It uses a specific verb ('remove') and resource ('effect from a layer'), and distinguishes from sibling tools like add-any-effect or list-layer-effects.

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

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

The description implies usage for removing effects but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or cases where it should not be used. With siblings like apply-effect and set-effect-property, more context would be beneficial.

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 fully discloses key behaviors: runs in background, does not block UI, requires saved project, returns immediately unless waitMs is set, and defaults to saving the open project first. All important behavioral traits are covered.

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 concise, with no wasted sentences. It starts with the core purpose and key differentiator, then covers prerequisites, default behavior, and monitoring. Each sentence adds value.

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 9 parameters and no output schema, the description adequately covers prerequisites, parameter behavior, return behavior, and how to monitor progress. It is complete for the tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of parameters like saveFirst, waitMs, and projectPath, and how they interact. It also clarifies output path extension and template usage, going 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 it renders a composition to a file in the background using aerender, distinguishing it from start-render by noting it does not freeze the UI. The verb 'render' and resource 'composition' are specific.

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 explains when to use this tool (background rendering without freezing UI) and provides a prerequisite (project must be saved). It also hints at using render-status to check progress. However, it does not explicitly exclude alternatives like start-render for specific cases.

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 provided; the description does not disclose that clear and remove actions are destructive or require caution. It does not mention side effects, permissions, or reversibility, which is a gap 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?

Single sentence efficiently conveys the tool's purpose and actions with no redundancy. Front-loads the main idea. Every word earns its place.

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

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

No output schema exists, so description should describe return values. It explains list output but not clear/remove returns. Lacks error handling or prerequisites. Adequate for a simple tool but has 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 covers both parameters (100% coverage). Description adds value by explaining the list output (status, output path) and that index is 1-based and required for remove. Baseline 3 is appropriate as the schema already documents the 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 clearly states the tool inspects or manages the After Effects render queue with specific actions: list, clear, remove. It distinguishes from sibling tools like add-to-render-queue, start-render, etc.

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

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

The description implies usage for queue management but does not explicitly state when to use it vs alternatives like add-to-render-queue or start-render. No when-not-to-use guidance.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses the tool checks status and reports running, finished, and log tail. It does not mention side effects (likely none) but adequately describes behavior.

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

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

The description is a single sentence with no wasted words. It front-loads the purpose and is highly 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?

Given the tool has one optional parameter, no output schema, and a straightforward purpose, the description is complete. It explains what the tool checks and how it reports, sufficient for an agent.

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 schema already describes the single 'pid' parameter as optional. The description adds no further meaning beyond the schema, 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?

The description clearly states the verb 'check' and the resource 'background aerender renders started with render-aerender', specifying what is checked (running, finished, log tail). It distinguishes from sibling tools like 'render-aerender' (starts renders) and 'render-queue' (likely different).

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

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

The description implies usage after starting renders with 'render-aerender', providing clear context. However, it does not explicitly state when not to use it or mention alternatives, but the context is sufficient for an agent to infer usage.

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 must disclose side effects, but it only restates the basic mutation ('Change... stacking order') and a parameter constraint. It does not address reversibility, required selection defaults, or effects on other layers.

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-load the core purpose and immediately give the key usage rule. There is no filler or repetition of schema text.

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

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

The tool has 9 optional-looking parameters and cross-parameter constraints, but the description never mentions how to identify the layer being moved (layerName/layerIndex) or whether active selection is used as a default. The complete invocation contract is therefore not documented.

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 imposing a mutual-exclusion constraint among toPosition, before*, and after* that the schema's standalone property descriptions do not convey. It remains slightly ambiguous about how the before/after name-index pairs combine.

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

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

The description opens with a specific verb and resource: 'Change a layer's stacking order (z-order) within its composition.' This clearly states the tool's function and distinguishes it from sibling operations like duplicate-layer, set-layer-parent, or precompose-layers.

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?

'Provide exactly one of toPosition, before*, or after*' gives an explicit usage constraint and names the three destination alternatives. It does not discuss explicit alternatives to this tool, but the stacking-order operation is unique among the siblings and the 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?

No annotations exist, so the description must fully disclose behavior. It vaguely mentions 'apply test effects' but does not specify what effects are applied, whether they are destructive, if any setup is needed, or what the script does in detail. The side effects are unclear.

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 sentence that is front-loaded with the main action and purpose. Every word is necessary; no 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 tool with no parameters and no output schema, the description is minimal but functional. However, it lacks details about return values (if any) or post-conditions after applying test effects. It could be more complete by stating expected output or side effects.

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

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

The input schema has no parameters, so schema coverage is 100%. The description correctly does not need to add parameter details. Baseline for zero parameters is 4, and the description adequately describes the tool without parameter information.

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

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

The description clearly states the tool runs a bridge test effects script to verify communication and apply test effects. The verb 'Run' and the specific resource are mentioned. However, it does not differentiate from similar sibling tools like 'check-bridge' or 'test-animation'.

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 provided on when to use this tool versus alternatives like 'check-bridge'. There is no mention of prerequisites, context, or when not to use it.

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

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

No annotations provided, so description carries full burden. Only states 'read-only', but does not disclose what happens on error, whether it returns output, or any side effects beyond being read-only.

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?

Single sentence, no fluff. Efficient but could be more informative without being 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 tool with no output schema and a nested parameters object, the description is too minimal. Does not explain how parameters are used, what the script returns, or if it's synchronous. Incomplete for reliable invocation.

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

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

Schema covers 100% of parameters (script and parameters). Description adds no additional meaning beyond 'predefined script' which is already in 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?

Description clearly states it runs a read-only script in After Effects. However, it does not differentiate from sibling tool 'execute-script', which might have similar functionality, causing potential confusion.

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

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

No guidance on when to use this tool versus alternatives like 'execute-script'. No mention of prerequisites or when not to use.

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 carries the full burden of behavioral disclosure. While 'search' implies read-only, the description does not explicitly state side effects, lack of destructiveness, or permission requirements. It is adequate but not explicit.

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

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

The description is a single, clear sentence with no extraneous information. It is appropriately concise and 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?

Given the lack of output schema and annotations, the description is minimally complete. It does not explain the return format or default behavior (e.g., default search directories). The schema covers parameters, but the tool description lacks context about what results look like.

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

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

The input schema has 100% description coverage, so the schema adequately documents all parameters. The description adds no additional meaning or context beyond the schema, meeting the baseline but not adding 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 clearly states the tool searches After Effects .ffx presets by name or path. It is specific and distinguishes from sibling tools like 'list-presets' and 'apply-preset', though it could be more explicit about how it differs from 'list-presets'.

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

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

The description provides no guidance on when to use this tool vs alternatives such as 'list-presets' or 'apply-preset'. There is no mention of prerequisites or scenarios where search is preferable.

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?

Despite no annotations, description thoroughly explains behavior: returns downscaled images by default, maxWidth 0 for native resolution, clamping of out-of-range times, still vs playback differences, motion blur param default false, and time-dependent effects caveat. Covers all key behaviors.

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?

Compact yet comprehensive. Front-loaded with purpose and use cases. Every sentence adds value without redundancy. Well-organized flow from purpose to parameter specifics to caveats.

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 6-parameter tool with no output schema, description covers all parameters, return format, default behaviors, caveats (still vs playback), and selection mechanisms. No gaps for agent to interpret.

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%, but description adds significant meaning: comp selection via name/index/active, time defaults to midpoint, maxWidth default 512, motionBlur default false, includeState for structured state. Explains rationale behind parameters and their effects.

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

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

The description clearly states the tool renders frames to images for visual verification, listing specific problems like clipped text or wrong colors. It distinguishes from siblings by mentioning 'inspect-comp' for structured state, which is also available via includeState.

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 states when to use: after edits to catch visual problems not revealed by DOM. Lists specific scenarios (clipped text, blown-out glow, etc.). Does not explicitly state when not to use, but provides clear context and mentions optional includeState for structured info.

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 provided, so description carries full burden. It explains dB range, per-channel override, and keyframing. Could mention persistence or undo behavior, but core transparency 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?

Single sentence, no waste. Front-loaded with key action and differentiated features.

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 no annotations, description covers essential behavior for a mutation tool. Could mention that it modifies existing layer audio settings, but sufficient.

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

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

Schema coverage is 100%, but description adds value by summarizing parameter roles (e.g., 'level' applied to both channels, left/rightLevel overrides). Groups keyframing concept with timeInSeconds.

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

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

Description clearly states action ('set audio levels'), resource ('audio or AV layer'), and key differentiators ('per-channel control', 'optional keyframing'). Distinguishes from sibling tools like get-audio-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?

Usage context is clear from description and sibling set (other tools are for effects, markers, etc.). No explicit when-not-to-use or alternatives, but 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?

No annotations are provided, so the description must fully disclose behaviors. It only lists the settable properties without detailing side effects (e.g., impact on layers, undoability, or permission requirements), leaving significant gaps.

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

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

The description is two short sentences, front-loaded with the action and list of settings, with no unnecessary words.

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 no annotations, the description lacks details on return values, default behavior when no parameters are set, and constraints like requiring width and height together (though schema covers it). It is adequate but not complete for a mutation tool.

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

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

Schema coverage is 100%, so the description adds minimal extra meaning beyond summarizing parameters. The mention of width+height together is helpful but already in the schema.

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

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

The description clearly states the tool changes composition settings like duration, frameRate, and width+height, distinguishing it from creation or inspection tools like create-composition or inspect-comp.

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?

While it clearly indicates what it does and how to select the composition, it does not explicitly guide when to use this tool vs alternatives like batch-set-layer-properties or set-effect-property, though the narrow focus on composition-level settings is implicit.

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

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

The description does not disclose key behavioral traits such as whether existing keyframes are overwritten, what happens if the property cannot be keyframed, or any permission requirements. Since no annotations are provided, the description carries the full burden, which it fails to meet.

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

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

The description is a single, front-loaded sentence that immediately conveys the tool's purpose and optional capabilities. No extraneous information, earning its place 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 tool's complexity (12 parameters, nested keyframeOptions object, no output schema), the description is too sparse. It lacks information about typical use cases, side effects, or result expectations, leaving gaps for the agent.

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

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

The input schema has 100% coverage, describing all 12 parameters in detail. The description adds minimal value beyond summarizing the keyframeOptions feature. Baseline score of 3 is appropriate as schema does the heavy lifting.

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

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

The description clearly states the tool's action ('Set an effect property keyframe') and specifies optional features ('graph interpolation and easy-ease controls'). This verb+resource combination effectively distinguishes it from sibling tools like setLayerKeyframe and set-effect-property.

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 tool versus alternatives (e.g., set-layer-keyframe) or when not to use it. The context is implied by the phrasing 'effect property keyframe' but lacks direct comparison or exclusion criteria.

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 must fully disclose behavior, but it only states the basic function. It omits critical details like conflict resolution when multiple identification methods are provided, what happens if a property doesn't exist, whether keyframes are added or overwritten, and the effect on existing keyframes or expressions.

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 sentence that efficiently conveys the core purpose and method. Every word is meaningful, and it is not verbose. It is perfectly concise for a tool with extensive schema documentation.

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

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

Given the tool's complexity (13 parameters, nested objects, no output schema, no annotations), the description is too minimal. It does not explain what the tool returns, how to handle errors, or provide any context on the order of precedence for identifying effects (name vs index vs matchName).

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 baseline is 3. The description adds a high-level summary but does not elaborate on parameter semantics beyond what the schema already provides. For example, the behavior of keyframeOptions and how parameters interact is left 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 clearly states the action ('set or keyframe any property on an existing layer effect') and the method ('using name/index/path'). However, it does not distinguish from sibling tools like set-effect-keyframe, which also handles keyframing, missing a chance to clarify unique scope.

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 provided on when to use this tool versus alternatives. For example, it doesn't explain when to prefer this over set-effect-keyframe or setLayerKeyframe, nor does it mention prerequisites like requiring an existing effect on the layer.

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 disclose behavioral traits. It reveals mutation (setting/removing expressions) and mentions that an empty string removes the expression. However, it lacks details on permissions, error states, or side effects. The schema already covers parameter descriptions, so the added behavioral context is minimal.

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, well-structured sentence that immediately conveys the tool's purpose. Every word is necessary and nothing is extraneous.

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 annotations, the description should be more complete. It does not explain the return value, success/failure indicators, or error handling. Given the tool has 4 required parameters and mutates state, the description is insufficient for full operational clarity.

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 adds value by explicitly stating that an empty expressionString removes the expression, which is not in the schema. However, it does not elaborate on parameter constraints or interactions beyond what the schema provides.

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

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

The description clearly states the verb (Set or remove) and the resource (expression for a specific layer property). It effectively distinguishes this tool from siblings that deal with markers, effects, or keyframes.

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

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

The description provides no guidance on when to use this tool vs alternatives like setLayerKeyframe or apply-effect. It does not mention prerequisites or conditions, leaving the agent to infer usage from the 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?

With no annotations, the description should disclose behavioral traits like whether existing keyframes are overridden, error conditions, or value constraints. It only states the action without any safety or side-effect details.

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 concise sentence that front-loads the purpose. It is efficient, though slightly lacking in 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?

Given the tool modifies state (sets a keyframe) with 5 parameters and no output schema, the description is minimal. It lacks information on return values, errors, or behavior when overwriting existing keyframes.

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 description adds useful examples for the 'value' parameter (e.g., [x,y] for Position), enhancing meaning beyond the schema's type definition.

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 (set a keyframe) and the resource (specific layer property at a given time). It is specific enough to distinguish from sibling tools like set-effect-keyframe, though not explicitly 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?

No guidance is provided on when to use this tool versus alternatives, such as set-effect-keyframe or batch-set-layer-properties. The description gives no context for selection.

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