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 disclosing behavioral details. It only states the action (apply an effect) without explaining side effects (e.g., modifying the layer), requirements (e.g., indices must be valid), or the behavior when parameters conflict (e.g., effectName vs. effectMatchName). The description adds minimal value beyond the tool name.

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 wasted words. It is appropriately sized for a basic tool purpose statement and is easy to parse quickly.

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 (7 parameters, nested objects, no output schema, no annotations), the one-sentence description is insufficient. It does not explain return values, error behavior, or the relationship between optional parameters. The schema covers parameter definitions but the description lacks contextual completeness 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%, with all parameters having descriptions, so the baseline is 3. The tool description does not add any parameter-specific meaning beyond the schema. It does not clarify how to choose between effectName, effectMatchName, or presetPath, but the schema already provides adequate descriptions for each parameter.

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: 'Apply an effect to a layer in After Effects.' It uses a specific verb ('apply') and identifies the resource ('effect') and target ('layer'). However, it does not distinguish from the sibling tool 'apply-effect-template', which also applies effects. Thus, it is clear but lacks sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context such as requiring an active composition or layer. No sibling tools are referenced, and there is no implied usage beyond the basic action.

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 only states the action without explaining important traits like whether existing effects are replaced, whether the operation is reversible, or what 'applying a template' actually entails (e.g., adding multiple effects, modifying layer properties).

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, direct sentence with no filler words. It efficiently communicates the core action and target resource, earning its place without redundancy.

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

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

Given the tool's moderate complexity (4 parameters, optional nested object, no output schema), the description is too sparse. It fails to explain what a 'predefined effect template' is, how customSettings override defaults, or any side effects, leaving the agent without enough context to predict the tool's full behavior.

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

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

Schema description coverage is 100%, with clear descriptions for compIndex, layerIndex, templateName (including an enum of available templates), and customSettings. The description adds no parameter-specific information, so the baseline of 3 applies.

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

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

The description clearly specifies the action ('Apply') and the resource ('a predefined effect template to a layer in After Effects'). It distinguishes from sibling tools like 'apply-effect' by emphasizing 'predefined template', which implies a package of effects rather than a single 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?

The description provides no guidance on when to use this tool versus alternatives such as 'apply-effect' or 'apply-preset'. It does not mention any prerequisites, selection requirements, or scenarios where a template would be preferred over a simple effect or preset.

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 tool creates a new composition but doesn't mention default behavior (e.g., default duration/frameRate if omitted) or whether it overrides an existing comp. The schema provides defaults for some parameters, but the description adds no extra behavioral context. Since creation tools are generally non-destructive (new resource), the lack of warning is acceptable, but the description could mention that existing comps are not affected.

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 filler words. It is front-loaded with the action ('Create') and resource ('a new composition'), making it immediately clear. Every word serves a purpose, and it is neither verbose nor under-specified.

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 creation tool with a rich schema (7 parameters, all documented), the description doesn't need to explain return values (no output schema). It could mention that the composition is added to the project panel or the current project, but this is implied by 'in After Effects.' The lack of annotations and output schema lowers the burden, but the description could be a bit more explicit about the context (e.g., the composition is created in the active project). Overall, it is minimally complete but not exceptional.

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 schema already documents all 7 parameters thoroughly. The description's phrase 'specified parameters' is generic. Consequently, the description adds no extra meaning beyond the schema. A baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states the verb ('Create') and resource ('a new composition in After Effects'), which clearly identifies the tool's function. It doesn't distinguish from sibling tools explicitly, but siblings like 'create-adjustment-layer' are different enough that no confusion is likely. A more specific mention of parameters like width/height/duration would strengthen it, but the current wording is adequate.

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

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

The description gives the context ('Create a new composition in After Effects') but no explicit when-to-use or alternatives. It implies that this is the go-to tool for creating comps, especially since siblings don't include another composition creator. However, no prerequisites or exclusions are mentioned, making it minimally 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 carries the full burden. It only restates the purpose ('Get help') without disclosing what the help output contains, whether it lists commands, returns usage examples, or requires further input. Behavior is largely opaque.

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 of 11 words, front-loaded with the verb 'Get'. No filler or redundancy; 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?

For a zero-parameter help tool, the description is largely complete, clearly stating the scope ('After Effects MCP integration'). The absence of an output schema means a description of the return format would have been useful, but this is a minor gap given the simplicity.

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 zero parameters and the schema is an empty object with 100% coverage. No parameter documentation is needed; the baseline for 0-param tools is 4, and the description doesn't misrepresent any 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 'Get help on using the After Effects MCP integration', with a specific verb and resource. It distinguishes itself from sibling tools that perform specific operations like apply-effect 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 implied usage is when the user needs assistance with the MCP integration, but there is no explicit when-to-use guidance or mention of alternatives. It doesn't reference more specific help tools like mcp_aftereffects_get_effects_help.

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. 'Get' implies a read-only operation, but there is no mention of behavior if no script has been run, whether results are cleared, or what the return payload looks like. The description is minimal and lacks depth.

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

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

The description is a single, front-loaded sentence with no wasteful words. It earns a perfect score for 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?

Given the tool's simplicity (no params, no output schema, no annotations), the description is minimally complete but leaves gaps about result format and error conditions. It is adequate but not rich enough to be genuinely 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema confirms no parameters exist.

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

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

The description clearly states the tool retrieves results from the last executed script, using a specific verb and resource. It is distinguishable from sibling tools like run-script or get-help, though it does not explicitly differentiate itself from similar getter 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 gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like having run a script first. It implies usage after script execution but does not state this explicitly.

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

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

With no annotations, the description carries the full burden and discloses little: it doesn't say whether re-importing the same path duplicates the project item, whether existing comps must be open, what happens if the file or comp is missing, or whether the operation is reversible. Only the media-acceptance behavior is conveyed.

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

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

A single front-loaded sentence naming the action, source, and accepted inputs, with the optional comp insertion tacked on parenthetically where it belongs. No filler, though it is too terse for a 10-parameter tool.

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

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

Ten parameters, no annotations, no output schema, and the description never says what the call returns (imported item identity or created layer) — information an agent likely needs to chain into setLayerExpression or apply-effect. It also gives no guidance on compName vs compIndex precedence or whether a comp must already exist.

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 filePath, compName, compIndex, position, scale, duration, startTime, sequence and threeDLayer are already fully documented. The description adds only the high-level notion that a sequence import mode exists and that comp insertion is optional, which is baseline-level 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?

States a specific verb (import) and resource (footage) with accepted media types (image, video, audio, sequence) and the optional composition insertion. It implicitly distinguishes itself from 'replaceFootage' by being the initial ingest step, though it never names that sibling.

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

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

Usage is only implied: use it to bring new media in from disk, and pass a comp to also place a layer. There is no explicit when-to-use vs 'replaceFootage' (already-imported items) or 'create-composition' (which must exist before compName/compIndex can be used), and no stated prerequisites.

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

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

With no annotations, the description carries the behavioral disclosure burden. Calling it 'List all items' implies a read-only operation and the listed item types clarify scope, but it does not explicitly state side-effect behavior, ordering, pagination, or whether nested folder contents are included.

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

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

The description is a single, front-loaded sentence that conveys the resource, scope, and item types without filler. Every phrase earns its place.

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

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

There is no output schema, so the description should explain return values. It mentions that items include metadata but does not specify the shape of that metadata, whether results are ordered or paginated, or how nested project structures are represented. For a no-parameter listing tool this is adequate but leaves clear gaps.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The baseline for a zero-parameter tool is 4, and the description appropriately does not discuss 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 a specific verb and resource: listing all items in the project panel. It also enumerates the item types returned, which makes the purpose concrete, though it does not explicitly distinguish itself from any sibling 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?

There is no guidance on when to use this tool versus alternatives, nor any stated preconditions or exclusions. The purpose is implied by the name and description, but the description provides no usage context.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It offers no transparency about side effects (e.g., modifying the layer's effect stack), error conditions, or whether the effect is appended or replaces existing effects. The single sentence provides only the obvious 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?

The description is a single sentence with no wasted words, but it is under-specified rather than appropriately concise. It lacks any structured detail or context that would make it useful for an agent deciding how to invoke the tool.

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

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

With no annotations, no output schema, and a tool that has 5 parameters including a nested object and two effect identifier variants, the description leaves out important context such as prerequisites, side effects, error behavior, and when to use effectName versus effectMatchName. The schema covers parameter meaning but not operational 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 description itself does not explain any parameters, but the input schema covers all 5 parameters with detailed descriptions and examples, so schema coverage is 100%. The baseline for high schema coverage is 3, and the description adds no extra 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?

The description clearly states the action (apply) and target (an effect to a layer in After Effects). However, it does not differentiate from sibling tools like 'apply-effect' or 'apply-effect-template', which might have similar purposes.

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 prerequisites, such as requiring an active composition or selected layer, nor does it explain when to prefer effectMatchName over effectName.

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 for behavioral disclosure. It only states the action without revealing important traits such as whether existing effects are replaced, whether the layer must be selected, or whether the operation is destructive. This is insufficient for a tool that applies changes to a layer.

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 redundant words. It is appropriately sized and front-loaded with the verb and object, 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?

Given no output schema and no annotations, the description should provide more context about what happens after applying the template, whether any output (e.g., success/failure) is returned, and how customSettings interact with the template. The current one-sentence description leaves critical operational details unspecified, especially for a tool with a nested object parameter.

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?

All four parameters are fully described in the input schema (100% coverage), so the baseline is 3. The description itself adds no additional meaning beyond the schema, such as explaining the customSettings object structure or how template defaults work, but the schema already provides adequate semantics.

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

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

The description clearly states the verb ('apply') and resource ('predefined effect template to a layer in After Effects'), making the core function understandable. However, it does not differentiate this from closely related sibling tools such as 'apply-effect' or 'apply-effect-template', leaving some ambiguity about which tool to choose.

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 like 'apply-effect' or 'apply-preset'. It does not mention any exclusions, prerequisites, or typical scenarios, leaving the agent without clear selection 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 carries the full burden of disclosing behavior. It implies a read-only operation (getting help) but does not state whether it is safe, what the output format looks like, or whether it requires After Effects to be running. This is minimal disclosure 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?

The description is a single, concise sentence that immediately conveys the core function. It is front-loaded with the verb and resource, and every word is necessary. There is 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?

Given the simplicity of the tool (0 parameters, no output schema, no annotations), the description is minimally viable. It tells the agent what the tool does but does not clarify the nature of the returned help (e.g., text, JSON, command reference) or the scope of 'using After Effects effects'. For a help tool, some additional context about output 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?

The tool has zero parameters, so the input schema provides no information. The description adds no parameter details, but the baseline for 0-parameter tools is 4, and there is nothing to compensate for, as no arguments are needed.

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 with a specific verb ('Get help') and resource ('After Effects effects'). It distinguishes from the generic 'get-help' sibling by specifying the domain. However, it lacks detail on exactly what kind of help is provided (e.g., syntax, examples, troubleshooting), making it slightly less clear than a more descriptive purpose.

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 like 'get-help' or other effect-related tools. It does not mention any conditions, prerequisites, or when not to use it. For a tool with a generic sibling, this is a notable gap.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states that an existing item is replaced with a new file from disk, but it does not disclose consequences such as what happens to compositions using the old footage, whether replacement is reversible, or how target resolution works when both footageId and footageName are optional.

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

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

The description is a single front-loaded sentence with no redundant wording. The parenthetical use-case note is compact and relevant rather than wasteful.

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 schema fully documents the parameters and the description states the core replacement operation, which is adequate for a simple mutation tool. However, with no annotations and no output schema, the description should ideally explain target selection between footageId and footageName and the effects of replacing assets in a project.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the input schema. The description adds only high-level context about replacing existing footage with a file from disk and does not add syntax, format, or selection details 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 a specific verb and resource: it replaces an existing footage item or placeholder with a new file from disk. This distinguishes it from importFootage by emphasizing replacement of an existing project item, though it does not explicitly name the sibling 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?

The parenthetical 'essential for template customization' provides an implied use case, and 'replace an existing footage item or placeholder' indicates the context. However, it does not explicitly say when to use this tool versus importFootage or how to choose between footageId and footageName.

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 full behavioral burden. It never states that this mutates layer text irreversibly, what happens when findText is omitted (only newText is required despite the tool being 'find and replace'), whether all matching layers or only the first are changed, or what occurs when no match is found.

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

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

A single front-loaded sentence with the core action first and the use case scoped in parentheses. 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?

With eight parameters, no annotations, and no output schema, the agent needs more than a one-liner: the fallback behavior for comp/layer resolution, the required-only newText oddity, and the mutation/reversibility profile are all unaddressed.

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

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

Schema coverage is 100%, so all eight parameters are already documented in structured data; the description adds little beyond 'across layers'. It does not clarify the interaction between compName/compIndex and layerName/layerIndex or that findText is effectively required for the replace behavior.

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

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

The description gives a specific verb and resource — 'find and replace text content across layers in a composition' — and adds a concrete use case (AE templates & MoGRTs). It is distinguishable from siblings like replaceFootage or setLayerExpression, though it never explicitly contrasts with them.

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

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

The parenthetical 'ideal for customizing AE templates & MoGRTs' implies when the tool is useful, but there is no guidance on when not to use it, no mention of alternatives for single-layer edits, and no prerequisites. Usage is only implied.

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

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

With no annotations, the description must disclose behavioral traits. It only states that it 'applies test effects,' which hints at mutation, but does not explain what those effects are, whether they are reversible, or any other side effects. This is insufficient for a tool with no annotation safety hints.

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, focused sentence that gets straight to the point. No wasted words, and it is appropriately sized for such a simple tool.

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

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

Given the tool's simplicity (no parameters, no output schema), the description gives the basic purpose but leaves ambiguity around 'bridge test' terminology and the nature of 'test effects.' It is adequate for a simple utility 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?

The tool has zero parameters, so the schema fully covers all inputs. The description doesn't need to explain parameters; the baseline of 4 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 identifies a specific verb ('Run'), the resource ('the bridge test effects script'), and the purpose ('verify communication and apply test effects'). It stands apart from generic siblings like 'run-script' by naming a specialized test 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 provides clear context for when to use the tool ('to verify communication and apply test effects'), but does not explicitly contrast with alternatives or state exclusions. This meets the 'clear context, no exclusions' bar, earning a 4.

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 discloses that the script is read-only, which is valuable safety information, and adds context beyond the schema. It could mention more about side effects or error behavior, but the read-only qualifier provides meaningful transparency.

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

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

The description is a single sentence that directly states the purpose and key qualifier. It is concise, front-loaded, and contains 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?

The tool has a simple interface with clear schema coverage, but no output schema is provided. The description does not explain what the script returns or how results are delivered, leaving a gap for a script runner. It is adequate for basic understanding but could be more complete, especially for a tool that runs arbitrary predefined scripts.

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 descriptions for both parameters with 100% coverage, so the description does not need to compensate. The description adds nothing about parameter semantics, and the baseline of 3 is appropriate given the schema's completeness.

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 (run), the resource (a script), and the context (After Effects) while adding the qualifier 'read-only' to define the script's nature. This distinguishes it from the sibling tools, which focus on effects, layers, and compositions, not script execution.

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 this tool is for executing predefined scripts that are read-only, clearly differentiating it from effect-related tools. However, it does not explicitly state when to use it over alternatives or provide exclusion criteria, but the uniqueness among siblings makes the usage context 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 are provided, so the description carries the full behavioral burden. It does not disclose that existing ease/influence values on the target keyframes are overwritten, whether the operation is reversible, whether a project/undo state is required, or what the response contains.

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

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

One front-loaded sentence with no filler; the verb and target come first. It is short enough that the missing prerequisites are a content gap rather than clutter.

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 10-parameter mutating tool with zero annotations and no output schema, the description is thin: it says nothing about existing keyframe state being modified, the keyIndex-vs-timeInSeconds alternative, compIndex defaulting to the active comp, or the effect of omitting keyIndex entirely.

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 schema already documents all ten parameters with units, ranges, and defaults. The description adds only a partial enumeration of the easeType enum (four of nine values, omitting cinematic/linear/hold) and the notion of custom speed & influence, so baseline 3 is right.

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

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

States a specific verb ('Apply ease') and resource ('keyframes of a property'), plus names the concrete ease modes. An agent can distinguish it from setLayerKeyframe (which creates keyframes) reasonably well, though no sibling is named explicitly.

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

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

Usage is implied by the frame 'apply ease to keyframes' and the description hints that preset ease types and custom speed & influence are two routes. However it never states prerequisites (keyframes must already exist) or when to prefer a preset over custom values, and names no alternative tool.

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 only states that expressions can be set or removed, but does not disclose side effects such as overwriting existing expressions, handling of invalid expressions, or whether the target property must exist. The removal behavior via empty string is only implied, not explicitly stated in the description itself.

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 directly states the tool's purpose without any filler. Every word earns its place, making it highly concise and scannable.

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 (4 required parameters, no output schema, no annotations), the description provides the essential purpose but leaves gaps around behavioral outcomes and edge cases (e.g., overwriting, error handling, prerequisites). The schema covers parameters well, but the lack of behavioral context makes the description only minimally complete for an agent to safely invoke the 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?

Since the schema already provides 100% coverage with clear descriptions for all four parameters, the description adds minimal extra semantic value beyond mentioning 'remove' in the summary. The schema describes expressionString's empty-string behavior effectively, so the description does not need to compensate for missing parameter 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 uses a specific verb ('set or remove') and resource ('expression for a specific layer property'), clearly distinguishing it from sibling tools like setLayerKeyframe (keyframes) and run-script (general scripts). It precisely conveys both the primary action and the removal capability.

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, nor does it mention any prerequisites or exclusions. Usage context is only implied by the tool's name and purpose, but no explicit when-to-use or when-not-to-use guidance is given relative to siblings like run-script or setLayerKeyframe.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose what happens if a keyframe already exists at that time, whether changes are reversible, permission/selection requirements, or what the return value contains. For a mutation tool, these are significant omissions.

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

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

A single sentence with no wasted words, front-loading the verb and resource. It is efficient, though it is arguably too terse given the tool's behavioral 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?

For a mutation tool with no annotations and no output schema, the description is too thin. It leaves unstated keyframe-overwrite behavior, return values, and any environmental prerequisites that an agent would need before invoking it safely.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including the easing enum and value formats. The description adds essentially nothing beyond restating 'layer property at a given time,' so the baseline 3 applies.

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

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

The description states a specific verb ('Set'), resource ('a keyframe'), and target ('specific layer property at a given time'). It is clear what the tool does, but it does not distinguish itself from the sibling setKeyframeEase, which addresses a closely related operation.

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

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

There is no guidance on when to use this tool versus alternatives like setKeyframeEase, nor any prerequisites or context about what state the project must be in. The agent must infer usage entirely from the name and schema.

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

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

With no annotations, the description carries the full disclosure burden, and it omits the important fact that this is a mutation which also touches existing content (enable3DOnLayers flips the 3D switch on every other layer in the comp). It says nothing about return values, undoability, or side effects on the target composition.

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

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

A single front-loaded sentence with the key capability first and the optional behavior last. Minor waste in the adjective 'professional', but nothing structurally wrong.

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?

Seven parameters, no annotations, and no output schema means the description should explain the target composition and what the caller gets back (a rig null, a camera layer, names?). Instead it stops at a feature list, leaving the agent to infer the post-conditions of the creation.

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 defaults, units, and ranges are already documented per parameter; the description only echoes zoom, distance, and 3D enablement as concepts. That meets the baseline for a well-covered schema but adds no syntax or formatting detail beyond it.

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

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

The description gives a specific verb and resource ('Create a professional 3D Camera Rig') and enumerates the pieces it builds: a 3D Null orbit controller, zoom, distance, and optional 3D enablement. No sibling tool does anything comparable (the others are expression, footage, keyframe, and effect operations), so differentiation is implicit rather than stated.

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

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

It says what the tool creates but never when to reach for it, what prerequisites exist, or what to do instead if a rig already exists. There is no guidance about supplying compName vs compIndex or what happens if neither is provided.

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 only says 'test', which is ambiguous—does it apply changes or remain read-only? It does not mention side effects, return values, or any safety profile, leaving the agent without critical information.

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 entire description is one short sentence, which is appropriately concise in length, but it merely restates the tool name. This is under-specification rather than effective conciseness because it uses the sole sentence without providing any substantive information.

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

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

For a tool with no annotations, no output schema, and three required parameters, the description is wholly inadequate. It fails to explain what 'testing' means, how operation/comp/layer parameters interact, what the agent should expect as a result, or when this tool should be chosen over the many sibling animation tools.

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 provides 100% description coverage for the three parameters, including the operation enum and brief guidance ('usually 1'). The description adds no parameter-level insight beyond the schema, so the baseline of 3 applies.

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

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

The description "Test animation functionality in After Effects" is a near-tautology of the tool name 'test-animation'. It identifies the domain (After Effects animation) but does not specify what testing entails, nor does it distinguish this tool from siblings like setLayerKeyframe or setLayerExpression.

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. With many sibling tools for setting keyframes and expressions, there is no explanation of whether this tool is for validation, comparison, or actual mutation, nor any exclusions or prerequisites.

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