AE MCP Server

by p10q

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists, such as 'add_text_layer' and 'add_text_layer_advanced' or 'set_keyframe' and 'set_keyframe_advanced', which could cause confusion. However, descriptions help clarify differences, and the majority target specific actions on distinct resources like layers, masks, or compositions.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as 'add_adjustment_layer', 'create_composition', and 'modify_layer_properties'. There are no deviations in style, making it easy to predict and understand the purpose of each tool.
Tool Count2/5
With 92 tools, the count is excessive for an MCP server, making it overwhelming and difficult to navigate. While After Effects is a complex application, this many tools suggests poor scoping and could lead to inefficiency in tool selection and usage.
Completeness5/5
The tool set provides comprehensive coverage for After Effects operations, including creation, modification, animation, rendering, and project management. There are no obvious gaps; it supports full CRUD/lifecycle workflows for compositions, layers, masks, and effects, ensuring agents can handle complex tasks without dead ends.
Average 3/5 across 92 of 92 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 states the tool is for getting information, implying a read-only operation, but does not disclose behavioral traits such as error handling, performance considerations, or what 'detailed information' entails. This leaves gaps in understanding how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the tool's purpose. It is appropriately sized without unnecessary words, making it efficient. However, it could be slightly more informative by specifying the type of information retrieved, but it earns a high score for being direct and waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a composition tool in a rich sibling set, no annotations, and no output schema, the description is incomplete. It does not explain what 'detailed information' includes, potential return values, or how it integrates with other tools like 'get_layer_info'. This leaves significant gaps for an AI agent to understand the tool's full context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'compId' documented as 'ID of the composition'. The description does not add meaning beyond this, as it only references 'a specific composition' without elaborating on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Get detailed information about a specific composition', which is clear but vague. It specifies the verb 'Get' and resource 'composition', but lacks specificity on what information is retrieved (e.g., settings, layers, duration). It distinguishes from siblings like 'delete_composition' or 'modify_composition' by being read-only, but does not differentiate from 'get_layer_info' or 'get_mask_info' in terms of scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description implies usage when detailed composition info is needed, but it does not mention prerequisites, when not to use it, or name specific alternatives like 'list_compositions' for overviews or 'get_project_info' for broader context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'animate' implies a mutation operation, it doesn't disclose behavioral traits like whether this overwrites existing animations, requires specific layer/mask states, has side effects on composition timing, or returns any confirmation. For a tool with 4 required parameters and complex nested data, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool name that already suggests the domain (animation/masking) and front-loads the core action. Every word earns its place by specifying what gets animated and how.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex animation tool with 4 required parameters (including nested keyframe arrays), no annotations, and no output schema, the description is inadequate. It doesn't explain what 'animate' means in practice, what happens to existing animations, what the tool returns, or how it integrates with the broader animation system. The 100% schema coverage helps but doesn't compensate for missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters and their nested structures. The description adds no parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples of keyframe data, or clarify how mask shapes are defined. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Animate a mask path with keyframes' clearly states the action (animate) and target (mask path), but it's vague about the specific animation mechanism and doesn't differentiate from sibling tools like 'modify_mask_path' or 'add_mask'. It provides a basic purpose but lacks specificity about what type of animation or how it differs from related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With siblings like 'modify_mask_path' (which might adjust static properties) and 'add_mask' (which creates masks), the description offers no context about appropriate use cases, prerequisites, or exclusions for this keyframe-based animation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' suggests a write operation, but the description doesn't mention permissions needed, whether this modifies existing compositions, what happens on failure, or what the return value is. It lacks critical context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool with good schema documentation and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (including complex nested objects), no annotations, and no output schema, the description is inadequate. It doesn't explain what 'create' means in this context, what gets returned, error conditions, or how this differs from similar text-creation tools. The agent would struggle to use this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, providing good documentation for parameters. The description adds minimal value beyond the schema - it mentions 'path' but doesn't explain the relationship between text and path vertices or how textProperties relate to 'add_text_layer_advanced'. Baseline 3 is appropriate given the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create text that follows a path' clearly states the verb ('create') and resource ('text'), but it's vague about what 'follows a path' means in this context. It distinguishes from siblings like 'add_text_layer' by specifying path-following, but doesn't clarify if this creates a new layer or modifies existing text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_text_layer' or 'add_text_layer_advanced'. The description implies text creation with path constraints, but doesn't specify prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a mutation ('modify') but doesn't disclose behavioral traits like permission requirements, whether changes are destructive or reversible, rate limits, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, nested objects, no annotations, and no output schema, the description is incomplete. It lacks behavioral context, usage guidelines, and details on return values or side effects, leaving significant gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with detailed descriptions for parameters like 'orientation' and 'materialOptions'. The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions or usage examples. Baseline 3 is appropriate since the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Modify 3D properties of a layer' states the verb ('modify') and resource ('3D properties of a layer'), but it's vague about what specific properties are involved. It doesn't distinguish from sibling tools like 'modify_layer_properties' or 'set_layer_3d', leaving ambiguity about scope and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'modify_layer_properties' and 'set_layer_3d', the description offers no context on prerequisites, exclusions, or comparative use cases, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Modify' implies a mutation operation, but the description doesn't state whether this requires specific permissions, if changes are reversible, what happens to unspecified properties, or any rate limits or side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('Modify text formatting properties') with zero waste. It is appropriately sized and front-loaded, clearly stating the core function without unnecessary elaboration. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with 3 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks behavioral context (e.g., mutation effects, error handling), usage guidelines, and output expectations. The schema handles parameter details well, but the description doesn't compensate for the missing annotations and output schema, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for all parameters (e.g., 'ID of the composition', 'Text properties to modify', 'Font size in pixels'). The description adds no additional parameter information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Modify text formatting properties' states the action (modify) and target (text formatting properties), which is clear but vague. It doesn't specify what resource is being modified (text layer in a composition) or distinguish it from similar tools like 'modify_layer_properties' or 'add_text_layer_advanced' in the sibling list. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing text layer), exclusions, or comparisons to sibling tools like 'modify_layer_properties' (which might handle broader layer changes) or text-specific tools in the list. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Set properties' implies a mutation operation, but it doesn't disclose behavioral traits such as required permissions, whether changes are reversible, or error handling. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 incomplete. It lacks context on behavioral aspects, error conditions, or return values, leaving gaps that could hinder correct tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, providing good documentation for parameters. The description adds no additional meaning beyond the schema, which already details compId, layerIndex, maskIndex, and properties. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set properties of a mask' states the action (set) and target (mask properties), which is clear but vague. It doesn't specify which properties or how it differs from sibling tools like 'modify_mask_path' or 'delete_mask', making it minimally adequate but lacking differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'modify_mask_path' and 'delete_mask', the description offers no context for selection, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool performs an addition operation, implying creation/mutation, but doesn't disclose behavioral traits like whether this requires specific permissions, what happens if the composition doesn't exist, whether the layer is added at a specific position, or what the return value might be. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place in conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what an adjustment layer is, what it does, where it's placed in the composition, or what happens after addition. For a tool in a creative suite with many layer types, more context is needed to guide proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (compId and name) clearly documented in the schema. The description doesn't add any parameter semantics beyond what the schema provides—it doesn't explain what 'adjustment layer' means in terms of parameters or provide context for the name default. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resource ('adjustment layer to a composition'), making the purpose immediately understandable. It distinguishes from siblings like 'add_camera_layer' or 'add_solid_layer' by specifying the type of layer being added. However, it doesn't explicitly contrast with all sibling tools or mention what an adjustment layer does functionally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing composition), when this is appropriate versus other layer types, or what an adjustment layer enables. With many sibling tools for adding different layer types, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Add' implies a write/mutation operation, but the description doesn't specify whether this requires specific permissions, if it's reversible, what happens on success/failure, or any rate limits. It lacks critical context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a straightforward tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 incomplete. It doesn't explain what happens after adding the layer (e.g., returns layer ID, success status), doesn't mention potential side effects, and lacks usage context. The 100% schema coverage helps with parameters but doesn't compensate for missing behavioral and output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resource ('a camera layer to a composition'), making the purpose immediately understandable. It distinguishes from siblings like 'add_light_layer' or 'add_null_layer' by specifying the type of layer being added. However, it doesn't explicitly differentiate from all sibling 'add_' tools beyond the layer type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing composition), when not to use it, or what alternatives exist among the many sibling tools for different layer types or operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 but offers minimal information. It implies a write operation ('Add'), but doesn't specify permissions needed, whether the mask is editable after creation, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 incomplete. It doesn't address behavioral aspects like error conditions, return values, or side effects. Given the complexity of adding graphical elements in a creative tool context, more guidance on usage and outcomes is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter definitions (e.g., 'compId' as composition ID, 'center' as position). The description adds no additional parameter semantics beyond what the schema provides, such as explaining coordinate systems or radius units. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('elliptical mask to a layer'), making the purpose immediately understandable. It distinguishes from sibling tools like 'add_rectangular_mask' by specifying the elliptical shape. However, it doesn't explicitly contrast with the generic 'add_mask' tool, which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_rectangular_mask' or 'add_mask'. The description lacks context about prerequisites, such as needing an existing composition and layer, or when elliptical versus rectangular masks are appropriate. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a destructive operation, what permissions are needed, how it affects the layer, error conditions, or what happens on success/failure. For a tool that modifies layers, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and target, making it easy to parse quickly. Every word contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of adding effects to layers, no annotations, and no output schema, the description is incomplete. It doesn't explain what an 'expression control effect' is, how it integrates with the layer, what the tool returns, or error handling. For a tool with 5 parameters in a creative context, this leaves too much undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying the tool adds a control effect, which is already clear from the name. This meets the baseline for high schema coverage but doesn't enhance understanding of parameters like 'value' or enum choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target ('expression control effect to a layer'), making the purpose understandable. It distinguishes from siblings like 'add_loop_expression' or 'add_wiggle_expression' by specifying it's for adding a control effect, not a specific expression type. However, it doesn't explicitly differentiate from 'apply_effect' or other effect-related tools, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing composition/layer), compare to similar tools like 'apply_effect', or specify use cases (e.g., for dynamic animations). This lack of context leaves the agent to infer usage from parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('Add') but doesn't disclose behavioral traits like whether this is a destructive operation, permission requirements, side effects, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 incomplete. It lacks behavioral context, error handling, or result details, which are crucial given the tool's complexity and the absence of structured safety or output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed parameter documentation. The description doesn't add any meaning beyond the schema, such as explaining parameter interactions or use cases. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('a light layer to a composition'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'add_camera_layer' or 'add_solid_layer' beyond the specific layer type, missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, when this operation is appropriate, or how it relates to other layer-adding tools in the sibling list, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action is 'Add', implying a mutation, but doesn't specify if this requires specific permissions, whether it's reversible, what happens to existing expressions, or what the response looks like. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and target, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error conditions, or return values, leaving significant gaps for an AI agent to understand how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what's in the schema, such as explaining the purpose of 'loopType' or 'numKeyframes' in context. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the target ('a loop expression to a property'), which is specific and distinguishes it from other expression-related tools like 'add_wiggle_expression' or 'set_expression'. However, it doesn't explicitly differentiate from 'enable_expression' or 'link_properties_with_expression', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'add_wiggle_expression' or 'set_expression', nor does it mention prerequisites such as needing an existing composition or property. It lacks context about typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Add a mask to a layer' implies a write operation but doesn't specify what happens (e.g., does it modify the layer permanently, require specific permissions, or have side effects?). It lacks details about error conditions, performance characteristics, or what the tool actually returns since there's no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, front-loading the core purpose with zero wasted words. Every element earns its place, making it easy to parse quickly while conveying the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs a write operation (adding a mask) with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes success/failure, what gets returned, or how this tool differs from similar mask-adding siblings. The 100% schema coverage helps with parameters, but overall context for proper tool selection and usage is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 4 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance understanding of parameter relationships or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a mask to a layer' clearly states the action (add) and target resource (mask to a layer), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_elliptical_mask' or 'add_rectangular_mask' which also add masks, leaving some ambiguity about what makes this tool distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'add_elliptical_mask' or 'add_rectangular_mask'. There's no mention of prerequisites, context, or specific scenarios where this generic mask addition is preferred over specialized mask tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool adds a layer, implying a write operation, but doesn't cover permissions, side effects (e.g., changes to composition structure), or error handling. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the key action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool (adding a layer) with no annotations and no output schema, the description is incomplete. It lacks details on what a null object layer is, its typical use cases, or what the tool returns (e.g., layer ID). This leaves the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (compId, name, is3D) with descriptions. The description adds no additional meaning beyond implying the tool acts on a composition, which is already covered by the schema. This meets the baseline score of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('null object layer to a composition'), making the purpose understandable. However, it doesn't differentiate this from sibling tools like 'add_shape_layer' or 'add_solid_layer' beyond specifying the layer type as 'null object', which is somewhat specific but could be more explicit about what distinguishes a null object layer from other layer types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention what a 'null object layer' is used for (e.g., as a parent or controller for other layers), nor does it reference sibling tools like 'add_shape_layer' or 'add_solid_layer' for comparison. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('add') but doesn't describe what happens after addition (e.g., whether it's destructive to existing masks, if it requires specific layer types, or what the expected outcome looks like). The description lacks crucial behavioral context for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any wasted words. It's perfectly front-loaded and appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after mask addition, potential side effects, or return values. Given the complexity and lack of structured support, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, providing a solid baseline. The description doesn't add any parameter-specific information beyond what's in the schema (like explaining coordinate systems for bounds or units for roundness). It meets the minimum viable baseline but doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'add' and the resource 'rectangular mask to a layer', making the purpose specific and understandable. It distinguishes from siblings like 'add_elliptical_mask' by specifying the shape type, but doesn't explicitly contrast with the more generic 'add_mask' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'add_mask' or 'add_elliptical_mask'. There's no mention of prerequisites, context, or comparison with sibling tools, leaving the agent with insufficient usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool adds a layer, implying a write operation, but doesn't cover critical aspects like whether it requires specific permissions, if it modifies existing layers, what happens on failure, or the expected return format. The phrase 'customizable properties' is vague and doesn't detail constraints like validation or defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Add a shape layer to a composition') and adds a qualifying phrase ('with customizable properties'). There's no wasted verbiage, though it could be slightly more structured by explicitly separating purpose from context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters with nested objects, no output schema, and no annotations), the description is inadequate. It doesn't explain the return value, error conditions, or behavioral nuances like how 'shapeType' interacts with 'properties'. For a tool that creates visual elements with many options, more guidance on typical use cases or limitations is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, thoroughly documenting all parameters and nested properties. The description adds minimal value beyond the schema, mentioning 'customizable properties' which aligns with the schema's detailed 'properties' object but doesn't provide additional context like usage examples or parameter interdependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a shape layer') and target ('to a composition'), with the additional detail 'with customizable properties' hinting at configurability. It distinguishes from siblings like 'add_solid_layer' or 'add_text_layer' by specifying shape creation, though it doesn't explicitly contrast with tools like 'add_shape_path' or 'convert_mask_to_shape'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing composition), exclusions (e.g., not for text or masks), or comparisons to sibling tools like 'add_shape_path' or 'create_shape_from_path', leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Add a path' implies a write/mutation operation, but the description doesn't specify whether this creates a new path object, appends to existing paths, requires specific permissions, or has side effects. For a complex tool with 7 parameters and no annotations, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at 6 words, front-loading the core purpose without unnecessary elaboration. Every word earns its place, and the structure is perfectly efficient for conveying the basic operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 7 parameters, nested objects, no annotations, and no output schema, the description is inadequate. It doesn't address what happens after adding the path, what the tool returns, error conditions, or how it integrates with the broader After Effects context. The high parameter complexity demands more contextual information than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 86% schema description coverage, the input schema already documents most parameters well. The description adds no additional parameter semantics beyond the tool name's implication of 'path' being added. It doesn't explain relationships between parameters like how 'fillColor' and 'strokeColor' interact with the path, or clarify the 'groupName' parameter's role when optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a path to a shape layer' clearly states the action (add) and target resource (path to shape layer), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_shape_layer' or 'modify_shape_path', which could cause confusion about when to use this specific tool versus creating a new shape layer or modifying an existing path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related to shapes, masks, and paths (like 'add_shape_layer', 'modify_shape_path', 'animate_mask_path'), the agent receives no indication of prerequisites, appropriate contexts, or distinctions from similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool adds an animator but doesn't explain what that entails—whether it modifies existing layers, requires specific permissions, has side effects, or what the expected outcome is. For a tool that likely involves mutation (adding animation), this is a significant gap in transparency, as it doesn't clarify behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly. This level of conciseness is ideal for a tool description, assuming other dimensions are adequately addressed elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with nested objects, no output schema, and no annotations), the description is insufficient. It doesn't explain the tool's behavior, output, or usage context, leaving gaps in understanding how to invoke it effectively. For a tool that likely performs mutations in a creative software context, more detail is needed to compensate for the lack of structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 80%, meaning most parameters are documented in the schema. The description adds minimal value by implying the tool animates 'individual characters', which loosely relates to the 'selector' parameter's 'basedOn' enum (e.g., 'characters'), but it doesn't provide additional semantics beyond what the schema already covers. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a text animator') and the target ('to animate individual characters'), which is specific and distinguishes it from other text-related tools like 'add_text_layer' or 'modify_text_properties'. However, it doesn't explicitly differentiate from sibling tools that might also involve animation, such as 'add_wiggle_expression' or 'apply_animation_preset', leaving some ambiguity in sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a text layer first), exclusions, or comparisons to other animation tools in the sibling list, such as 'add_wiggle_expression' or 'apply_animation_preset'. This lack of context makes it harder for an AI agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('Add') but doesn't clarify if this is a mutation (likely yes), what permissions are required, whether it's reversible, or what the output looks like (e.g., success/failure, layer ID). For a tool that modifies compositions, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it easy to parse and front-loaded with the core action. It efficiently communicates the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of adding a layer (a mutation operation), lack of annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like error handling, return values, or how it differs from sibling tools, leaving the agent with incomplete context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters (compId, text, name) are documented in the schema. The description doesn't add any extra meaning beyond the schema, such as explaining the relationship between parameters or providing examples. The baseline score of 3 reflects adequate but minimal value added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resource ('text layer to a composition'), making the purpose immediately understandable. It distinguishes itself from siblings like 'add_text_layer_advanced' by being a basic version, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_text_layer_advanced' or other layer-adding tools (e.g., 'add_shape_layer'). The description lacks context about prerequisites, such as needing an existing composition, or when this simpler version is preferred over the advanced one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'advanced formatting options' but fails to specify that this is a creation/mutation tool, what permissions are needed, whether it modifies existing layers, or what happens on success/failure. This leaves critical behavioral aspects unclear for a tool with complex inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates the tool's function, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters with nested objects, no output schema, and no annotations), the description is insufficient. It doesn't address behavioral aspects like mutation effects, error handling, or output expectations, leaving gaps that could hinder an agent's ability to use the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed parameter documentation. The description adds minimal value by hinting at 'advanced formatting options', which loosely relates to the 'sourceText' object parameters, but doesn't explain specific semantics beyond what the schema already covers. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('text layer'), specifying 'advanced formatting options' to differentiate from the simpler sibling tool 'add_text_layer'. However, it doesn't explicitly contrast with other text-related tools like 'modify_text_properties' or 'create_text_on_path', keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'add_text_layer' (simpler) and 'modify_text_properties' (for existing layers), the description lacks any context about prerequisites, timing, or comparisons, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the action ('Add') but doesn't describe what happens after addition (e.g., whether rendering starts automatically, if the queue persists across sessions, or if it requires 'start_render' to initiate). It also omits potential side effects like file system writes or performance impacts. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 incomplete. It doesn't explain the return value (e.g., success confirmation, error handling, or queue status), behavioral nuances like idempotency or permissions, or how it integrates with other render tools (e.g., 'start_render'). Given the complexity of render operations and lack of structured context, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters (compId, outputPath, outputModule, renderSettings) with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as format examples for outputPath or default values for optional parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the target resource ('a composition to the render queue'), making the purpose immediately understandable. It distinguishes from siblings like 'batch_render' or 'clear_render_queue' by focusing on single-composition queue addition rather than batch operations or queue management. However, it doesn't explicitly differentiate from other render-related tools beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'batch_render' for multiple compositions or 'start_render' to begin rendering. It doesn't mention prerequisites (e.g., needing an open project or existing composition) or exclusions (e.g., not for modifying render settings after addition). Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool adds a wiggle expression, implying a mutation operation, but fails to describe what this entails—such as whether it modifies existing expressions, requires specific permissions, has side effects on animation, or returns any confirmation. This is a significant gap for a tool that likely alters composition properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It is front-loaded with the core action and target, making it easy to parse quickly. This exemplifies optimal conciseness for a tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of adding an expression (a mutation operation) with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., effects, error conditions), usage context, and output expectations. While the schema covers parameters well, the overall context for safe and effective use is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing clear details for all 8 parameters (e.g., 'frequency' as 'Wiggle frequency (times per second)'). The description adds no additional parameter semantics beyond the schema, which is acceptable given the high coverage, but it doesn't compensate with context like typical values or interactions between parameters (e.g., how 'amplitude' and 'ampMultiplier' relate).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target ('wiggle expression to a property'), which is specific and actionable. It distinguishes from siblings like 'add_loop_expression' by specifying 'wiggle' as the expression type, though it doesn't explicitly contrast with other expression-related tools like 'set_expression' or 'enable_expression'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a composition or layer), compare to similar tools (e.g., 'add_loop_expression' or 'set_expression'), or specify use cases (e.g., for animation effects). This leaves the agent with insufficient context for appropriate tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions that the tool 'automatically enables time remapping', which is useful context, but fails to describe critical behaviors like whether this is a destructive operation, what permissions are needed, error conditions, or what the output looks like (since there's no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant or unnecessary information, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that modifies layer animation with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral details (e.g., mutation effects, error handling), usage context, and output expectations, leaving significant gaps for an agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain keyframe formatting or time units). Baseline 3 is appropriate when the schema does all the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set time remap keyframes') and target ('for a layer'), with the additional detail that it 'automatically enables time remapping'. This provides a specific verb+resource combination, though it doesn't explicitly differentiate from sibling tools like 'set_time_remapping' (which might be a more general version).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when-not-to-use scenarios, or compare it to similar tools like 'set_time_remapping' from the sibling list, leaving the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Apply' suggests a mutation operation, but the description doesn't mention whether this requires specific permissions, whether the changes are reversible, what happens to existing animations on the layer, or what the expected outcome looks like. This is inadequate for a tool that modifies compositions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and resource, making it immediately understandable despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what 'applying' entails operationally, what happens to existing animations, whether there are side effects, or what success looks like. The context demands more behavioral detail than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema, which meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'apply' and the resource 'predefined animation presets', making the purpose understandable. However, it doesn't differentiate this tool from sibling animation tools like 'apply_easy_ease' or 'create_animation_curve', which would require more specific language about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 animation and effects (like 'apply_easy_ease', 'apply_effect', 'create_animation_curve'), there's no indication of when this preset application is preferred over other animation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Apply') but doesn't clarify whether this is a destructive mutation, what permissions are needed, or what happens if applied to non-existent keyframes. For a tool that modifies animation data, this is a significant gap in safety and behavior information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a tool with well-documented parameters in the schema and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'Easy Ease' means in animation terms, what the tool returns, or provide any context about the broader animation workflow. The agent would need to infer too much from the parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters or provide usage examples. The baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply Easy Ease') and target ('to selected keyframes'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'set_keyframe_interpolation_type' or 'set_temporal_ease', which might have overlapping functionality in animation contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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's no mention of prerequisites (e.g., needing keyframes to exist), exclusions, or comparison to similar sibling tools like 'set_keyframe_interpolation_type' that might handle easing differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'apply' implies a mutation operation, the description doesn't specify whether this overwrites existing effects, requires specific permissions, has side effects on layer properties, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just five words, front-loading the core action and target without any wasted words. Every element ('apply', 'an effect', 'to a layer') contributes essential information about the tool's function. This represents optimal efficiency in description length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 insufficiently complete. It doesn't explain what happens after application (success indicators, error conditions, return values), doesn't provide usage context relative to sibling tools, and offers minimal behavioral transparency. The combination of mutation operation with poor contextual support creates significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters clearly documented in the input schema (compId, layerIndex, effectName). The description adds no additional parameter information beyond what's already in the structured schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('to a layer'), specifying the resource (effect) being applied. It distinguishes from siblings like 'apply_animation_preset' or 'apply_expression_preset' by focusing specifically on visual/processing effects rather than animation or expression presets. However, it doesn't explicitly differentiate from all possible effect-related operations that might exist in other contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing composition and layer), when not to use it, or what alternatives exist for similar operations. Given the sibling tools include various 'add_' operations for different layer types and effects, this lack of contextual guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('apply') but doesn't describe what happens during application—whether it overwrites existing expressions, requires specific permissions, has side effects on the property, or what the expected outcome is. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and target, making it easy to parse quickly. There's no wasted verbiage or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (applying presets with customization parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't explain the mutation behavior, potential errors, or what happens post-application. For a tool that modifies properties with presets, more context is needed to guide safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting all 5 parameters clearly. The description adds no additional meaning beyond the schema, such as explaining how 'propertyPath' is formatted or what 'parameters' object should contain. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description doesn't compensate or enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('saved expression preset to a property'), making the purpose understandable. It distinguishes from siblings like 'add_expression_control' or 'set_expression' by focusing on applying pre-saved presets rather than creating or setting expressions directly. However, it doesn't explicitly differentiate from 'apply_animation_preset' or 'save_expression_preset', leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a saved preset first), when it's appropriate compared to 'set_expression' or 'add_loop_expression', or any constraints like property compatibility. This lack of context makes it hard for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It states this is a modification tool (implying mutation) and mentions performance benefits, but doesn't cover critical aspects like permissions needed, whether changes are reversible, error handling for invalid inputs, or what the tool returns. The performance claim is vague without context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose upfront. There's no wasted language or unnecessary elaboration - every word serves the functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 insufficient. It doesn't explain what happens when the tool executes (success/failure responses), doesn't warn about potential side effects, and doesn't provide context about the performance benefits mentioned. The agent would need to guess about behavioral characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (compId and modifications array). The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain what 'better performance' means in relation to the parameters or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Modify') and resource ('properties of multiple layers'), and specifies the benefit ('for better performance'). However, it doesn't explicitly differentiate from the sibling tool 'modify_layer_properties', which appears to be a single-layer version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'modify_layer_properties' (single-layer) or 'batch_set_expressions'. It mentions 'better performance' as a benefit but doesn't specify thresholds or scenarios where batch operations are preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Set' implies a write/mutation operation, but the description doesn't disclose whether this requires specific permissions, what happens on failure (partial updates?), whether changes are reversible, or any rate limits. It mentions performance benefit but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 insufficient. It lacks details on behavioral traits (permissions, error handling, reversibility), expected return values, and explicit usage differentiation from siblings like 'set_expression', leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (compId, expressions) and their nested properties. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and resource ('multiple expressions') with the performance benefit ('for better performance'). It distinguishes from the sibling 'set_expression' by indicating batch capability, though it doesn't explicitly name that sibling for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'for better performance' which implies usage when efficiency is needed, but provides no explicit guidance on when to use this versus the single 'set_expression' tool, nor any prerequisites, exclusions, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool removes all items, implying a destructive action, but fails to detail critical aspects like whether this action is reversible, requires specific permissions, or has side effects (e.g., stopping active renders). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, earning a top score for clarity and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and absence of an output schema, the description is insufficiently complete. It does not address behavioral risks, return values, or error conditions, leaving the agent with inadequate context for safe and effective use in a complex environment like After Effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully documenting the 'confirmClear' parameter. The description does not add any semantic details beyond the schema, such as explaining why confirmation is needed or the consequences of clearing. Thus, it meets the baseline of 3 without enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove all items') and target ('from the render queue'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_render_queue' or 'stop_render', which limits its score to 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'stop_render' or 'pause_render', nor does it mention prerequisites or exclusions. This lack of contextual direction makes it inadequate for informed tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing important behavioral traits. It doesn't mention whether closing is reversible, what happens to unsaved changes by default, whether this requires specific project states, or what the response looks like. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero wasted words. It's front-loaded with the core action and immediately communicates what the tool does without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 insufficiently complete. It doesn't explain what 'closing' entails operationally, what state the project enters, whether this affects other tools' availability, or what happens to unsaved changes by default. The agent needs more context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, but schema description coverage is 100% with a single well-documented parameter (saveChanges). The description doesn't add any parameter semantics beyond what the schema provides, but with complete schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('close') and target resource ('current After Effects project'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential alternatives like 'save_project' or 'delete_project' that might also affect project state, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or consequences. With many sibling tools that modify projects (save_project, delete_composition, etc.), the agent receives no help in selecting the appropriate tool for closing versus other project operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the conversion action but lacks critical details: whether this is a destructive operation (replacing keyframes with an expression), what permissions or prerequisites are needed, how errors are handled, or what the output looks like. For a tool that likely modifies animation data, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action ('convert') and immediately states the transformation ('keyframed animation to an expression'). There's no redundancy or unnecessary elaboration, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of converting animation data and the lack of annotations and output schema, the description is insufficient. It doesn't address behavioral aspects like side effects, error conditions, or output format, leaving the agent with incomplete context for safe and effective use. For a tool with 5 parameters and no structured safety hints, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond the schema—it doesn't explain relationships between parameters (e.g., how 'expressionType' interacts with 'customExpression') or provide context for usage. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('convert') and target ('keyframed animation to an expression'), making the purpose immediately understandable. It distinguishes itself from siblings like 'add_expression_control' or 'set_expression' by focusing on conversion from existing keyframes rather than creating or applying expressions directly. However, it doesn't specify the exact resource (e.g., 'property keyframes'), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related to expressions and keyframes (e.g., 'set_expression', 'set_keyframe', 'add_loop_expression'), there's no indication of prerequisites, typical workflows, or scenarios where conversion is preferred over other methods. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action 'convert' but lacks details on permissions needed, whether the operation is destructive to the original mask, error conditions, or output format. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and easy to parse, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a conversion tool with 5 parameters and no annotations or output schema, the description is incomplete. It doesn't address behavioral aspects like mutability, error handling, or result format, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying a conversion process, which the schema's parameter descriptions cover adequately. This meets the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'convert' and the resource 'mask to a shape layer path', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_shape_from_path' or 'modify_shape_path', which might handle similar shape operations, leaving some ambiguity about uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites, such as needing an existing mask, or compare it to siblings like 'add_shape_layer' or 'modify_shape_path', leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'copy' implies a non-destructive read-then-write operation, the description doesn't address critical behavioral aspects: whether this overwrites existing keyframes in the target property, what permissions are required, whether it works across different property types, or what happens on failure. This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a tool with well-documented parameters in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, what happens on success/failure, whether it validates property compatibility, or any error conditions. The combination of mutation behavior and missing structured documentation requires more descriptive content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond implying a source-to-target copying operation. This meets the baseline expectation when the schema does the heavy lifting, but doesn't provide extra value like explaining property path format or layer indexing conventions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('copy') and resources ('keyframes from one property to another'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'offset_keyframes' or 'reverse_keyframes' that also manipulate keyframes, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like 'offset_keyframes', 'reverse_keyframes', and 'batch_keyframes' available, there's no indication of when copying keyframes is appropriate versus other keyframe manipulation operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Create an animation with custom curve' implies a write operation, but it doesn't specify permissions needed, whether it overwrites existing data (though 'clearExisting' parameter hints at this), error conditions, or what the tool returns. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded and directly states the tool's purpose without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, mutation operation) and lack of annotations and output schema, the description is inadequate. It doesn't cover behavioral aspects like side effects, return values, or error handling, leaving significant gaps for an agent to understand how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond the schema—it doesn't explain parameter relationships, usage examples, or constraints. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'animation with custom curve', which is specific and actionable. However, it doesn't explicitly differentiate this tool from sibling tools like 'set_keyframe', 'set_keyframe_advanced', or 'batch_keyframes', which also handle animation/keyframe operations, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related to animation and keyframes (e.g., 'set_keyframe', 'batch_keyframes'), there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' implies a write operation, but the description doesn't mention whether this requires specific permissions, what happens if a project with the same name exists, whether the project is automatically saved, or what the response looks like. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple creation tool and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't explain what happens after creation, error conditions, or how the tool fits into the broader After Effects workflow. The description should provide more context given the complexity implied by the sibling tools list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the schema has 2 parameters with 50% coverage (only 'name' has a description). Since schema_description_coverage is only 50%, the description should compensate but doesn't, leaving half the parameters undocumented. The baseline is 3 because the schema provides some documentation, but the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new After Effects project'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_composition' or 'create_shape_from_path' that also create resources, so it doesn't reach the highest clarity level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'open_project' or 'create_composition', nor does it mention prerequisites or typical workflow context. It simply states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Create' implying a write/mutation operation, but doesn't disclose behavioral traits like permissions needed, side effects, error conditions, or what happens on success (e.g., returns a layer ID). For a creation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating shapes with multiple nested parameters and no output schema, the description is inadequate. It doesn't explain what the tool returns (e.g., layer ID, success status), error handling, or usage context. With no annotations and rich input schema, the description should provide more behavioral and output context to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema, such as explaining path structure or color ranges. Baseline 3 is appropriate when the schema does the heavy lifting, but no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('shape layer from a custom path'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'add_shape_layer' or 'add_shape_path', which may have overlapping functionality, leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like 'add_shape_layer' and 'add_shape_path' available, there's no indication of prerequisites, context, or distinctions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('Delete') without disclosing behavioral traits like permanence, permissions required, error conditions, or what happens to dependent layers. It mentions a confirmation parameter in the schema but not in the description, leaving critical safety aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, front-loading the core action and resource. It's appropriately sized for a straightforward deletion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is inadequate. It lacks information on consequences, success/failure behavior, or integration with sibling tools (e.g., what happens to layers in the composition). Given the complexity and risk, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (compId and confirmDelete). The description adds no additional meaning beyond implying deletion targets a composition, which is already clear from the tool name and schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a composition from the project'), making the purpose unambiguous. It distinguishes itself from siblings like 'delete_layer' or 'delete_mask' by specifying compositions, but doesn't explicitly contrast with 'duplicate_composition' or 'modify_composition' beyond the action difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'delete_layer' or 'duplicate_composition', nor are prerequisites or contextual constraints mentioned. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool performs a deletion, implying a destructive mutation, but doesn't disclose critical behavioral traits such as whether the deletion is permanent or reversible, what permissions are required, or how it affects layer indices in the composition. For a destructive tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it easy to parse. It front-loads the core action and resource efficiently, which is ideal for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, permissions, or effects on the composition, nor does it explain return values or error conditions. For a mutation tool in this context, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('compId' and 'layerIndex') documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., format details or constraints), so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a layer from a composition'), making the purpose immediately understandable. It distinguishes from siblings like 'delete_composition' or 'delete_mask' by specifying the layer resource, though it doesn't explicitly contrast with these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'delete_composition' or 'delete_mask', nor does it mention prerequisites (e.g., whether the layer must exist or be unlocked). It only states what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Delete' implies a destructive operation, it doesn't disclose whether this action is reversible, requires specific permissions, affects other layer elements, or has side effects like updating indices. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion (e.g., whether mask indices shift, if confirmation is needed, or what the return value might be), leaving significant gaps in understanding the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (compId, layerIndex, maskIndex) clearly documented in the schema. The description adds no additional parameter context beyond what's already in the schema, so it meets the baseline of 3 without compensating or detracting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a mask from a layer'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other deletion tools like 'delete_composition' or 'delete_layer' in the sibling list, which would require specifying scope or constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like 'delete_composition' and 'delete_layer' available, there's no indication of whether this is for mask-specific deletions or how it relates to other deletion operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'duplicate' implies a write operation, it doesn't specify what gets duplicated (settings, layers, effects?), whether permissions are required, if the original is affected, or what the result looks like. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple operation and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 insufficient. It doesn't explain what 'duplicate' entails in this context, what happens to the original composition, what properties are copied, or what the tool returns. Given the complexity of composition duplication in After Effects, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('duplicate') and resource ('an existing composition'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'duplicate_layer' or explain what distinguishes composition duplication from other duplication operations in this After Effects context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (like needing an existing composition), when not to use it, or how it differs from similar tools like 'create_composition' or 'duplicate_layer' in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('Duplicate') but doesn't explain what duplication entails—e.g., whether it copies properties, effects, or keyframes; if it requires specific permissions; or what the expected outcome is. This leaves significant gaps for an AI agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, contributing to clarity without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like what gets duplicated, potential side effects, or error conditions. Given the complexity implied by sibling tools (e.g., involving compositions and layers), more context is needed to ensure the agent can use it correctly without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'compId' and 'layerIndex'. The description doesn't add any additional meaning beyond the schema, such as explaining what a 'layer' is in this context or how indices work. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter details adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Duplicate') and resource ('a layer within a composition'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'duplicate_composition' or 'batch_create_layers' that might involve similar duplication logic, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention when to choose 'duplicate_layer' over 'batch_create_layers' or 'duplicate_composition', nor does it specify prerequisites like needing an existing composition or layer. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action without behavioral details. It doesn't mention permissions needed, whether this is a destructive operation, error conditions, or what happens if the expression doesn't exist. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 incomplete. It lacks behavioral context (e.g., side effects, error handling), usage guidance relative to siblings, and any details about what 'enabling' or 'disabling' entails operationally, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters (compId, layerIndex, propertyPath, enabled). The description adds no additional parameter context beyond what's in the schema, meeting the baseline for high coverage but not enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('enable or disable') and the target ('an expression on a property'), making the purpose understandable. However, it doesn't differentiate from siblings like 'add_expression_control', 'add_loop_expression', or 'set_expression', which all involve expressions but serve different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'set_expression' or 'remove_expression'. The description lacks context about prerequisites (e.g., needing an existing expression) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('execute') but doesn't mention critical behaviors like whether this is a read-only or destructive operation, potential side effects (e.g., modifying project state), error handling, or performance implications (e.g., script execution time). This is inadequate for a tool that runs arbitrary code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and context, making it easy to parse quickly. Every word earns its place by conveying essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing arbitrary code in After Effects, no annotations, and no output schema, the description is insufficient. It lacks details on safety (e.g., is this destructive?), expected outputs, error conditions, or integration with sibling tools. This leaves significant gaps for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain ExtendScript syntax or provide examples). This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('execute') and resource ('custom ExtendScript in After Effects'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'batch_execute' or specify that this is for arbitrary code execution versus predefined operations, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an open project), compare it to sibling tools like 'batch_execute' or 'set_expression', or specify use cases for custom scripting versus built-in tools, leaving the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this is a read/write operation, file system impacts, permissions needed, or output format details beyond what's in the schema. This is inadequate for a tool that likely writes files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't address key contextual aspects like what happens after export (e.g., file creation confirmation, error handling), making it insufficient for a tool that performs file output operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying frame export, which is already clear from the tool name and schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and resource ('a single frame from a composition'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'batch_render' or 'add_to_render_queue' which might also involve exporting/render operations, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an open project or composition), exclusions, or comparisons to sibling tools like 'batch_render' for multiple frames, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It doesn't disclose if this is a read-only operation, what happens if the expression doesn't exist (e.g., error vs. null), or any performance/rate limits. The description only repeats the basic action without adding context beyond what's implied by 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the core action ('Get the expression') and specifies the target ('from a layer property'), making it easy to parse quickly. Every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficient for a tool with 3 required parameters. It doesn't explain what an 'expression' is in this context, what the return value looks like, or error conditions. For a retrieval tool in a complex domain (layer properties), more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters (compId, layerIndex, propertyPath). The description adds no additional meaning beyond implying these are needed to locate the expression. This meets the baseline for high schema coverage, but doesn't enhance understanding (e.g., explaining propertyPath format beyond the schema's example).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the target resource ('expression from a layer property'), making the purpose understandable. It distinguishes from siblings like 'set_expression' or 'remove_expression' by focusing on retrieval. However, it doesn't specify what an 'expression' entails in this context (e.g., code snippet, value), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing expression), compare to similar tools like 'get_layer_info' for broader data, or specify scenarios where this is appropriate. The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it retrieves information without disclosing behavioral traits. It doesn't mention if this is a read-only operation, what format the output takes, potential errors, or any constraints like rate limits or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loading the core action. It's appropriately sized for a simple retrieval tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely returns complex layer data. It doesn't explain what 'detailed information' includes, such as properties or formats, leaving gaps in understanding the tool's full behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters (compId and layerIndex). The description adds no additional meaning beyond implying these are needed for layer identification, aligning with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a layer', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_composition_info' or 'get_mask_info' that follow similar patterns, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as needing an open project or valid layer, and doesn't mention sibling tools like 'get_composition_info' for related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool retrieves information, implying a read-only operation, but does not specify what information is returned (e.g., mask properties, count, or details), potential errors, or any side effects. This leaves the agent with insufficient context for reliable invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly and understand the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves information. It does not specify what 'information' includes (e.g., mask properties, types, or counts), leaving the agent uncertain about the return format. For a read operation with no structured output, more detail is needed to ensure proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'compId', 'layerIndex', and 'maskIndex'. The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between parameters or usage examples. Thus, it meets the baseline score of 3, as the schema adequately covers parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get information about masks on a layer' clearly states the verb ('Get information') and resource ('masks on a layer'), making the purpose unambiguous. However, it does not differentiate from potential sibling tools like 'get_layer_info' or 'get_composition_info' that might also retrieve mask-related data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Given the sibling list includes tools like 'get_layer_info' and 'get_composition_info' that might overlap in functionality, the absence of explicit usage context or exclusions is a significant gap, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('import') but lacks behavioral details: it doesn't specify if this overwrites existing footage, requires specific permissions, handles errors for invalid file paths, or provides feedback on success/failure. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action ('import footage') and specifies media types and destination without redundancy. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with external file handling) and lack of annotations or output schema, the description is incomplete. It doesn't address error conditions, return values, or side effects, leaving significant gaps for the agent to navigate. For a tool that modifies project state, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema itself. The tool description adds no additional parameter semantics beyond implying 'footage' relates to 'filePath' and 'project' relates to organization via 'folderName'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('import') and resource ('footage') with specific media types (video, image, or audio) and destination ('into the project'). It distinguishes from siblings like 'add_solid_layer' or 'create_composition' by focusing on importing external media rather than creating internal elements. However, it doesn't explicitly differentiate from potential media-handling siblings that might not exist in this list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an open project), exclusions (e.g., file format limitations), or comparisons to siblings like 'batch_create_layers' for bulk operations. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool links properties but doesn't explain what this entails—whether it creates a dynamic relationship, modifies existing properties, requires specific permissions, or has side effects like affecting render times. For a tool with 9 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action without unnecessary words. It directly communicates the tool's purpose without redundancy or fluff, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain the outcome of linking properties, potential errors, or how the expression integrates with the properties. For a tool that likely involves dynamic data relationships in a composition, more context is needed to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying a relationship between source and target properties, which is already clear from parameter names. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with extra context like examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('link') and resources ('two properties'), specifying it uses an expression. It distinguishes from siblings like 'set_expression' or 'add_expression_control' by focusing on property linking rather than general expression setting or control addition. However, it doesn't explicitly differentiate from all expression-related tools, keeping it at 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'set_expression' or 'add_expression_control', nor does it mention prerequisites such as needing an existing composition or layers. It lacks context about typical use cases, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states it modifies properties without detailing behavioral aspects like permission requirements, whether changes are reversible, error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, clearly front-loaded with the core action. It's appropriately sized for the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with nested parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavior, error handling, or output, making it insufficient for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with the 'properties' object having detailed sub-properties but the top-level 'compId' and 'properties' lacking context. The description adds no additional parameter semantics beyond the schema, so it meets the baseline of 3 without compensating for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('modify') and target ('properties of an existing composition'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'modify_layer_properties' or 'modify_text_properties', which target different resources, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention if this is for basic composition settings versus more specific modifications handled by other tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'modify' which implies mutation, but doesn't specify whether this is destructive, requires specific permissions, or has side effects. It also doesn't describe the response format or error conditions, leaving significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and target, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, no output schema, and incomplete parameter documentation (67% coverage), the description is inadequate. It doesn't address behavioral aspects like safety, response format, or error handling, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'transform properties', which aligns with the 'properties' parameter in the schema, but doesn't add meaningful details beyond what the schema already covers (67% coverage). It doesn't explain the relationship between parameters or provide examples, so it only marginally compensates for the schema's partial documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('modify') and target ('transform properties of a layer'), which is specific and distinguishes it from sibling tools like 'modify_layer_3d_properties' or 'modify_text_properties'. However, it doesn't explicitly mention what 'transform properties' include beyond what's implied by the input schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'modify_layer_3d_properties' or 'batch_modify_layer_properties'. The description lacks context about prerequisites, such as needing an existing composition and layer, or exclusions for specific layer types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a mutation ('modify') but doesn't disclose permissions needed, side effects (e.g., whether changes are reversible), rate limits, or what the response looks like (no output schema). This is inadequate for a tool with complex parameters and potential destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It lacks behavioral details, usage context, and output expectations, leaving significant gaps for an agent to understand how to invoke it correctly in real-world scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description doesn't add any meaning beyond the schema—it doesn't explain relationships between parameters (e.g., how maskShape interacts with indices) or usage nuances. This meets the baseline for high schema coverage but provides no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('modify') and target ('path of an existing mask'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'modify_shape_path' or 'animate_mask_path', which also involve path modifications, leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing mask), exclusions, or comparisons to similar tools like 'modify_shape_path' or 'animate_mask_path', leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool modifies an existing shape path, implying a mutation operation, but fails to mention critical details like whether changes are destructive, require specific permissions, or how errors are handled. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral traits, error handling, and output expectations, leaving significant gaps in understanding how to use the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema, which has 80% coverage. Since the schema descriptions are comprehensive for parameters like 'pathPropertyPath' and 'path', the baseline score of 3 is appropriate, as the description doesn't compensate for the remaining 20% gap but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('modify') and resource ('existing shape path'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'modify_mask_path' or 'add_shape_path' that also manipulate paths, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'modify_mask_path' or 'add_shape_path', nor does it mention prerequisites such as needing an existing shape path to modify. This leaves the agent without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. 'Offset keyframes in time' implies mutation (changing keyframe timing) but doesn't disclose whether this is destructive (overwrites timing), requires specific permissions, has side effects (e.g., affecting linked properties), or how errors are handled. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase with zero wasted words. It's front-loaded with the core action and target. No structural issues exist—every word earns its place by conveying essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., safety, side effects), usage guidance, and output expectations. While the schema covers parameters, the description doesn't compensate for missing annotation coverage, making it inadequate for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond implying an 'offset' parameter through the phrase 'in time'. It doesn't explain relationships between parameters (e.g., how compId, layerIndex, and propertyPath identify the target). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Offset keyframes in time' clearly states the action (offset) and target (keyframes) with a specific dimension (time). It distinguishes from siblings like 'scale_keyframe_timing' or 'reverse_keyframes' by focusing on time shifting rather than scaling or reversing. However, it doesn't specify what resource (composition/layer/property) is affected, which the schema reveals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'scale_keyframe_timing' or 'batch_keyframes'. It doesn't mention prerequisites (e.g., needing existing keyframes) or typical use cases (e.g., synchronizing animations). Usage is implied only through the action name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('Open') but doesn't describe what happens upon opening (e.g., loads project into memory, makes it active, potential performance impact, or error conditions). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of opening a project file (a mutation operation with potential side effects), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, error handling, or what the tool returns, leaving gaps for an AI agent to understand its full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'filePath' fully documented in the schema as 'Absolute path to the .aep file'. The description doesn't add any parameter details beyond what the schema provides, such as file format constraints or path examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open') and resource ('existing After Effects project file'), making the purpose immediately understandable. It distinguishes from siblings like 'create_project' (new vs. existing) but doesn't explicitly differentiate from 'close_project' or other file operations. The description is specific but lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., file must exist, project must be closed), when not to use it, or how it relates to siblings like 'create_project' or 'close_project'. Usage is implied by the action but without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action is 'Remove,' implying a destructive mutation, but doesn't disclose behavioral traits like whether this is reversible, requires specific permissions, affects other properties, or has side effects (e.g., breaking linked expressions). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It's front-loaded with the core action and target, making it highly efficient and easy to parse. Every word earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive mutation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or what happens after removal (e.g., error handling or return values). For a mutation tool in this environment, more detail is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (compId, layerIndex, propertyPath) documented in the schema. The description doesn't add any meaning beyond the schema, such as examples of property paths or how indices work. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and target ('an expression from a layer property'), making the purpose specific and understandable. It distinguishes from siblings like 'add_expression_control' or 'set_expression' by focusing on removal, though it doesn't explicitly contrast with tools like 'clear_render_queue' or 'delete_layer' that also remove things.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing expression), exclusions, or comparisons to similar tools like 'delete_layer' or 'modify_layer_properties' that might affect expressions. The description assumes context without stating it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'Change the order' implies a mutation operation, it doesn't specify whether this requires specific permissions, whether the change is immediate or reversible, what happens to other layers' indices, or potential side effects. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., success/failure, updated layer list), potential errors, or behavioral nuances like how indices are handled after reordering. For a tool that modifies data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (compId, layerIndex, newIndex) with clear descriptions. The description adds no additional parameter information beyond what's in the schema, such as format examples or edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change the order') and resource ('layers in a composition'), making the purpose immediately understandable. It distinguishes from siblings like 'delete_layer' or 'modify_layer_properties' by focusing specifically on reordering. However, it doesn't specify whether this affects z-index, timeline order, or another type of ordering, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like 'modify_layer_properties' or 'batch_modify_layer_properties' that might handle similar operations, there's no indication of when reorder_layers is the appropriate choice. No prerequisites, constraints, or comparison to other tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('reverse the order') but does not clarify if this is a destructive operation, what permissions are required, how it affects animation timing, or what the output looks like. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation on keyframes), lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like safety, permissions, or result format, which are critical for an AI agent to use the tool correctly in a production environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions (e.g., 'ID of the composition'). The description does not add any meaning beyond what the schema provides, such as explaining how 'propertyPath' relates to keyframes. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reverse the order') and target ('keyframes'), providing a specific verb+resource combination. However, it does not distinguish this tool from sibling tools like 'offset_keyframes', 'scale_keyframe_timing', or 'batch_keyframes', which also manipulate keyframes but in different ways, so it 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.
Usage Guidelines2/5
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 needing existing keyframes, or compare it to other keyframe-related tools in the sibling list, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'save' implies a write operation but doesn't disclose behavioral traits like whether it overwrites existing presets, requires specific permissions, or returns confirmation. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 incomplete. It lacks details on behavior (e.g., overwrite rules), error conditions, or return values, leaving gaps in understanding how the tool operates in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying an 'expression' is saved, which is already clear from parameter names. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('save') and resource ('expression as a preset'), specifying it's for reuse. However, it doesn't differentiate from siblings like 'apply_expression_preset' or 'set_expression', which handle different aspects of expression management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'apply_expression_preset' or 'set_expression'. The description lacks context about prerequisites, such as whether an expression must be active or valid, or when saving is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('save') but lacks details on permissions, side effects (e.g., overwriting files), error handling, or what happens if no project is open. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficient, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 incomplete. It doesn't cover behavioral aspects like success/failure responses, file overwriting risks, or dependencies (e.g., requiring an open project), which are critical for safe agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully documenting the single optional parameter 'filePath'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('save') and resource ('current After Effects project'), making the purpose immediately understandable. However, it doesn't differentiate from potential siblings like 'save_as' or 'export_project', which might exist in other contexts, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an open project), exclusions, or related tools like 'save_as' or 'export_frame', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'stretch or compress animation' which implies mutation, but lacks critical behavioral details: whether this operation is destructive to existing keyframes, what permissions are needed, how errors are handled, or what the output looks like. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with a clarifying parenthetical. It is front-loaded with the core action and wastes no words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation of keyframe timing with 5 parameters), lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like side effects, error conditions, or return values, leaving significant gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain propertyPath format or anchorTime behavior). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scale') and target ('timing of keyframes'), with the parenthetical clarifying it stretches or compresses animation. It distinguishes from siblings like 'offset_keyframes' or 'reverse_keyframes' by focusing on timing scaling. However, it doesn't explicitly differentiate from tools like 'animate_time_remap' that might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 animation manipulation (e.g., 'offset_keyframes', 'reverse_keyframes', 'animate_time_remap'), there is no indication of specific use cases, prerequisites, or exclusions. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action ('Set an expression') but lacks details on permissions, side effects, error handling, or what happens to existing expressions. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of setting expressions (a mutation operation), the lack of annotations and output schema means the description should do more to explain behavior, return values, or error cases. It's insufficient for a tool that modifies layer properties without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters well-documented in the input schema. The description doesn't add any additional meaning beyond what the schema provides, such as examples of property paths or expression syntax. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'expression on a layer property', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'add_expression_control', 'add_loop_expression', or 'batch_set_expressions', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'add_expression_control' or 'batch_set_expressions', nor does it mention prerequisites or context for setting expressions. Without any usage instructions, the agent must infer from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action but doesn't disclose behavioral traits like whether this is a destructive mutation (likely yes, given 'set'), what permissions are needed, error conditions, or what happens if a keyframe already exists at that time. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste. It's front-loaded with the core action and efficiently communicates the purpose without unnecessary elaboration, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral details (e.g., effects, error handling), usage context relative to siblings, and output information, leaving significant gaps for an AI agent to understand and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what's in the schema, which has 100% coverage with detailed descriptions for all parameters. This meets the baseline of 3, as the schema adequately documents the inputs, but the description doesn't provide additional context like examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and resource 'keyframe for a layer property', which is specific and actionable. However, it doesn't distinguish from sibling tools like 'set_keyframe_advanced' or 'batch_keyframes', leaving some ambiguity about when to choose this simpler version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like 'set_keyframe_advanced' and 'batch_keyframes' available, there's no indication of this tool's scope (e.g., for basic single-keyframe operations) or prerequisites, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'interpolation options' but doesn't disclose critical behavioral traits: whether this is a mutation (likely yes, given 'Set'), what permissions are needed, if it overwrites existing keyframes, error conditions, or response format. For a tool with 6 parameters and no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('Set a keyframe') and qualifies it directly ('with interpolation options'), making it easy to parse. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, nested objects, no output schema, no annotations), the description is inadequate. It doesn't explain what a keyframe is in context, how interpolation works, what happens on success/failure, or typical usage patterns. For an 'advanced' tool with rich parameters, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83% (high), so the baseline is 3. The description adds minimal value beyond the schema, mentioning 'interpolation options' which aligns with the 'interpolation' parameter but doesn't explain semantics like how interpolation affects animation, when spatial vs. temporal applies, or default behaviors. It doesn't compensate for the 17% coverage gap (e.g., 'value' parameter lacks description in schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and resource ('a keyframe') with a specific feature ('with interpolation options'), making the purpose understandable. It distinguishes from the simpler 'set_keyframe' sibling tool by mentioning 'advanced' interpolation capabilities, though it doesn't explicitly contrast with other keyframe-related siblings like 'set_keyframe_interpolation_type' or 'set_keyframe_velocity'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 keyframe manipulation (e.g., 'set_keyframe', 'set_keyframe_interpolation_type', 'set_keyframe_velocity'), there's no indication of when this advanced version is preferred, what prerequisites exist, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Set' implies a mutation operation, but the description doesn't mention whether this requires specific permissions, whether changes are reversible, what happens to existing interpolation settings, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for what it communicates and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what interpolation types mean in context, what happens after setting them, or any behavioral implications. The description should provide more context about this operation's purpose and effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 6 parameters with descriptions and enums. The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining relationships between parameters or providing usage examples. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and target ('interpolation type for keyframes'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'set_keyframe', 'set_keyframe_advanced', or 'set_keyframe_velocity', which all modify keyframes but for different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 multiple sibling tools related to keyframes (e.g., 'set_keyframe', 'set_keyframe_advanced', 'set_keyframe_velocity'), there's no indication of when this specific interpolation-setting tool is appropriate versus those other keyframe-modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Set' implies a write/mutation operation, the description doesn't address important behavioral aspects like whether this requires specific permissions, whether changes are destructive or reversible, what happens if invalid values are provided, or what the expected response format is. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence with zero wasted words. It's front-loaded with the core action and target, and the parenthetical 'speed graph' efficiently clarifies the technical meaning of 'velocity' in this context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after setting velocity, what valid velocity ranges are, how this interacts with other keyframe properties, or what errors might occur. The description should provide more operational context given the tool's complexity and lack of supporting structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 6 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting, though the description could have provided context about how velocity values are interpreted (units, typical ranges, etc.).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set velocity') and target ('for keyframes'), with 'speed graph' providing helpful context about what velocity means in this animation context. It doesn't specifically differentiate from sibling tools like 'set_keyframe_interpolation_type' or 'set_temporal_ease', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use this tool versus alternatives. With multiple keyframe-related tools in the sibling list (set_keyframe, set_keyframe_advanced, set_keyframe_interpolation_type, set_temporal_ease), there's no indication of how this specific velocity-setting tool relates to or differs from those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the action but does not mention permissions needed, side effects (e.g., impact on rendering or other layer properties), or error conditions. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, efficiently conveying the core action. It is front-loaded and appropriately sized for the tool's straightforward purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for a mutation tool. It does not explain what happens upon execution (e.g., success indicators, error responses) or address potential complexities like invalid inputs or layer states. This leaves the agent with incomplete context for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters (compId, layerIndex, is3D). The description adds no additional semantic context beyond what the schema provides, such as parameter interactions or examples. Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable or disable') and target resource ('3D for a layer'), making the purpose immediately understandable. However, it does not differentiate this tool from sibling tools like 'modify_layer_3d_properties', which might handle similar functionality, leaving room for ambiguity in sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'modify_layer_3d_properties' from the sibling list. It lacks context about prerequisites, constraints, or typical scenarios for enabling/disabling 3D on a layer, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a mutation operation ('Set') but does not disclose behavioral traits such as required permissions, whether changes are reversible, error conditions, or side effects. This is inadequate for a tool that modifies 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste, front-loading the core action. It is appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks details on behavioral context, error handling, or return values, which are crucial for a mutation tool. The schema covers parameters well, but overall context is insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions and an enum for 'blendMode'. The description adds no additional meaning beyond the schema, such as explaining blend mode effects or layer indexing conventions, but the schema provides sufficient baseline documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target ('blending mode of a layer'), making the purpose evident. However, it does not differentiate from sibling tools like 'modify_layer_properties' or 'set_layer_visibility' that also modify layer attributes, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'modify_layer_properties' that might handle blend modes, the description lacks context on specific use cases, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool sets relationships but doesn't cover critical aspects: whether this is a destructive mutation (likely yes, given 'set'), what permissions are needed, if changes are reversible, error conditions (e.g., invalid indices), or the expected outcome. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's front-loaded and appropriately sized for the task, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutating layer relationships) and lack of annotations or output schema, the description is insufficient. It doesn't explain behavioral traits, usage context, or what happens upon execution (e.g., does it return confirmation or error details?). For a mutation tool in a creative environment like After Effects, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters. The description adds no additional semantic context beyond what's in the schema (e.g., it doesn't explain what a 'parent-child relationship' entails in this context or how indices work). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set parent-child relationship') and the resource ('between layers'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'reorder_layers' or 'modify_layer_properties', which might also affect layer hierarchy, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing composition or layers), exclusions, or compare it to related tools like 'reorder_layers' for hierarchy changes. This leaves the agent with minimal context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Set the quality/sampling of a layer,' implying a mutation operation, but fails to disclose critical traits such as required permissions, whether changes are reversible, potential side effects on rendering, or error conditions. This is inadequate for a tool that modifies layer properties in a complex system like After Effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, front-loading the core action ('Set') and target. It efficiently conveys the tool's purpose without unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of modifying layer properties in a video editing context, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral aspects (e.g., mutability, errors), usage context, and output expectations, leaving significant gaps for an agent to operate effectively in this domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters (compId, layerIndex, quality) with an enum for quality. The description adds no additional semantic meaning beyond what the schema provides, such as explaining what 'best' quality entails or how layer indexing works. Thus, it meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target ('quality/sampling of a layer'), which is specific and distinguishes it from siblings like 'set_layer_visibility' or 'set_layer_blend_mode' that modify different layer properties. However, it doesn't explicitly differentiate from tools like 'modify_layer_properties' that might handle quality indirectly, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a valid composition and layer), exclusions, or compare it to sibling tools like 'modify_layer_properties' that might offer broader property changes. This lack of context leaves the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Control layer visibility settings' implies a mutation operation, but it doesn't specify whether this requires specific permissions, if changes are reversible, or what happens to other layer properties. For a tool with 6 parameters and no annotation coverage, this is a significant gap in transparency about its effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase: 'Control layer visibility settings'. It's front-loaded with the core purpose, has zero wasted words, and appropriately sized for a tool with a clear scope. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, mutation operation) and lack of annotations or output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error conditions, or return values. For a tool that modifies layer states in a creative application, more context about its impact and usage is needed for effective agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters clearly documented in the input schema (e.g., 'visible' for layer visibility, 'solo' for soloing). The description adds no additional parameter semantics beyond what the schema provides, such as explaining interactions between parameters (e.g., how 'solo' affects other layers). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Control layer visibility settings', which specifies the action (control) and target (layer visibility settings). It distinguishes itself from sibling tools like 'set_layer_3d' or 'set_layer_parent' by focusing on visibility-related properties, though it doesn't explicitly differentiate from tools like 'modify_layer_properties' that might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites, context (e.g., after creating a layer), or exclusions (e.g., not for non-visibility properties). With many sibling tools for layer manipulation, this lack of differentiation leaves the agent guessing about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Configure motion blur' implies a mutation operation, but the description doesn't specify if this requires specific permissions, whether changes are reversible, what happens to existing settings, or what the response looks like (e.g., success/failure confirmation). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste: 'Configure motion blur for a layer'. It's front-loaded with the core action and target, making it easy to parse quickly. No extraneous words or redundant information are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., side effects, error conditions), usage prerequisites, and any indication of what the tool returns. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially compared to siblings that may have richer descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters (compId, layerIndex, enabled, adjustmentLayer) clearly documented in the schema. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain relationships between parameters (e.g., how 'adjustmentLayer' interacts with 'enabled') or provide usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Configure motion blur for a layer' clearly states the action (configure) and target (motion blur for a layer), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'set_layer_visibility' or 'set_layer_blend_mode', but the specificity of 'motion blur' provides inherent distinction. It's not tautological with the name 'set_motion_blur' as it adds context about configuring for a layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing a valid composition and layer), exclusions (e.g., not applicable to certain layer types), or related tools (e.g., how it differs from 'modify_layer_properties' or other 'set_' tools). The agent must infer usage solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a write operation ('Set') but doesn't disclose permissions needed, whether changes are destructive to existing tangents, error conditions, or what happens if parameters are invalid. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it easy to parse quickly. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (permissions, side effects), usage guidance, and any indication of what happens after setting tangents. The high schema coverage doesn't compensate for these gaps in operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional parameter semantics beyond implying tangents relate to 'motion path', which is already suggested by parameter names. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set spatial tangents') and the target ('for position keyframes (motion path)'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'set_keyframe_interpolation_type' or 'set_keyframe_velocity' that might also affect keyframe behavior, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or exclusions. It doesn't mention when spatial tangents should be set (e.g., for smooth motion paths) or refer to related tools for other keyframe adjustments, leaving usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'Set' implies a mutation operation, the description doesn't specify whether this is destructive (overwrites existing ease settings), requires specific permissions, has side effects, or provides any feedback on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose ('Set temporal ease') and includes necessary context ('bezier handles for keyframes'). Every word earns its place, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 6 parameters affecting animation keyframes), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like error conditions, what happens if parameters are invalid, or what the tool returns. For a tool that modifies critical animation properties, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters (compId, layerIndex, propertyPath, keyframeIndex, easeIn, easeOut). The description adds no additional parameter semantics beyond what's already in the schema—it doesn't explain relationships between parameters, provide examples, or clarify concepts like 'bezier handles' or 'multi-dimensional properties.' Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target ('temporal ease (bezier handles) for keyframes'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from similar sibling tools like 'set_keyframe_interpolation_type' or 'set_keyframe_velocity', which also modify keyframe behavior in animation contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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's no mention of prerequisites (e.g., needing existing keyframes), exclusions, or comparison to sibling tools that might handle related keyframe modifications. The agent must infer usage solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Enable time remapping' implies a mutation operation, but the description doesn't address permission requirements, whether changes are reversible, potential side effects, or what happens when enabled is set to false. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for the tool's functionality and front-loads the essential information. Every word earns its place in this concise formulation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 insufficiently complete. It doesn't explain what time remapping actually does, what the expected outcome is, or provide any behavioral context. The agent would need to guess about the tool's effects and appropriate usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what the schema already provides (compId, layerIndex, enabled). This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable time remapping') and target ('for a layer'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'animate_time_remap' or other layer modification tools, which would require explicit differentiation to achieve a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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's no mention of prerequisites, when-not-to-use scenarios, or comparison with sibling tools like 'animate_time_remap' that might handle similar functionality. This leaves the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states 'Set track matte for a layer', which implies a mutation operation, but does not disclose any behavioral traits like whether it requires specific permissions, if changes are reversible, potential side effects, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, clearly front-loaded with the tool's purpose. It is appropriately sized for a straightforward tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context, usage guidelines, and details on what the tool returns or any side effects. For a tool that modifies layer properties, more information is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions and an enum for 'matteType'. The description does not add any meaning beyond what the schema provides, as it only restates the tool's purpose without elaborating on parameter usage or semantics. Baseline score of 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'track matte for a layer', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'set_layer_blend_mode' or 'set_mask_properties', which might involve similar layer property modifications, so it 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.
Usage Guidelines2/5
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 other layer property setters like 'set_layer_blend_mode' or 'set_mask_properties'. It does not mention prerequisites, context, or exclusions, leaving usage entirely implied from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool performs a conversion but doesn't disclose behavioral traits like whether the operation is destructive (implied by 'convert' but not explicit), if it requires specific permissions, what happens on failure, or the output format. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('convert text layer to shape layer') and includes a clarifying detail ('create outlines') without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimally adequate for a tool with clear purpose and fully documented parameters. However, it lacks details on behavioral aspects (e.g., mutation effects, error handling) and output expectations, which are important for a conversion tool in a creative workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (compId, layerIndex, keepOriginal) with clear descriptions. The description adds no additional meaning or context about the parameters, such as how layerIndex is determined or implications of keepOriginal. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('convert text layer to shape layer') and specifies the outcome ('create outlines'), which distinguishes it from generic text or shape tools. However, it doesn't explicitly differentiate from sibling tools like 'convert_mask_to_shape' or 'create_shape_from_path', which have similar conversion purposes but different source materials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing text layer), compare to other text or shape tools in the sibling list, or specify scenarios where conversion is appropriate (e.g., for vector editing vs. text editing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'Create' implies a write operation, the description doesn't specify what happens after creation (e.g., whether the composition becomes active, if it's saved automatically, or what permissions are required). For a creation tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a creation tool and front-loads the essential information. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, 1 required) and the absence of both annotations and output schema, the description is minimally adequate but incomplete. It states what the tool does but lacks important context about behavioral outcomes, error conditions, or relationship to other composition tools. The 100% schema coverage helps, but for a creation tool with no output schema, more behavioral context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 5 parameters clearly documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema (e.g., it doesn't explain relationships between parameters or provide usage examples). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new composition in the current project'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'duplicate_composition' or 'modify_composition', but the 'new' qualifier helps distinguish it from modification tools. The description avoids tautology by not just restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It mentions 'in the current project', which implies a prerequisite of having an open project, but doesn't specify when to choose this over alternatives like 'duplicate_composition' or how it relates to other composition management tools. No explicit when-not-to-use scenarios or comparison with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get information' implies a read-only operation, it doesn't specify what information is returned (project settings, metadata, statistics), whether it requires specific permissions, or if there are any limitations like performance considerations. The description is too vague about the actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the essential purpose without any wasted words. It's appropriately sized for a zero-parameter tool and gets straight to the point with clear subject-verb-object structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description should provide more context about what information is returned and in what format. The current description is insufficient for an agent to understand what 'information' means in this context or how to interpret the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't waste space discussing parameters that don't exist, earning a baseline 4 for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get information') and target resource ('current After Effects project'), making the purpose immediately understandable. It doesn't specifically differentiate from siblings like 'get_composition_info' or 'get_layer_info', but the focus on 'project' rather than specific components provides adequate distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_composition_info' or 'get_layer_info' for more specific information needs. It also doesn't mention prerequisites such as requiring an open project or what context this tool operates within.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions starting a render process but doesn't cover critical aspects like whether this is a blocking/non-blocking operation, error handling, progress tracking, or interaction with other render-related tools. For a tool that initiates a potentially long-running process, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without unnecessary words. It's perfectly front-loaded and every word earns its place, making it an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that initiates rendering—a potentially complex, stateful operation—the description is insufficient. With no annotations, no output schema, and minimal behavioral context, it doesn't provide enough information about what happens after invocation, error conditions, or interaction with the rendering system. The description should explain more about the rendering process it starts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't waste space discussing parameters, maintaining focus on the tool's purpose. A baseline of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start rendering') and target ('all items in the render queue'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish itself from sibling tools like 'batch_render' or 'stop_render', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'batch_render' or 'pause_render', nor does it mention prerequisites such as having items already in the render queue. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'Get' implies a read-only operation, the description doesn't specify whether this requires an active After Effects session, what happens if no project is open, or what the return format looks like. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple informational tool and front-loads the essential purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is minimally adequate. However, with no annotations and many complex sibling tools, it should ideally provide more context about when this information is useful or what specific data is returned. The description meets basic requirements but leaves gaps in practical usage understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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% (though empty). The description appropriately doesn't discuss parameters since none exist. It could theoretically mention that no inputs are required, but this is adequately covered by the schema. A baseline of 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('After Effects version information'), making the purpose immediately understandable. It distinguishes itself from siblings by focusing on system information rather than creation, modification, or animation operations. However, it doesn't specify what exactly 'version information' includes (e.g., version number, build date, compatibility).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., requires an open project), use cases (e.g., checking compatibility before applying effects), or exclusions. With many sibling tools for various operations, this lack of context leaves the agent guessing about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if this requires specific permissions, whether it's real-time or cached data, potential rate limits, or error conditions—critical for a status-checking tool in a rendering context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get the status') and resource ('all items in the render queue'), with zero wasted words. It's appropriately sized for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with no output schema, the description is minimally adequate but lacks completeness. It doesn't explain what 'status' entails (e.g., pending, rendering, completed) or the return format, which is important given the rendering context and sibling tools that modify the queue. With no annotations, more behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required, aligning with the schema. A baseline of 4 is appropriate as it doesn't contradict or omit necessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('status of all items in the render queue'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'clear_render_queue' or 'start_render', which would require mentioning it's a read-only status check versus modification actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Given siblings like 'clear_render_queue', 'start_render', and 'batch_render', there's no indication that this is for monitoring status rather than queue management or rendering operations, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'List all compositions' but doesn't specify return format, pagination, error conditions, or whether it requires specific permissions. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action ('List all compositions'), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description is minimally adequate. However, without annotations or output details, it lacks information on return format, error handling, or dependencies (e.g., project state). It meets basic needs but leaves room for improvement in contextual richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate here. A baseline of 4 is given since the schema fully covers the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all compositions in the current project'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'get_composition_info', but the scope ('all compositions') is specific enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_composition_info' or 'duplicate_composition'. The description only states what it does, not when it's appropriate or what prerequisites exist (e.g., needing an open project).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It implies a mutation action ('Pause') but doesn't specify whether this requires specific permissions, what happens to the render process (e.g., resumable vs. terminated), or what the response looks like. This leaves significant gaps for a tool that likely controls an active process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (controlling an active render process) and lack of annotations or output schema, the description is minimally adequate but incomplete. It states the purpose but misses behavioral details like effects on the render, error conditions, or response format, which are crucial for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any. A baseline of 4 is applied since no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pause') and target ('the current render process'), providing a specific verb+resource combination. However, it doesn't differentiate itself from sibling tools like 'stop_render' or 'batch_render', which would require explicit comparison to achieve a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'stop_render' or 'batch_render', nor does it mention prerequisites (e.g., whether a render must be active). It only states what the tool does, not when it should be applied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While 'stop' implies a destructive action that halts a process, the description doesn't specify whether this is reversible, what happens to the render queue, or if it requires specific permissions. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste. It's front-loaded with the essential action and target, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 0 parameters) and lack of annotations or output schema, the description is minimally adequate. It states what the tool does but omits behavioral details like effects on the render queue or system state. For a tool that likely alters system behavior, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, earning a baseline score of 4 for adequately handling this case without unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and the target ('the current render process'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'pause_render' or 'clear_render_queue', but the verb 'stop' suggests termination rather than temporary halting or queue management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'pause_render' or 'clear_render_queue'. It lacks context about prerequisites (e.g., whether a render must be active) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'for better performance', which hints at efficiency, but lacks details on permissions, side effects, error handling, or what happens if keyframes conflict. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and benefit ('for better performance'). It's front-loaded with no wasted words, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutating keyframes in a batch), lack of annotations, and no output schema, the description is minimal. It covers the basic purpose and performance aspect but doesn't address behavioral traits, prerequisites, or return values, leaving gaps for an AI agent to infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters ('compId' and 'keyframes') and their nested properties. The description doesn't add any meaning beyond what the schema provides, such as explaining the structure of 'keyframes' or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set multiple keyframes at once') and the resource ('keyframes'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'set_keyframe' or 'set_keyframe_advanced' beyond mentioning 'for better performance', which is helpful but not a full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when performance is a concern for setting multiple keyframes, suggesting it as an alternative to single keyframe operations. However, it doesn't explicitly state when not to use it or name specific alternatives like 'set_keyframe', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool adds compositions to a render queue, implying a write operation, but doesn't disclose behavioral traits like whether it requires specific permissions, if it overwrites existing queue items, or what happens on failure. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 100% schema coverage, and no output schema, the description is adequate but minimal. It covers the basic purpose but lacks details on behavioral aspects (e.g., error handling, queue management) that would be helpful given the mutation nature and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description mentions 'same settings' which aligns with parameters like outputFormat and outputModule, but doesn't add meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add multiple compositions to render queue') and resource ('compositions'), specifying the scope ('with same settings'). It distinguishes from sibling 'add_to_render_queue' by handling multiple compositions at once, though it doesn't explicitly name this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when multiple compositions need rendering with identical settings, but doesn't explicitly state when to use this vs. 'add_to_render_queue' or other rendering tools. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions parallel execution and speed. It doesn't disclose important behavioral traits like error handling, whether commands can depend on each other, what happens if one command fails, authentication needs, rate limits, or the response format. For a batch execution tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place - first stating the core functionality, then explaining the benefit. It's front-loaded with the essential information and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a batch execution tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, how errors are handled, whether there are limitations on command count, or how results are organized. For a complex batch operation tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description doesn't add meaningful parameter semantics beyond what the schema already documents about 'commands' and 'sequential' parameters. It mentions 'parallel' execution which relates to the 'sequential' parameter default, but this is already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 specific verbs ('execute multiple commands in parallel') and resource ('commands are sent to After Effects'), distinguishing it from all sibling tools which are single-command operations. It explicitly mentions the parallel execution capability that sets it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('for faster processing' when executing multiple commands), but doesn't explicitly state when NOT to use it or name specific alternatives. It implies usage for batch operations versus individual sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the tool tests connectivity, which implies it's a read-only diagnostic operation with no side effects. However, it doesn't specify what 'connectivity' entails (e.g., network, extension handshake), what success/failure responses look like, or any rate limits. The description adds basic behavioral context but leaves important details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately communicates the tool's purpose. Every word earns its place: 'Test' (verb), 'connectivity' (what's being tested), 'with After Effects CEP extension' (context). There's no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema, no annotations), the description is reasonably complete for its diagnostic purpose. However, it doesn't specify what constitutes successful connectivity testing or what the response format might be. For a connectivity test tool, some indication of expected outcomes would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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%. The description doesn't need to explain any parameters. It appropriately focuses on the tool's purpose without unnecessary parameter discussion. A baseline of 4 is appropriate for zero-parameter tools with complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('Test') and resource ('connectivity with After Effects CEP extension'), distinguishing it from all sibling tools which perform various creative/editing operations in After Effects. It precisely communicates a diagnostic function rather than a content manipulation task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when to use this tool: to test connectivity. This implies it should be used for verification purposes, likely at startup or when troubleshooting, rather than for regular editing workflows. The context clearly differentiates it from all sibling tools that perform actual After Effects operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes key behavioral traits: the tool performs a write operation (adding a layer), specifies the layer ordering (added on top), and mentions the need for reordering if used for backgrounds. However, it doesn't cover potential errors, permissions, or rate limits, which keeps it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured in two sentences: the first states the core purpose, and the second provides critical usage notes. Every sentence adds value without unnecessary elaboration, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (adding a layer with configurable properties), no annotations, and no output schema, the description is largely complete. It covers purpose, usage, and behavioral aspects, but lacks details on return values or error handling, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing details for all 5 parameters. The description does not add any parameter-specific information beyond what the schema already documents, such as explaining 'compId' or 'color' further. Thus, it meets the baseline of 3 without compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a solid color layer') and the target resource ('to a composition'), distinguishing it from sibling tools like 'add_shape_layer' or 'add_text_layer' by specifying the layer type. It provides specific functionality that is not just a restatement of the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: it notes that new layers are added on top (Layer 1) and advises to create backgrounds last or use 'reorder_layers' as an alternative. This gives clear context on when and how to use this tool versus other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes the creation behavior ('Create multiple layers at once'), ordering semantics, and a specific constraint about background layers. However, it doesn't mention potential side effects, error conditions, or what happens if the composition doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place: the core purpose, ordering rules, and a critical best practice. It's front-loaded with the main action and wastes no words while delivering essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch creation tool with no annotations and no output schema, the description does well by explaining ordering behavior and background placement. However, it doesn't address what the tool returns (layer IDs, success status) or potential error scenarios, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds valuable context about parameter semantics by explaining that 'Order matters! First = top layer, Last = bottom layer' and reinforcing 'Put backgrounds at the END of array.' This provides crucial usage guidance beyond the schema's structural documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create multiple layers at once') and resource ('layers'), distinguishing it from single-layer creation siblings like 'add_solid_layer' or 'add_text_layer'. It explicitly mentions batch creation, which sets it apart from individual layer tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Create multiple layers at once') and includes critical ordering instructions ('first item becomes Layer 1 (top), last item becomes bottom layer') and a specific rule ('Create backgrounds LAST!'). This gives clear operational context for when batch creation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ae-mcp MCP server](https://glama.ai/mcp/servers/p10q/ae-mcp/badges/card.svg)](https://glama.ai/mcp/servers/p10q/ae-mcp)

Score Badge

Copy to your README.md:

[![ae-mcp MCP server](https://glama.ai/mcp/servers/p10q/ae-mcp/badges/score.svg)](https://glama.ai/mcp/servers/p10q/ae-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/p10q/ae-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server