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 of behavioral disclosure. It only states 'Get help' without conveying what output to expect, whether it returns a list of commands, or if it has any side effects. The read-only nature is implied but not stated, and no additional behavioral context is given.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose, making it highly concise and well-structured.

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

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

For a simple help tool with no parameters and no output schema, the description provides the essential purpose but lacks details about what kind of help is returned (e.g., command list, usage examples, or links). Since there is no output schema, the description should explain the return value, but it does not, leaving a moderate gap.

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

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

The tool has zero parameters and schema description coverage is 100%, so the baseline score is 4. The description does not need to add parameter information because there are none 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 states a clear verb and resource: 'Get help on using the After Effects MCP integration'. It is more specific than a tautology and identifies the tool as general help, but it does not explicitly distinguish itself from the sibling tool 'mcp_aftereffects_get_effects_help', which appears to be a more specialized help option.

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 situations where users should prefer the dedicated effects help tool or any other tool, and it offers no exclusions or contextual examples.

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 clearly signals a read-only retrieval ('Get results'), but it does not disclose what the result payload looks like, whether it can fail, or whether it has side effects. The behavioral description is minimal but not misleading.

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 that front-loads the action and resource with no filler. 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?

Given zero parameters and low complexity, the description is mostly adequate, but the absence of an output schema leaves 'results' undefined. The agent must guess whether it returns a string, object, or status, which is a notable gap for a tool with no other documentation.

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 100% covered (empty properties), so the baseline for no parameters applies. The description does not need to explain parameters since there are none.

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

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

The description uses a specific verb+resource ('Get results') and scopes it to the last script executed in After Effects, clearly distinguishing it from sibling execution tools like run-script and execute-script. The subject and scope are immediately understandable.

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

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

The phrase 'last script executed' implies the tool should be used after running a script, providing clear context, but it does not explicitly state when to use it versus alternatives or what happens if no script has been executed. No exclusions or alternative tool references are given.

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

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

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?

With no annotations provided, the description carries the full burden of disclosing behavior. It merely states the purpose without mentioning that the operation is read-only, what output to expect, or any other behavioral traits. The implication of 'help' being non-destructive is weak.

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, directly stated sentence with no filler words. It conveys the core purpose efficiently and is appropriately sized for a tool with no parameters.

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 is adequate for a simple help tool, but it lacks details about the output format or what kind of help is returned. Since there is no output schema and no annotations, the description should explain what the agent will receive, but it does not.

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 an empty schema, so the baseline for parameter semantics is 4. The description adds no parameter information, but none is needed since there are 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 tool's purpose: providing help on using After Effects effects. The verb 'Get help' and the resource 'After Effects effects' distinguish it from general help tools like 'get-help' and effect listing tools like 'list-available-effects', though it doesn't elaborate on what the help includes.

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 offers no guidance on when to use this tool versus similar siblings such as 'get-help' or 'list-available-effects'. It does not mention any alternatives, prerequisites, or exclusions.

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

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

With no annotations provided, the description carries full burden for transparency. It does disclose that the tool 'applies test effects', indicating side effects, but it does not explain what those effects are, whether they are destructive, reversible, or impact the current project. The behavior beyond 'verify communication' is vague, leaving the agent uncertain about possible outcomes.

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, compact sentence that directly conveys the tool's function without any filler or redundancy. It is front-loaded with the action ('Run') and the resource ('bridge test effects script'), earning high marks 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 the tool has no parameters and no output schema, the description is the sole context. It provides the basic purpose but leaves gaps about the nature of 'test effects' and the expected outcome. While it is minimally viable, an agent might struggle to predict the tool's impact on the environment, so the description could be more detailed.

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 is empty, meaning there are no parameters. The description correctly makes no mention of parameters, and because there are none, there is no semantic gap. Baseline 4 is appropriate for a zero-parameter tool.

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

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

The description clearly states a specific action ('Run the bridge test effects script') and its dual purpose ('verify communication and apply test effects'). This distinguishes it from siblings like 'run-script' (generic script runner) and 'check-bridge' (only checks communication), making the tool's role 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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or that it should be used before/after other operations. The purpose implies a testing scenario, but the description fails to explicitly state this 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?

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?

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without revealing what happens if the optional 'value' parameter is omitted, whether existing keyframes are overwritten, or what the tool returns. This 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 a single concise sentence that directly states the core action without any filler or redundancy. Every word contributes to understanding.

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 annotations, no output schema, and an optional 'value' parameter whose behavior is unexplained, the description is not complete enough for an agent to fully understand the tool's behavior. The schema covers parameter names and types, but the description fails to convey key contextual nuances such as keyframe overwriting or the significance of the optional value.

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

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

The input schema already provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds little beyond restating 'specific layer property' and 'given time,' and it fails to clarify the optional 'value' parameter, which is not included in the required list. However, since the schema handles most semantics, a 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 uses a specific verb 'Set' with a clear resource: 'a keyframe for a specific layer property at a given time.' It clearly distinguishes from sibling tools like set-effect-keyframe by focusing on layer properties rather than 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 provides no guidance on when to use this tool versus alternatives. There are related sibling tools such as set-effect-keyframe and setLayerExpression, but the description does not mention them or any exclusions, leaving the agent without explicit usage direction.

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.