AE-MCP

by davidcasan

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
Disambiguation3/5
Most tools have distinct resource-action purposes, but several similar categories create ambiguity: get_comp_report vs get_composition_info vs debug_dump_layer, set_keyframe vs set_keyframe_advanced, and apply_effect vs apply_effect_template. With 68 tools, an agent needs to read descriptions carefully to avoid selecting the wrong overlapping variant.
Naming Consistency4/5
Names are overwhelmingly snake_case with a clear verb_noun pattern, such as create_composition, add_text_layer, set_expression, and remove_effect. A few outliers like get_comp_report and debug_dump_layer deviate slightly, but overall the naming style is predictable and systematic.
Tool Count2/5
68 tools is far beyond the generally well-scoped 3-15 range, making navigation and selection mentally heavy for an agent. While After Effects is a broad domain and many tools cover real sub-workflows, a great deal of the surface stdin could be consolidated or namespaced into smaller servers.
Completeness4/5
The server covers the major After Effects lifecycle: project opening/creation/saving, composition CRUD, layer addition/modification, keyframes, expressions, effects, markers, and footage/import management. Notable gaps like full video rendering or layer duplication exist, but the core workflows an agent would need are well represented.
Average 2.7/5 across 67 of 68 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and the description does not mention any side effects, permissions, or behavioral traits. It is completely opaque.
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 highly concise, consisting of a single clear sentence. It is appropriately short, though it sacrifices content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with parameters and a specific concept (adjustment layer). It does not explain what an adjustment layer is, how the parameters affect it, or provide any operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any meaning to the parameters (name, compId, compName) beyond their minimal schema descriptions. No explanation of their purpose or usage is given.
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 clearly states the action (add) and resource (adjustment layer), but it does not distinguish from sibling tools like add_solid_layer or add_text_layer, which are also adding layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 or conditions for use.
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 must carry the transparency burden, but it only names the action. It does not explain side effects, required parameters, whether an active composition is needed, failure behavior, or how adding a light layer differs from other layer additions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified rather than appropriately concise. A single phrase that merely unpacks the tool name is not enough for a six-parameter tool with no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six unannotated parameters, no output schema, and many sibling layer-creation tools, the description is far too incomplete. It does not explain what a light layer is, where it is added, or how the inputs configure it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter meaning. The six parameters such as type, color, compId, compName, and intensity must be inferred from names alone, with no explanation of the enum values or object shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a light layer' is a direct restatement of the tool name and adds no new information. It identifies the action and resource but leaves ambiguous what a light layer is and what adding it entails.
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 given about when to call this tool instead of sibling layer-creation tools such as add_solid_layer, add_text_layer, or add_camera_layer. There are no prerequisites, composition context, or alternative-tool cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. However, it simply says 'Delete a marker' and says nothing about whether the operation is destructive, reversible, if it requires any permissions, or what side effects might occur (e.g., affecting layer markers vs composition markers). This is a significant gap for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it does not provide any meaningful information. It is under-specification rather than effective conciseness, as the single sentence does not earn its place by adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is completely inadequate. It does not mention what markers are affected (composition vs layer), how markerIndex is used, or what the response looks like, leaving the agent without essential context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the parameters (compId, compName, layerName, layerIndex, markerIndex). Since the schema itself provides no descriptions, the lack of parameter explanation means the agent has no idea how to construct a valid request beyond the names and types.
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 'Delete a marker' clearly states the verb (delete) and the resource (a marker), but it does not specify what kind of marker (composition marker vs layer marker) or how it is identified, making it somewhat vague. It does not differentiate from sibling tools like add_composition_marker or delete_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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, context, or exclusions, leaving the agent to infer usage entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'Apply' which implies a mutation but gives no details about side effects, whether existing effects are overwritten, rollback capabilities, or any other behavioral traits. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but this is under-specification rather than conciseness. It lacks substance and fails to earn its place by providing valuable information. There is no structure or information hierarchy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, this description is completely inadequate. It doesn't cover the mechanics of applying a template, explain the templates available, or describe expected outcomes. The description is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 29%, and the description adds nothing about the 7 parameters. It doesn't explain the meaning of template, intensity, customParams, or how to target a layer. The description fails to compensate for the low 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 ('Apply') and the resource ('pre-configured effect template'). It distinguishes the tool's purpose from direct effect manipulation by implying a preset application, though it doesn't explicitly contrast with sibling tools like apply_effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 such as apply_effect or modify_effect_properties. The description offers no context on preferred scenarios, prerequisites, 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 bears full responsibility for behavioral disclosure. The description only says 'Delete a layer'—it does not state that the operation is destructive, whether it is reversible, if confirmation is needed, or what happens to keyframes or effects on the deleted layer. This is insufficient for a deletion operation.
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 sentence with no waste, and the purpose is immediately clear at a brief glance. However, it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 0% schema coverage, lack of annotations, no output schema, and four parameters with no context, the description is critically incomplete. An agent cannot determine how to safely invoke this tool, whether it requires additional setup, or what the outcome entails. The sparse description fails to compensate for the lack of supporting structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the four parameters (compId, compName, layerName, layerIndex). An agent must infer that these identify the target layer and composition, but no clarification is given about whether these are optional or how to use them in combination. The description adds no value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a layer' states the basic action but fails to specify what type of layer or from what context (e.g., from a composition or project). Given 28 sibling tools for adding and modifying various layer types, this vague verb+resource phrase offers no differentiation, making it hard for an agent to distinguish 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 Guidelines1/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_composition, or whether the layer deletion is permanent or requires preconditions such as selecting the correct composition. With numerous sibling tools, the absence of usage context severely undermines correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose side effects, prerequisites, or operational context. It merely states the action without noting that it modifies the current composition, requires special permissions, or has any other behavioral implications. For a mutation function, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is efficient in word count but entirely lacking in substance. It does not include any structured information that helps the agent, unlike concise descriptions that pack meaning into a few sentences. This is under-specification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no output schema, and no annotations, the one-phrase description is grossly insufficient. It doesn't explain the layer creation context, return values, or parameter relationships. This tool needs substantially more documentation to be usable by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has five parameters (name, type, zoom, compId, compName) with zero descriptions, and the tool description mentions none of them. With 0% schema description coverage, the description provides no semantic meaning for any parameter. An agent would be unable to know what compId or zoom represent.
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 uses a specific verb ('Add') and resource ('camera layer'), clearly indicating the action and object. Among sibling tools, it uniquely identifies the camera layer creation function. However, it lacks any elaboration on scope or behavior, so it's clear but minimal.
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 offers no guidance on when to use this tool over alternatives like add_solid_layer or add_text_layer. There are no prerequisites, no context about the target composition, and no mention of when a camera layer is appropriate. This is essentially no usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 merely states the action without explaining side effects, required parameters, whether it modifies the composition, or any safety considerations. This is as thin as the 'Process' example and offers no transparency beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence), but this is under-specification rather than effective conciseness. It doesn't earn its place because it provides insufficient information to guide correct invocation, similar to the 'Process' example but slightly more grammatical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, no annotations, no output schema, and many ambiguous fields (url, compId, frameTarget, cuePointName). The description is far too minimal to be complete for such a complex tool, failing to address any of the contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11% (only 'time' is described), yet the description does not explain any parameters such as compId, compName, url, chapter, comment, duration, frameTarget, or cuePointName. The description adds no meaning to the input schema and fails to compensate for the low 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 'Add a marker to a composition' clearly states the action (add) and the target (a marker to a composition). It is specific enough to understand the basic function, but it does not explicitly distinguish itself from the sibling tool 'add_layer_marker', which also adds markers but to layers.
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?
There is no guidance on when to use this tool versus alternatives like add_layer_marker. The description provides no context, prerequisites, or exclusions, leaving agents to infer usage solely from the minimal action phrase.
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 behavioral disclosure responsibility. The phrase 'Add a null object layer' only names the action; it does not disclose whether the operation is destructive, requires an existing composition, returns the created layer, or where in the layer stack the null is placed. For a mutation operation without annotations, this is a significant transparency gap.
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 with no filler or redundant phrasing. It is well-structured as a concise statement, though the brevity reflects a lack of substantive content rather than deliberate information density.
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 has 3 parameters, no annotations, no output schema, and only 33% schema description coverage, the one-sentence description is far from sufficient. It does not explain how the null layer is added to a composition, which parameter selects the target, or what the expected behavior is. The description is too minimal for an agent to use the tool reliably in the broader API context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only 'name' having a description ('Layer name'); compId and compName are undocumented. The tool description does not mention any parameters or their roles, so it fails to compensate for the low schema coverage. An agent has no way to infer whether compId and compName are alternatives, precedence, or which is required for targeting a composition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a null object layer' uses a specific verb and resource, but it essentially restates the tool name 'add_null_layer' with words. It provides no additional scope or contextual information (e.g., target composition, purpose of a null layer), and while it distinguishes from sibling layer-add tools by naming the layer type, that distinction is already present in 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?
There is no guidance on when to use this tool versus alternatives such as add_solid_layer, add_text_layer, or precompose_layers. The description does not mention prerequisites like an open project or composition, nor does it explain the relationship between compId and compName as targeting options. No exclusions or alternative tool recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The phrase 'Create an animated logo reveal' only restates the tool's function with no mention of side effects, mutation of project state, dependency on a logo item, or output format. This is a significant gap for a tool likely performing a complex creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than effective conciseness. It lacks the detail needed for an agent to understand the tool's workflow, making it a summary rather than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, this description is woefully incomplete. It fails to address what a 'logo reveal' entails, what inputs are required, what the tool will do to the project, or what the agent should expect as a result. The complexity of the tool demands much more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (2 of 7 parameters described). The description adds no parameter meaning whatsoever—it does not explain 'style', 'compId', 'compName', 'duration', or 'backgroundColor'. With such low coverage, the description should compensate, but it is entirely silent on parameter semantics.
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 'Create an animated logo reveal' clearly states a specific verb and resource, distinguishing this tool from generic creation tools like create_title_card or create_transition. However, it lacks scope details (e.g., which composition it operates on), so it's specific but not fully elaborated.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, target composition, or scenarios where this would be preferred over other creation tools like create_text_animator or create_lower_third.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no details about side effects, permissions, or the nature of the modification. It simply states that layer properties are modified without any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and contains no fluff or unnecessary words. It is well-structured as a single clear phrase, though its brevity borders on being too minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, no schema descriptions, no output schema), the description is severely incomplete. It fails to provide any context about the purpose, usage, or effects, making it nearly unusable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 20 parameters but no descriptions, and the description does not explain any of them. Parameters like 'shy', 'is3D', and 'blendMode' are left completely ambiguous, which is critical given the lack of schema-level descriptions.
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 'Modify layer properties' specifies a clear verb and resource, and it is distinct from the sibling tool 'modify_composition'. It does not specify which layer or which properties, but it is still unambiguous as a general layer modifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 other layer-specific tools (e.g., set_keyframe, apply_effect). There is no mention of prerequisites, alternatives, or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only adds 'with animations.' It fails to mention side effects, whether it creates a composition or layer, required permissions, or any other behavioral implications, making it highly opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is under-specified. It is concise yet lacks the necessary detail to serve as effective documentation, making its brevity a limitation rather than a virtue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested objects, no output schema, no annotations), the description is grossly inadequate. It provides no information about return values, parameter relationships, or expected behavior, failing to meet the contextual needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain any of the 10 parameters, including the required 'style' and 'title'. There is no semantic guidance for parameter values, leaving the agent completely without assistance.
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 the resource ('title card'), making the core purpose understandable. However, it does not differentiate from sibling tools like 'create_lower_third' or 'create_transition', so it falls short of full distinctiveness.
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 given about when to use this tool versus alternatives. The description merely states what it does without any context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No information is given about side effects, permissions required, reversibility, or error behavior. Without annotations or additional description, the agent cannot anticipate the tool's impact or potential risks.
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 one sentence, conveying the core operation without unnecessary fluff. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the schema with multiple optional parameters, the description is severely incomplete. It does not explain how the parameters relate to the reordering operation, what determines the layer, or what the expected outcome is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lists six parameters but the description does not explain the meaning or purpose of any of them (e.g., compId, layerName, effectIndex). The schema itself provides no descriptions, so parameter semantics are entirely undocumented.
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 'Reorder effects on a layer' clearly states the tool's action and target entity. It is concise and unambiguous, though it does not elaborate on the specific context or parameters involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, prerequisites, or alternatives. It entirely lacks usage context, making it difficult for an 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It merely states 'Add an expression control effect' – a mutation – but does not disclose whether it modifies the layer in place, whether it is reversible, what side effects occur, or any dependencies. This is minimal and insufficient.
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 concise sentence with no filler. It is front-loaded with the core purpose. However, it may be too brief for a tool with 7 parameters, but structurally it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no annotations, and no output schema, the description provides virtually no contextual guidance. It does not explain parameter relationships, default behavior, or prerequisites. This is severely incomplete for an effect-adding tool with multiple control types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 7 parameters, 0% description coverage. The description provides zero information about parameters like controlType, controlName, defaultValue, or how compId/layerName/layerIndex relate. There is no explanation of what the enum values mean or how default value works. The description adds no semantic value beyond the raw 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 action ('Add an expression control effect') and the target resource ('a layer'). It is a specific verb+resource construction that accurately reflects the tool's function. However, it does not differentiate itself from sibling tools like apply_effect or set_expression, which could also be used for adding controls or expressions.
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 does not mention prerequisites, typical use cases, or when not to use it (e.g., when using apply_effect might be more appropriate). With 57 sibling tools, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations or description of side effects, permissions, or return values. The description is purely functional without any behavioral detail.
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, concise sentence with no redundancy. It directly states the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks context such as error conditions, success indicators, or interaction with other tools. No annotations or output schema further reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter names are suggestive (e.g., time, compId, comment, duration, layerName, layerIndex), but there are no descriptions and schema coverage is 0%. The description does not compensate, so semantics remain largely ambiguous.
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 marker') and target ('to a layer'), but it does not specify how the layer is identified (e.g., by name or index) or distinguish it from similar tools like add_composition_marker. The core purpose is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. There is no mention of prerequisites, constraints, or when this tool should be used instead of alternatives.
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 only says 'Modify properties,' implying mutation but not explaining how existing properties are merged/replaced, whether the operation is idempotent, or what happens if multiple identifiers (e.g., compId vs compName, layerName vs layerIndex) conflict. The description is too shallow to be behaviorally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, but it is under-specified rather than appropriately concise. For a tool with 7 parameters and a nested required object, this brevity omits essential context and cannot be credited as good conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, a nested required object, no output schema, and no annotations, the description is completely inadequate. An agent cannot determine how to identify the target composition/layer/effect or how to format the properties object from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 7 parameters except the word 'properties,' which merely echoes the required parameter name. It does not explain the structure of the properties object, how to select the effect, or the relationship between compId/compName, layerName/layerIndex, and effectName/effectIndex.
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 the target resource ('properties of an existing effect'), making the basic purpose understandable. However, it does not add enough detail to distinguish it strongly from sibling effect-management tools like apply_effect, remove_effect, or reorder_effects, beyond the word 'existing'.
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 that apply_effect or apply_effect_template should be used for adding new effects, or that remove_effect handles deletion, so the agent is left to infer appropriate usage from the tool 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?
With no annotations provided, the description must disclose behavioral traits on its own. It only states 'Reverse keyframe order', which implies mutation of keyframe order but does not explain side effects, whether it affects multiple layers, how it interacts with existing keyframe selections, or whether it requires certain property formats. The lack of any additional behavioral context 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is so underspecified that it fails to provide necessary details. Conciseness should not come at the expense of essential information; here, the extreme brevity makes the description minimally useful, so it is not appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, no annotations, and five parameters with no descriptions, the description carries the full burden of explaining behavior. It does not mention the target property, layer identification, or any sequencing constraints. It is completely inadequate for an agent to understand the tool's full operational context, especially compared to the rich set of sibling keyframe tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the five parameters (compId, compName, property, layerName, layerIndex) are documented in the schema. The description does not explain any of these parameters, leaving the agent without clues about what values are expected or how they relate to each other. This is a complete failure to add meaning beyond the bare parameter names.
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 states the verb 'Reverse' and the resource 'keyframe order', which clearly indicates the core action. It somewhat distinguishes from sibling tools like 'offset_keyframes' or 'scale_keyframe_timing' by specifying reversal, but does not explicitly contrast with them. The purpose is clear for a simple operation, though it could be more specific about scope (e.g., which property or 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?
There is no guidance on when to use this tool versus alternatives such as 'offset_keyframes', 'scale_keyframe_timing', or 'copy_keyframes'. The description does not mention prerequisites, typical use cases, or when not to use it, leaving the agent without decision-making 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, and the description gives no behavioral details beyond the fact that it 'sets' something. It does not disclose whether the operation is mutating, reversible, what happens to existing ease values, or any side effects. The description fails to carry the burden of transparency for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise in length, but it is underspecified for a tool with 10 parameters. It does not front-load essential details or structure information; it simply states the action. While no words are wasted, the extreme brevity is more a deficit than a virtue given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 10 parameters, no annotations, and the complexity of After Effects keyframe easing, the description is severely incomplete. It does not explain the meaning of temporal ease, how parameters relate, or what the output/effect will be. The tool's complexity is not matched by the description, making it far from self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 10 parameters. While the schema lists parameter names and types, it lacks semantic meaning (e.g., what inSpeed and outSpeed represent, how inInfluence/outInfluence work, or how to specify the target keyframe). The description adds zero value beyond the schema, and with 0% coverage, it must compensate but does not.
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 resource ('temporal ease on a keyframe'), which conveys the core purpose. It distinguishes from siblings like set_keyframe (which sets values) and apply_easy_ease (which applies a fixed ease), though it does not explicitly name alternatives. This is a clear, specific purpose but lacks explicit 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 apply_easy_ease, set_keyframe, or scale_keyframe_timing. There is no mention of contexts, prerequisites, or when not to use it. The usage context is completely absent.
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 the full burden of behavioral disclosure. It only states the action 'Add a footage item as a layer' without mentioning side effects, required project state, or potential issues. It doesn't clarify whether this is destructive or what happens to existing layers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which makes it concise and front-loaded. However, it is under-specified rather than efficiently detailed. It earns a middle score because it's not verbose but lacks substance.
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 has five parameters and no output schema, the description is far from complete. It fails to explain key details like what startTime means, how compId vs compName are used, or what the expected return value is. The description is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about any of the five parameters. With schema description coverage only at 40%, the description should compensate by explaining compId, compName, and startTime, but it doesn't. The schema already documents itemId and itemName, so the description adds no value here.
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', the resource 'footage item', and the outcome 'as a layer', which is specific enough to distinguish from other layer-adding tools like add_solid_layer or add_text_layer. However, it does not explicitly mention the footage vs. other types differentiation beyond the name, so it's not a perfect 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?
No guidance is provided on when to use this tool versus alternatives. It simply states what it does without any context on prerequisites, when it's appropriate, or when to prefer a sibling tool like add_null_layer or add_solid_layer.
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 the full burden of behavioral disclosure, but it only states the action without explaining side effects, scope (all keyframes by default), or whether it overwrites existing easing values. It does not describe what happens to the property or whether it is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and free of fluff, which is efficient, but it is under-specified. One four-word sentence is not enough to serve as a complete tool description, so conciseness comes at the expense of necessary content.
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 7 parameters, one required parameter, no annotations, and no output schema, this description is insufficient. It omits prerequisites, behavior with omitted optional parameters, return values, and any error conditions, leaving the agent unable to confidently invoke the tool without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only keyframeIndex is documented), and the description adds no parameter-level meaning. The tool name and description repeat the obvious purpose but do not explain `property`, `type`, `compId`, `layerName`, or the interaction between `keyframeIndex` and the rest.
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 'Apply easy ease to keyframes' uses a specific verb and resource, clearly indicating it changes keyframe interpolation to an easy ease easing type. It is distinct from sibling tools like set_keyframe or set_temporal_ease, though it doesn't explicitly mention the optional single-keyframe 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 guidance is given for when to use this tool versus alternatives such as set_temporal_ease or set_keyframe_advanced. The description only implies its purpose through the name and phrase, but provides no explicit when-to-use or when-not-to-use 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 were provided, so the description carries the full burden of behavioral disclosure. It only says 'Apply a pre-built expression template'—it does not disclose side effects (e.g., whether it modifies properties, whether it is destructive, or what the output is). It adds no behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff, which earns some points for conciseness. However, it is under-specified—the brevity comes at the cost of missing critical information. It is not merely concise but incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain return values, potential side effects, or parameter roles. The lack of any guidance on usage or parameter semantics makes it inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with only 14% coverage (only 'params' has a description). The description does not explain the meaning of 'property', 'template', 'layerName', 'compId', etc. It also does not clarify how the parameters interact or provide examples. The description adds virtually no semantic value beyond the raw 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 action ('Apply') and the resource ('pre-built expression template'), which gives a clear verb+resource purpose. However, it does not distinguish itself from siblings like 'set_expression' or 'apply_effect_template'—it is not specific about what an expression template does or how it differs from simply setting an 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?
There is no guidance on when to use this tool versus alternatives. No mention of scenarios, prerequisites, or exclusions. The description only states what it does, not when or why to use 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, the description alone must explain side effects. It states 'copy' but does not clarify whether the source is modified, whether existing target keyframes are overwritten, or if the operation is reversible. This lack of detail obscures the tool's behavioral impact.
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, concise sentence with no redundancy. It is efficient, though its brevity contributes to the lack of substantive information. Still, for the content it does convey, it is well-structured and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nine parameters, no output schema, and many sibling operations), the description is severely incomplete. It does not explain how parameters interact, what the expected result looks like, or any error handling. The tool appears to require more documentation to be usable by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides nine parameters with no descriptions, and the tool description offers no explanation of any parameter. For instance, 'sourceProperty' and 'targetProperty' are self-explanatory, but 'compId', 'timeOffset', and the layer identifiers lack context. The description adds zero semantic value to the parameter list.
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 function (copy keyframes from one property to another) using a specific verb and resource. It distinguishes from sibling tools like set_keyframe or offset_keyframes by focusing on copying, though it lacks detail on what 'property' and 'keyframes' entail in this 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?
No guidance is provided on when to use this tool versus alternatives. Given the large number of sibling tools for keyframe operations (e.g., offset, scale, reverse), the model receives no indication of when copying is the appropriate operation, 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, the description carries the full burden of behavioral disclosure. It only says 'enable or disable' without explaining side effects, whether an expression must already exist, or what happens to the state. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is severely under-specified for a tool with 6 parameters. Brevity here sacrifices necessary information, making it inappropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and 6 parameters with 0% schema coverage, the description is fundamentally incomplete. It provides no information about how to identify the expression, how to specify parameters, or what the expected behavior is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it adds nothing about the 6 parameters. Only 'enabled' is inferable from the tool name; compId, compName, property, layerName, layerIndex are all unexplained, leaving their roles ambiguous.
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 states the tool enables or disables an expression, differentiating it from set_expression (which sets the expression code) and remove_expression (which removes it). However, it doesn't clarify which expression or how it is identified, so it's clear but not fully specific.
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 get_expression. There are no prerequisites, conditions, or exclusions 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, the description must fully disclose behavioral traits. It merely says 'get the expression', implying a read operation, but fails to state whether the operation is safe, if the property must exist, what happens on failure (e.g., if no expression is set), or any side effects. This is insufficient for an 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient but lacks structure to separate purpose from usage details. While not verbose, it sacrifices completeness; a short description can still be well-structured, but here it is just a bare statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no output schema, no annotations, and many siblings, the description is severely incomplete. It does not explain what an 'expression' is, how to reference a property within a layer/composition, or the return format. The agent has insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain the meaning and relationships of the five parameters (compId, compName, property, layerName, layerIndex). The description offers no parameter information at all. An agent cannot determine how to specify which property to target without additional context.
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 the expression from a property' clearly identifies the verb (get), resource (expression), and context (from a property). This distinguishes it from sibling expression tools like set_expression, remove_expression, and enable_expression. However, it does not explicitly state that it reads an existing expression, which could add 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?
No guidance is provided on when to use get_expression versus alternatives such as set_expression, remove_expression, or related tools like get_keyframes. The description does not mention prerequisites or context in which this tool is appropriate, 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 must carry the burden of behavioral disclosure. 'Remove' implies a destructive/mutating operation, but the description does not mention whether removal is permanent, what criteria define 'unused', how the optional parameters affect behavior, or whether this affects files on disk.
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 short sentence with no redundant wording, making it easy to read and front-loaded. However, it is under-specified to the point of being minimally useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no annotations, no output schema, and zero parameter documentation, a one-sentence description is far from complete. The agent cannot determine what will be removed, what parameters do, or what the result/return behavior will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention 'compId' or 'compName' at all. The agent is left guessing how these parameters relate to the removal process, which is especially problematic because both parameters are 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 states a clear action ('Remove') and resource ('project') with a scope ('unused items'), so an agent can broadly understand the tool's purpose. However, it does not distinguish itself from sibling project-management tools or define what counts as 'unused items'.
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_layer', 'organize_project_items', or 'collect_files'. There is no explicit context, prerequisite, or exclusionary note.
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 neither side effects (e.g., layer creation in current composition), requirements (e.g., open project, compId), nor return behavior. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, a single sentence with no wasted words. However, it is under-specified to the point of being unhelpful for such a complex tool, so it is not appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. It provides only a basic purpose statement and lacks essential context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (text, leading, tracking), and the description adds no parameter-level meaning. 'Advanced styling options' vaguely hints at properties like stroke, tracking, or baseline shift, but does not clarify or map to the 15 parameters. The description fails to compensate for the low 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 uses a specific verb ('Add') and resource ('text layer'), clearly stating the tool's purpose. The qualifier 'advanced styling options' hints at differentiation from the sibling 'add_text_layer', though it doesn't explicitly name the alternative.
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 the basic 'add_text_layer'. The word 'advanced' implies a use case, but there is no explicit context, prerequisites, 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, the description carries full responsibility for behavioral disclosure. It implies an action that likely copies or relocates files, but does not disclose whether the operation is destructive, requires a saved project, or how it handles missing files. No side effects are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is under-specified—concision without substance. It front-loads the primary purpose but lacks structural breakdowns for parameters or usage. It could be expanded to 2-3 sentences without being verbose.
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 3 parameters, no annotations, no output schema, and an ambiguous verb, the description is incomplete. It does not clarify the source of files, whether the project is modified, the meaning of 'collect' (copy vs move), or the effect of the boolean parameters. Given the tool's operational nature, more detail is needed to avoid misuse.
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 coverage is only 33% (only outputPath has a description). The description implies the tool collects project files, so includeFonts and includeFootage clearly control whether those file types are included, but this is inferred, not explicit. The description adds minimal value over the schema's boolean fields with no context.
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?
States a specific verb+resource+target ('Collect project files to a folder') but 'collect' is ambiguous—does it mean copy, move, or reference? There's no differentiation from siblings like organize_project_items or import_footage, so it's clear but not distinctly positioned.
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 on when to use this tool versus alternatives. It doesn't mention intended use cases (e.g., packaging, backup, portability) or prerequisites (e.g., project must be open). The sibling context suggests it's for gathering dependencies, but nothing is 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?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Add a text animator' without mentioning any side effects, requirements (like needing a compId or layerName), or limitations. It doesn't describe what happens to existing text properties or if the tool modifies layers destructively. The description is too sparse to inform the agent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified for a tool with 10 parameters unsupported by annotations or output schema. It lacks detail on usage, parameters, or outcomes, so the brevity comes at the cost of utility.
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?
With 10 parameters, no annotations, no output schema, and only 40% schema coverage, the description needs to provide substantial context. It only states the basic action, leaving the agent without guidance on animator types, required parameters, or behavioral implications. The enum for animatorType is in the schema but not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40% (four out of ten parameters have descriptions). The description mentions no parameters at all, so it doesn't add any meaning beyond the schema. With low schema coverage, the description should compensate but doesn't.
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 resource ('text layer'), making the purpose unambiguous. It distinguishes this tool from siblings like add_text_layer or add_shape_layer by focusing specifically on animators. However, it doesn't mention the variety of animator types available, which is evident from the enum but not in the description.
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?
There is no guidance on when to use this tool versus other animation-related tools, no prerequisites (e.g., must have a text layer), and no conditions for using different animator types. The description only states what it does, not when or how to use it 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?
No annotations are provided, so the description carries full burden. The description does not disclose whether the tool is destructive (e.g., overwrites existing properties), whether partial updates are allowed, or if there are side effects. For a mutation tool with 8 parameters, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence is concise but lacks structure. It fails to expand on the operation, leaving the agent to rely entirely on the schema. While not verbose, it does not provide a clear, front-loaded summary of 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 8 parameters, no required params, nested objects, and no output schema, the description leaves significant gaps. It does not explain return values, error behavior, or how partial updates work. The tool is moderately complex, and the description is too minimal.
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 each parameter's purpose. However, the description adds no extra semantics, such as format constraints for backgroundColor (e.g., RGBA vs hex), or whether values are optional and what the default behavior is. Baseline 3 is appropriate since schema covers all params.
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 'Modify an existing composition', which clearly identifies the verb (modify) and resource (composition). However, it does not differentiate from sibling tools like 'modify_layer' or 'modify_effect_properties', which have similar structure. The input schema shows many editable properties, adding some 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 given on when to use this tool versus alternatives like 'modify_layer' or other composition-specific tools. There is no discussion of prerequisites (e.g., composition must exist), or when to use compId vs compName. This forces the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 operation is a removal (implying mutation) but doesn't disclose whether the effect is permanently deleted, whether it requires the composition to be open, or what happens if the effect/layer is not found. This is a minimal one-liner with no behavioral depth.
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, concise sentence with no filler. It is front-loaded and immediately understandable, though it sacrifices necessary detail for 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?
With 6 parameters, 0% schema description coverage, no annotations, and no output schema, the description should compensate by explaining parameter semantics, identification methods, and error behavior. It does none of this, leaving the agent to guess how to specify targets or handle failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is 0% schema description coverage, so the description must clarify parameter semantics. It only mentions 'effect' and 'layer' but doesn't explain the relationship between compId/compName, layerName/layerIndex, or effectName/effectIndex. Users are left unsure which parameters are alternatives, required, or how they interact.
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 resource (effect from a layer). It distinguishes from sibling tools like delete_layer (deletes entire layer) and modify_layer (edits layer properties). However, it doesn't clarify scope (which composition or layer) beyond the parameters.
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 on when to use this tool versus alternatives like modify_layer or set_keyframe. No mention of prerequisites (e.g., composition must be open, effect must exist) or how layer/effect identification works.
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 it only says 'Save the current project'. It doesn't disclose whether saving overwrites the existing file, if it creates a new file, or if it requires a path. Behavior like overwriting or prompting for confirmation is hidden. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but is concise. However, it is under-specified for a tool with multiple sibling tools and no annotations. A slightly longer description with more detail would improve usefulness without losing 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 (1 param, no annotations, no output schema) and the large number of sibling tools, the description is incomplete. It doesn't explain the return value, error conditions, or how it differs from similar tools like collect_files. The agent would likely struggle to use this tool 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?
There is only one optional parameter (path), and the schema description covers it fully. The tool description adds no extra meaning beyond the schema, so with 100% schema coverage, a baseline of 3 is appropriate. However, it could clarify what happens if path is omitted (e.g., save to current file).
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 tool name and description clearly state it saves a project, but the description 'Save the current project' is generic and doesn't distinguish it from sibling tools like close_project or open_project. The scope is vague (e.g., does it save to the current file or ask for a new one?). With 42 sibling tools including save-related ones, more specificity is needed.
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 save_project versus alternatives like collect_files or reduce_project, which also involve saving. There's no mention of prerequisites (e.g., project must be open) or when not to use this tool. The context hints are not leveraged.
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 carry the full burden of behavioral disclosure. It only says 'set a keyframe with easing options,' but doesn't explain what happens to existing keyframes, how easing affects interpolation, whether the tool mutates the project state directly (likely yes), or any side effects. It doesn't describe return behavior or errors. For a mutation tool, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified. Conciseness should still provide necessary information; this fails to do so, as it says nothing beyond a tautological expansion of the tool name. It's not front-loaded with useful content.
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 high complexity (11 parameters, nested objects, enums), minimal schema coverage, and no output schema, the description is severely incomplete. It doesn't explain the easing model, how to specify target layers (layerName vs layerIndex), or the meaning of 'inEase'/'outEase' objects. The agent would likely misuse the tool without additional info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is very low (3 out of 11 parameters are described, ~27%). The description adds nothing about parameter semantics beyond the schema's enum and property names. For instance, 'inEase' and 'outEase' are not explained, nor how 'compId' vs 'compName' are used. The description fails to compensate for the low 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 ('Set a keyframe') and the resource ('property'), and distinguishes it from the simpler 'set_keyframe' sibling by implying advanced easing options. It is concise and specific, though it doesn't explicitly mention the tool's focus on easing 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?
No guidance is provided on when to use this tool over alternatives like 'set_keyframe', 'apply_easy_ease', or 'set_temporal_ease'. There is no mention of prerequisites (e.g., needing a composition/layer context), nor when NOT to use it. The description offers no context about typical use cases or selection criteria.
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 only says 'Set the work area', which implies a mutation but does not specify the effects (e.g., whether existing work area settings are overwritten, if it affects playback or rendering, or if it requires the composition to be open). It also does not state whether the operation is reversible or if there are side effects on existing layers or markers. This lack of detail is significant for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is too minimal – it provides the bare minimum without any elaboration. It is structured with the verb first, which is good, but it lacks any additional context that would make it effective. It is not wasteful, but it is under-specified, so it earns a middle score.
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 there is no output schema, no annotations, and a moderate parameter count with 50% schema coverage, the description is insufficient. It explains the basic action but does not cover edge cases, prerequisites, or the full meaning of parameters like 'compId' and 'compName' (e.g., which one takes precedence, or if either is sufficient). For a mutating tool with optional parameters, deeper context is needed, but the description only states the obvious.
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 'start' and 'duration' described as times in secondscars. The description itself does not add any parameter semantics beyond what the schema provides ow – it just says 'set the work area' without explaining how start and duration define it. For the two undocumented parameters ('compId' and 'compName'), the description offers no guidance, but the baseline for 50% coverage is 3, which is scored because the schema gives some meaning and the description does not contradict it.
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 action ('Set the work area') and the resource ('a composition'), which is clear enough for basic understanding. However, it does little to distinguish this from siblings like 'modify_composition' or 'get_composition_info' — the verb 'set' implies mutation, but the specific scope (work area) is the only differentiator. The description lacks detail on what 'work area' means in context (e.g., it may refer to the In/Out points of the composition timeline).
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 given on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., selecting a composition) or when not to use it. The context of composition management is implied by the sibling tools, but the description itself offers no usage context, leaving the agent to infer 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects. It does not mention whether copying modifies the source layer, replaces existing effects on the target, or requires any prerequisites, leaving the behavior opaque.
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 concise sentence with no superfluous words. It is easy to read and lacks clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely sparse and does not cover important context such as return values, error handling, or how effects are copied (e.g., whether they are referenced or duplicated). Given the absence of an output schema and annotations, this lack of completeness severely hampers usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists seven parameters but provides no descriptions, and the tool description does not clarify their roles. It does not explain the relationship between names and indices, nor whether effectIndices is optional, leaving the agent without essential parameter information.
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 (copy) and the resource (effects) with a specific source and destination. It is distinct from sibling tools like apply_effect or remove_effect, making its intended function 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 on when to use this tool versus alternatives such as apply_effect or duplicate_effect. It does not mention any specific scenarios or edge cases, leaving the agent without clear usage criteria.
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 responsibility for behavioral transparency. It does not state whether this is a destructive action (e.g., overwriting existing comps), what side effects occur (e.g., timeline creation), or if the composition becomes the active one. The description is too brief to disclose any behavioral traits beyond the existence of creation.
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, concise sentence with no fluff or repetition. It is appropriately front-loaded and immediately understandable. It earns its place, though it could benefit from slight expansion for clarity.
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 a composition (6 parameters, nested objects, no output schema), the description is inadequate. It does not explain what is returned (e.g., composition ID), the significance of the background color object, or any constraints like aspect ratio limits. An agent using this tool would need external knowledge 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 already documents all parameters and their types. The description adds no additional parameter context (e.g., valid ranges for width/height, pixel aspect ratio, or default behavior for backgroundColor). However, since the schema fully covers the parameters, the baseline score of 3 is appropriate—the description provides no extra value but doesn't hurt.
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 uses a standard verb-resource pattern ("Create a new composition"), which is clear and unambiguous. However, given the large sibling list with other creation tools like create_project and add_solid_layer, the description lacks any differentiation or scope detail (e.g., that composition is the primary container in After Effects). It is functional but minimally informative.
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 vs. alternatives. For example, compared to create_project or the various add_*_layer tools, there is no context for what a composition is or when composition creation is the right step. The description is purely declarative with no usage hints.
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, and the description only says 'Create a transition effect layer' without disclosing behavioral details such as side effects, required properties, or how the layer interacts with compositions. This leaves the agent with insufficient understanding of 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is concise but under-specified. It does not waste words, but it omits essential details about parameters and usage, making it less effective than a well-rounded concise 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?
The tool has six parameters, no annotations, and no output schema, yet the description only offers a single basic sentence. It does not explain what a transition effect layer is, what the parameters control, or how it fits into the broader workflow, making the description inadequate for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the six parameters (type, color, compId, easing, compName, duration) or their meanings. With 0% schema description coverage, the description fails to compensate for the lack of parameter context, even though the schema provides enums for type and easing.
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 'transition effect layer', which gives a specific purpose. It distinguishes from siblings since no other transition tool exists, but lacks details about transition types or 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 like add_solid_layer or apply_effect. There is no mention of prerequisites, suitable scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, permissions, or result behavior. It only says 'duplicate' with no indication of whether the original is preserved, what properties are copied, or what the tool returns.
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, consisting of a single sentence with no unnecessary words. It is well-structured and directly states the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 severely incomplete. It does not explain the result of duplication, whether it returns a new ID, or any preconditions. The overall context is missing, making it difficult for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal descriptions (e.g., 'Composition ID', 'Name for the duplicate', 'Composition name'), but the tool description adds no further meaning. The purpose of 'compName' is ambiguous—it could be the original name or a redundant field—and the description does not clarify.
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 'Duplicate a composition' is a clear verb-object phrase that precisely states the tool's function, distinguishing it from siblings like create_composition or delete_composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 (e.g., create_composition). It lacks any contextual cues such as 'when you need a copy of an existing composition'.
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 explaining behavioral traits. It mentions no side effects, such as moving or copying items, requiring existing folders, whether the operation is reversible, or how it may affect the project's file structure. This is insufficient for a tool that likely modifies the project's organization.
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 succinct sentence with no redundant words or filler. However, the conciseness is achieved at the cost of missing critical detail; it is not ideal concise but rather minimal, though still well-formatted and front-loaded.
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 organizing items, the absence of output schema, annotations, and any parameter explanation leaves significant gaps. There is no mention of how the tool organizes items of what the expected outcome is, or what happens when no parameters are provided. The description is too incomplete to support payload and execution expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'structure' or 'customFolders'. The enum values 'type', 'usage', 'custom' are left undefined, and the relationship between 'structure' and 'customFolders' is not clarified. The description adds no meaning beyond the schema's bare parameter list.
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 a specific action ('Organize project items') and the target resource ('folders'), which distinguishes it from sibling tools like import_folder or collect_files. However, 'project items' is slightly vague, leaving room to clarify whether it refers to assets, compositions, or other project nodes.
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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites, limitations, or use cases for different values of 'structure' (type/usage/custom). The description simply restates the core purpose without contextualizing the scenarios where this tool is the right choice.
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 only says 'Remove expression' without disclosing side effects, reversibility, failure behavior, or required permissions. This is minimal and insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is under-specified rather than appropriately concise. It lacks structure or additional context, making it borderline between adequate and insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return values, parameter relationships, or edge cases, making it inadequate for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0% and no parameter details in the description, the agent has no information about what 'property' means or how compId/compName/layerName/layerIndex identify the target. The description fails to compensate for the missing schema info.
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 action: 'Remove expression from a property'. It uses a specific verb and resource, and the name 'remove_expression' distinguishes it from siblings like 'set_expression' and '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 such as set_expression with an empty value or enable_expression with false. It does not mention any conditions or prerequisites, leaving the agent 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 must fully disclose behavior. It states the operation speeds up or slows down keyframe timing, but does not mention whether it is destructive, what happens to keyframe values, how anchorTime affects the operation, or any requirements like property type or keyframe selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded with the action, making it concise. However, it is too minimal for the tool's complexity, omitting essential details, so it is not as effective as it could be.
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 7 parameters, no annotations, and no output schema, this one-sentence description is inadequate. It does not explain how the scale factor is interpreted, what anchorTime does, or how the target layer or composition is specified, creating significant gaps for an agent to correctly use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, with only 'scale' and 'anchorTime' having descriptions. The tool description adds no parameter meaning beyond the schema; critical parameters like property, compId, compName, layerName, and layerIndex remain unexplained, leaving the agent without enough information to invoke the tool correctly.
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 uses the specific verb 'Scale' and resource 'keyframe timing', with a parenthetical clarifying the effect as 'speed up or slow down'. This makes the tool's purpose clear and distinguishes it from related operations like offset or reverse, though it doesn't explicitly name alternative tools.
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 given on when to use this tool versus alternatives such as offset_keyframes or reverse_keyframes. The parenthetical implies timing adjustments, but there are no explicit use cases, exclusions, or recommendations for other timing edits.
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 it only restates the tool's basic action. It does not mention whether applying an effect replaces existing effects, how effect lookup/match name works, whether properties are merged or overwritten, or what side effects occur on the layer.
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 concise sentence that front-loads the core purpose. It is appropriately short, though it sacrifices useful detail for 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 six parameters, a nested properties object, no annotations, no output schema, and a crowded sibling set of effect-related tools, this description is far too sparse. It lacks critical context about required identifiers, effect selection, parameter passing, and expected outcomes, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 33%, and the description adds no parameter explanations beyond the two already described in the schema. The names compId, compName, layerName, and layerIndex are somewhat self-explanatory, but there is no clarity on identifier precedence, optionality, or how the properties object maps to effect controls.
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 'Apply an effect to a layer' clearly states the verb and resource, indicating the core action. However, it does not distinguish this from sibling tools like apply_effect_template or modify_effect_properties, which also involve applying or altering effects.
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?
There is no guidance on when to use this tool versus alternatives such as apply_effect_template, modify_effect_properties, or list_effects. The description gives no context about prerequisites, selection criteria, or typical scenarios, so the agent receives no 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, the description bears the burden of disclosure. It only mentions 'with animated text', hinting at animation but not revealing side effects, composition/layer creation, or output. It does not explain whether the tool modifies the project or creates new items, nor does it discuss any destructive or non-destructive aspects.
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 concise sentence with no unnecessary words, front-loading the core purpose. However, it is under-specified for the tool's complexity, so the conciseness is not paired with adequate structure or additional sections that would help the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters, no annotations, no output schema, and nested object parameters, making it a highly complex tool. The description provides almost no contextual information about defaults, parameter interactions, or the internal behavior, rendering it completely inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 31% (only 4 of 13 parameters have descriptions). The description adds no parameter information whatsoever, failing to compensate for the low coverage. It doesn't even connect 'animated text' to the animateIn/animateOut fields, leaving most parameters semantically opaque.
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 verb 'Create' and a specific resource 'lower third graphic', and adds 'with animated text' which further differentiates it from siblings like create_title_card or create_transition. The purpose is unambiguous and distinguishes the tool's specific function.
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 gives no guidance on when to use this tool versus related creation tools such as create_title_card, create_logo_reveal, or create_text_animator. It lacks any context about prerequisites, scenarios, 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 the full burden of behavioral disclosure. It doesn't state whether this is a read-only operation, what happens if the property has no keyframes, or whether it returns keyframe values, times, or both. The description is minimal and lacks behavioral 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. However, it is under-specified, which is a completeness issue rather than a conciseness issue. The structure is fine, but the content is too sparse.
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 has 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain how to specify the target property (e.g., by name or path), how to identify the composition and layer, or what the return format is. The agent would need to infer too much from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. The schema lists five parameters (compId, compName, property, layerName, layerIndex) but the description only mentions 'property', leaving the agent to guess how to identify the composition and layer. The description adds no value beyond the schema's parameter names.
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 all keyframes from a property' clearly states the action (get) and the resource (keyframes from a property). It is specific enough to distinguish from sibling tools like set_keyframe, set_keyframe_advanced, and other keyframe manipulation tools, though it doesn't explicitly mention the context of a composition or 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 that it retrieves keyframes for a specific property, nor does it clarify the need to specify a composition and layer. Sibling tools like get_expression or get_layer_info are not referenced, so the agent has no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey side-effect behavior. The verb 'Get' strongly implies a read-only operation, but it doesn't explicitly state that or mention any permissions or limitations. A user could reasonably infer no side effects, but it's not guaranteed.
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, concise sentence that leads with the verb 'Get' and the resource. It is front-loaded and does not waste words, though it is arguably too brief to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a retrieval tool: it does not mention what information is returned, the format of the output, or any error conditions (e.g., missing layer or invalid index). Without an output schema or further detail, a caller cannot predict the tool's results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the four parameters (compId, compName, layerName, layerIndex). It doesn't clarify how to specify the layer (by name vs. index) or that a composition must be identified. Since the schema provides no descriptions either, the user is left guessing about required inputs and their combinations.
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 detailed information') and the resource ('a layer'), which distinguishes it from the many modifying layer tools in the sibling list. However, it lacks specifics on what 'detailed information' entails.
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 that it is appropriate for retrieving metadata, or contrast with other getters like 'get_composition_info' or 'list_layers'. No context or prerequisites are given.
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 it only says 'set a keyframe.' It does not indicate whether an existing keyframe at the given time is replaced, how interpolation defaults behave, whether the operation mutates the project, or what happens when multiple comps/layers match the selection criteria.
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 short sentence with no filler, making it easy to parse and front-loaded. Its brevity is structurally clean, though it sacrifices substantive context that other dimensions capture.
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 7 parameters, no annotations, no output schema, and a large family of sibling keyframe tools, the description is incomplete. It does not explain how a target layer or composition is identified, what value shapes are expected beyond the schema enum, or what the result of the operation looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, so the description needs to compensate, but it adds almost nothing beyond the word 'property.' It does not explain how compId, compName, layerName, and layerIndex are resolved, which is a major missing selection semantic for a 7-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 a specific action ('Set a keyframe') and an object ('a property'), so an agent can tell this is a keyframe-insertion tool rather than a query or easing operation. However, it does not explicitly differentiate it from the similarly named sibling set_keyframe_advanced or other keyframe-modification tools.
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 given for when to use this tool vs set_keyframe_advanced, apply_easy_ease, offset_keyframes, or get_keyframes. The description is only a verb phrase and provides no exclusions, prerequisites, or contextual decision support.
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?
There are no annotations, so the description carries the full burden. It only states the basic action and does not disclose behavioral traits such as output format, ordering, handling of nested layers, or potential side effects. As a read-only operation, the safety profile is inferred but not stated.
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 concise sentence with no filler. It front-loads the core action and resource, making every word count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two optional, undocumented parameters and no output schema, the description is far from complete. It does not explain parameter usage, how the composition is selected, or what the return value looks like, leaving critical gaps for an agent attempting to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what compId or compName mean, whether they are alternatives or required, or what happens when both are omitted. With both parameters optional and no clarification, the tool's identification of the target composition is ambiguous.
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 'List all layers in a composition' uses a specific verb and resource, clearly indicating the tool enumerates layers within a composition. It distinguishes itself from siblings like get_layer_info (which likely retrieves a single layer's properties) by explicitly stating 'all layers'.
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, or any exclusions. The use case is only implied by the tool's name and description, with no explicit context about when choosing list_layers is appropriate (e.g., for overview vs. single-layer details).
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?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only says a text layer is added, but does not indicate defaults, behavior when no compId/compName is provided, or any side effects or required 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, front-loaded sentence with no redundant words or filler. It is appropriately sized for the level of detail it delivers.
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?
Despite having 9 parameters, nested objects, and no output schema, the description provides only the bare mutation action and omits context such as how the composition is targeted, defaults for optional fields, and what the result of the operation is. Additional context is needed for the tool to be safely selected and invoked.
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 78%, so the schema already documents most parameters sufficiently. The description adds no further parameter meaning, but this is acceptable given the high schema coverage. A few properties like position and justification lack descriptions, but the description does not help compensate.
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 layer to a composition') with a specific verb and resource. However, it does not distinguish this tool from the sibling tool 'add_text_layer_advanced'.
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 like add_text_layer_advanced, add_solid_layer, or other layer-creation tools. The intended use is only vaguely implied by the 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?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Close the current project' without specifying what happens to unsaved changes, whether confirmation is required, or whether the operation is reversible. The existence of a 'save' parameter implies optional saving, but the description does not explain the default or the consequence of not saving.
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?
Description is a single, front-loaded sentence with zero extraneous information. Every word is earned for a simple close 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?
Tool is simple (1 optional param, no output schema) but description fails to specify return behavior, side effects (e.g., unsaved data handling), or post-close state. Without output schema, agent needs to know what the tool returns or signals failure, which is absent.
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 coverage is 100% for the single 'save' parameter, which already has a description. The tool description adds no additional meaning or usage guidance for the parameter. Per criteria, baseline 3 is appropriate since the schema handles the burden, but the description does not 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?
Description states 'Close the current project' with a clear verb-resource pair. It immediately conveys the action and target. While it doesn't distinguish from sibling tools, the action is distinct enough (close vs. open, save, create) that 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?
No guidance on when to use this tool versus alternatives such as save_project or open_project. No mention of prerequisites (e.g., a project must be open) or exclusions. The agent is left 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 exist, so the description must fully disclose behavior. It only says 'create a new project' without specifying what happens to the current project, whether a file is saved, or if any side effects occur. This is inadequate for a tool that likely modifies the application state.
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 extremely concise (5 words, one sentence) and front-loaded with the key action. However, it is so minimal that it sacrifices completeness for brevity, which slightly reduces the score from a perfect 5.
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 simplicity (one optional parameter, no output schema, no annotations) and the large set of sibling tools, the description is insufficient. It fails to explain what 'creating a project' entails (e.g., does it replace the current project? Is it saved to disk? What is the return value?). This leaves the agent with critical gaps.
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 covers the single parameter with 100% description coverage ('Optional project name'). The description adds no additional meaning beyond the schema, so it meets the baseline of 3 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 ('create') and resource ('new After Effects project'), distinguishing it from siblings like 'open_project' or 'save_project' by implying a new project. However, it does not explicitly differentiate from other creation tools (e.g., 'create_composition').
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 such as 'open_project', 'save_project', or 'close_project'. The agent receives no context on prerequisites, workflow order, or when creation 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The phrase 'Get detailed information' implies a read operation but does not disclose what information is returned, whether any side effects occur, or what error cases 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 a single, front-loaded sentence with no filler or redundant phrasing. It earnestly conveys the tool's basic function in minimal space.
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?
Although the tool is simple, there is no output schema and no annotations, so the description should clarify what 'detailed information' includes and how it relates to the overlapping get_comp_report sibling. The current description is too vague to fully guide an agent in selecting or invoking the tool 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 compId and compName already have basic descriptions. The tool description adds no further meaning, and the fact that both parameters are optional while none are required leaves ambiguity about whether one, both, or specific combinations are expected.
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 identifies the action ('Get') and the resource ('detailed information about a composition'), so the core purpose is recognizable. However, it does not distinguish itself from the sibling tool get_comp_report, which likely overlaps in purpose.
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 offers no guidance on when to use this tool versus alternatives like get_comp_report, get_project_info, or list_compositions. It also does not state any prerequisites, required identifiers, 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, the description carries the full burden of behavioral disclosure, but it does not explain side effects such as whether the old file is deleted, how project references are updated, or if the new file must exist. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is concise and front-loaded. However, it is under-specified, omitting necessary context, which slightly reduces the score.
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?
The tool is a mutation with no annotations and no output schema, yet the description provides no side-effect details, return behavior, or prerequisites. This is inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only newPath is described in the schema, and the description does not clarify the roles of itemId and itemName. With schema coverage at 33%, the description should compensate but fails to add meaning beyond 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 action ('replace') and the resource ('footage item'), which distinguishes it from sibling tools like import_footage. It's specific and 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?
No guidance is provided on when to use this tool versus alternatives such as import_footage or modify_layer. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Set an expression' but does not indicate whether it overwrites an existing expression, requires an existing property, or how invalid expressions are handled. It also fails to mention the way the target is identified (via comp/layer parameters).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is concise and front-loaded. However, it is so brief that it omits necessary context, making it under-specified rather than efficiently detailed. It earns a 3 because it is not overly verbose but lacks substance.
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 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain how to specify the target property, whether the expression replaces or appends, or what errors might occur. The description provides only a minimal hint of functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 17% of the schema is described (just the 'expression' field has a description). The description adds no extra meaning for the other parameters—compId, compName, property, layerName, layerIndex—and does not clarify how they are used together. It does not compensate for the low 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 action ('Set an expression') and the resource ('a property'), which is specific and differentiates it from siblings like get_expression and remove_expression. It is unambiguous and concise.
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 enable_expression, add_expression_control, or apply_expression_template. There is no mention of context, exclusions, or complementary 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?
Annotations are absent, so the description must disclose behavioral traits. It only says 'find', which suggests a read-only operation, but does not specify side effects, permissions, or what counts as 'missing' (e.g., unlinked files). With no annotations, the description omits important behavioral nuance.
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?
Single sentence with no fluff, front-loads the key verb 'find'. It is appropriately sized for a simple query tool, though it could add a brief note on output usage without hurting conciseness.
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 parameters, no annotations, no output schema, and a straightforward read purpose, the description is minimally complete. However, it lacks details that would make it fully helpful, such as whether results include file paths, whether it searches all project items, or how it pairs with other tools like 'collect_files'. It does not explain return format since no output schema exists, which is a gap.
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 schema has zero parameters, so the description is the sole source of semantics. It clearly states the scope 'in the project', which is adequate for a parameterless tool but leaves some ambiguity about 'missing' definition. Since there are no params, the description fully covers what an agent needs to know operationally.
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 uses a specific verb 'find' and resource 'missing footage items in the project', clearly indicating the tool's purpose. It stands out among siblings like 'import_footage' and 'replace_footage' because it focuses on identifying gaps rather than manipulating assets, though it doesn't explicitly name 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?
No guidance is provided on when to use this tool versus others or what to do with the results. It implies usage for auditing missing items, but lacks explicit context on preconditions (e.g., project must be open) or how it relates to 'collect_files' and 'reduce_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?
No annotations are provided, so the description must disclose behavioral traits on its own. It does not explain how markers are returned, what happens when both composition and layer are specified, whether an empty result is returned, or whether any lookups can fail. This leaves significant behavioral ambiguity for a tool with four optional selector parameters.
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, front-loaded sentence with no wasted words. It conveys the action and scope efficiently, 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?
With no annotations, no output schema, and four optional parameters at 0% schema description coverage, the description is too sparse to fully support correct invocation. It does not explain selector behavior, precedence, return format, or error conditions, leaving important gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only loosely maps to parameters by mentioning 'composition or layer'. It does not clarify how compId/compName or layerName/layerIndex are resolved, whether they are alternatives or complementary, or what happens when none are provided. The parameter names are somewhat self-explanatory, but the description adds minimal value beyond them.
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 ('Get all markers') and the resource scope ('from a composition or layer'). It distinguishes this read-oriented tool from sibling marker tools like add_composition_marker, add_layer_marker, and delete_marker.
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 choose this tool over alternatives, no prerequisites, and no exclusions. It only restates the core function without explaining use cases or selection rules.
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 must convey behavioral traits, but it only states the high-level action. It does not disclose whether existing expressions are overwritten, if the link is reversible, or any side effects on keyframes or layer properties. This lack of detail for a write operation 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 with no redundancy. It is appropriately concise and front-loaded, effectively communicating the core action without unnecessary 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 the tool's complexity (9 parameters, no annotations, no output schema), a six-word description is insufficient. It does not explain return values, edge cases, or how it relates to expression-setting tools, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers only 11% of parameters (only offset has a description), and the description adds minimal semantic value. It implies sourceProperty and targetProperty but says nothing about compId, layer names, or indices. With 9 parameters, the description doesn't compensate for the low 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 'Link two properties with an expression' uses a specific verb (link), identifies the resource (two properties), and clarifies the mechanism (with an expression). This clearly distinguishes it from sibling tools like set_expression, which focuses on a single property.
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 such as set_expression or modifying expressions directly. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It does not disclose that precomposing typically replaces the selected layers with a new layer, nor does it clarify side effects like destruction of original layer stacking or the need for a target composition. The mutation behavior is implied but not detailed.
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, and front-loaded sentence with no redundant wording. It efficiently communicates the core 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 precomposing (side effects on original layers, creation of a new comp, optional parameters), the description is too minimal. No output schema or annotations help, so the description should explain more about what happens to the selected layers and what moveAttributes does, but it doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% with some parameters (compId, compName) lacking descriptions. The description does not add any parameter meaning beyond what the schema already provides, leaving gaps for optional parameters unclear.
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 (precompose), the target (selected layers), and the outcome (a new composition). It is specific and distinguishes itself from sibling tools like create_composition or delete_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, no prerequisites, and no mention of which composition the operation applies to (e.g., active comp vs. compId). It is entirely absent of 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?
With no annotations, the description must disclose behavioral traits. It states 'Delete' which implies a destructive action, but provides no detail on permanence, side effects on linked assets, or success/failure feedback. The description is minimal and fails to inform the agent about the irreversible nature or any additional consequences beyond the basic 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 concise sentence with no unnecessary words. It is front-loaded and to the point, perfectly sized for a simple 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 operation with 2 optional parameters and no output schema, the description is inadequate. It does not explain which parameter to supply, whether deletion is permanent, or what happens after success (e.g., returns a confirmation). The lack of annotations and minimal description leaves the agent without critical operational 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 coverage is 100% (both parameters have descriptions), so the baseline is 3. The tool description adds no extra meaning beyond the schema, leaving ambiguity about whether compId, compName, or both are required (both are optional in schema). The description does not clarify usage rules for the parameters, so it provides no added value over 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 'Delete a composition' uses a specific verb (delete) and resource (composition), clearly distinguishing it from siblings like create_composition or modify_composition. It is unambiguous and immediately conveys the tool's function.
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. There is no mention of when deletion is appropriate, prerequisites (e.g., composition must exist), or cases where another tool (like delete_layer) should be used instead. The description is purely declarative with no 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 must disclose behavior. 'Import' implies a mutation to the project, but the description does not explain what happens to existing items, whether files are moved or copied, how unsupported files are handled, or if the operation is reversible. This is a significant gap for a mutating 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, front-loaded sentence with no redundant words. It communicates the core purpose immediately and 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?
For an import operation with no annotations and no output schema, the description is under-specified. It does not mention return values, side effects, error behavior, or the type of files that can be imported. Even though the schema covers parameters, the overall behavior is not sufficiently explained.
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 already provides 100% coverage with descriptions for both parameters ('path' and 'recursive'), so the tool description adds nothing beyond the schema. Baseline of 3 is appropriate since schema does the work.
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 'Import all files from a folder' clearly states the action (import), the resource (files), and the scope (all files from a folder). It distinguishes itself from sibling tool 'import_footage' by implying bulk import of any files rather than a specific footage asset.
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 given on when to use this tool versus alternatives like import_footage. There is no mention of typical use cases, prerequisites, or situations where another tool would be more appropriate.
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?
With no annotations provided, the description carries full burden. It correctly implies an import operation (data intake, non-destructive to existing items) but does not disclose whether the file is copied versus linked, whether supported formats exist, or what happens on failure. No contradictions since annotations are absent.
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, focused sentence with no redundant text. It could benefit from a bit more context, but it remains appropriately concise for a tool with four well-documented parameters in the schema.
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 (4 parameters, no output schema, no annotations), the description is somewhat lacking. It does not clarify whether the import is blocking or async, how path resolution works (relative vs absolute), or what the tool returns upon success. The presence of sibling tools like 'collect_files' and 'reduce_project' suggests a larger workflow where this tool's role and limitations (e.g., single file only) should be clearer.
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 baseline clarity for all four parameters. The description adds no extra context beyond the schema, such as how 'sequence' interacts with 'forceAlphabetical' or what format 'path' must follow. With full schema coverage, a score of 3 is appropriate; the description does not degrade understanding but adds no unique 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 states the specific action 'Import footage file into the project'. It uses an appropriate verb-resource pair and distinguishes itself from related sibling tools like 'import_folder' and 'replace_footage', though it could more explicitly note what 'footage' means (e.g., video/audio files vs other assets).
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 such as 'import_folder' for importing multiple items or 'replace_footage' for swapping existing footage. The description does not specify prerequisites like file format support, project state requirements, or excluded 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, the description must convey behavior. It only says 'offset all keyframes in time' without detailing side effects (e.g., whether keyframes are shifted relative to a reference point), in-place modification, or error conditions. This leaves significant ambiguity about the operation's effects.
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 with no redundant words. It is appropriately concise for a simple operation, though it could include a bit more detail without becoming verbose.
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?
The description omits critical context: how to specify which keyframes to offset (via layer/property), whether the offset is added or subtracted, and what the tool returns (no output schema is present). The schema is sparse, so the description does not compensate, leaving the tool incompletely specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes only 'offset' with a unit (seconds). The tool description adds no further explanation for parameters like compId, property, layerName, or layerIndex. It does not clarify how these parameters identify the target layer/property, leaving the caller to infer from names alone.
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 'Offset all keyframes in time' clearly states the action (offset) and the object (keyframes), and specifies the dimension (time). This distinguishes it from sibling operations like scale_keyframe_timing (which scales times) or reverse_keyframes (which reverses order).
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 the use case (shifting keyframes by a fixed time offset) but does not explicitly state when to prefer this over alternatives. No mention of prerequisites (e.g., layer must have keyframes) or conditions that make this tool suitable.
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 must convey behavioral traits. It only states 'Add a shape layer to a composition' without mentioning side effects, required composition references, parameter interplay, or what happens with multiple unspecified valid combinations. The operation is clearly a mutation but lacks details about layer ordering, overwrite behavior, or error conditions.
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, front-loaded sentence with no redundant words. It is concise and immediately understandable, earning high marks for efficiency.
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 has 12 parameters, no output schema, and no annotations, the one-sentence description is inadequate. It fails to explain which parameters are shape-specific, how to identify the target composition (compId vs compName), or mention that all parameters are optional. Rich guidance is needed but entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 58%, and the description text adds no parameter meaning. It does not clarify how parameters like size, position, compId vs compName, or shape-specific options (innerRadius, points) are used together. The schema partially describes parameters, but the description fails to compensate for the gaps or add insights beyond the structured data.
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?
Description uses specific verb 'Add' and clear resource 'shape layer' with target 'composition', making it distinct from sibling add_*_layer tools like add_text_layer or add_solid_layer. It immediately communicates the core function without ambiguity.
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?
No explicit when-to-use or alternatives are mentioned. However, the tool name and description imply it is for adding shape layers, distinguishing from other layer types. Usage context is implied by the resource type, but no exclusions or comparisons to similar tools are provided.
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?
With no annotations, the description carries the full burden. It implies a read-only operation via 'get', but does not explicitly state that it is non-destructive or whether it requires an open project. The minimal disclosure is adequate but lacks details on errors or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, using only six words to convey the tool's purpose. Every word is necessary and there is no 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 absence of an output schema and the vague description, the tool lacks sufficient completeness. An agent would not know what 'information' means—e.g., project name, frame rate, duration. The many sibling tools increase the need for specificity.
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?
There are no parameters, so the description cannot add meaning beyond the schema. Per guidelines, 0 parameters yields a baseline of 4. However, the description fails to explain the return value content, which would have added 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 tool gets information about the current project, distinguishing it from siblings like get_composition_info or get_layer_info. However, it does not specify what specific information (e.g., project settings, metadata) is returned, 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?
There is no guidance on when to use this tool versus alternatives or any prerequisites. The description simply states what it does without context for when it is appropriate or when to avoid it.
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. 'List all effects on a layer' implies a non-destructive read operation, which is implied but not explicit. It conveys the basic behavior without detailing the return format, pagination, or effect ordering, but is adequate for a simple list 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, focused sentence of nine words that uses the verb 'List' and the target 'effects on a layer'. It conveys the most important purpose immediately with no wasted words. 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?
For the complexity level, this is a list operation with four optional parameters but no required ones. The description is potentially complete for a straightforward listing scenario, though it doesn't address how effects are identified when multiple layers or compositions share names. Minimal viable for the documented scope.
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?
No parameters are required, but there are four optional filters (compId, compName, layerName, layerIndex). With 0% schema description coverage and no parameter documentation in the description, the agent cannot know how to select between compId vs compName or layerName vs layerIndex. Baseline 3 applies despite the schema providing type/name hints.
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 'List all effects on a layer' clearly uses the specific verb 'List' with the resource 'effects on a layer'. It has high purpose clarity as a read-only listing operation. It distinguishes from siblings like list_layers and list_compositions, though it does not name alternatives explicitly.
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 the tool is used for reading effects but provides no explicit when-to-use guidance or exclusions versus sibling tools like get_layer_info or apply_effect, which may also relate to effects. Usage must be inferred from typical MCP tool naming conventions.
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 clearly indicates the create/mutation behavior and the entity type, but it does not disclose how composition selection works when compId/compName are omitted, nor does it mention defaults like duration/startTime 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 front-loaded sentence with no filler or redundant wording. It communicates the core purpose immediately and 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?
With 8 parameters, nested color input, and the broader add-layer sibling family, the description is minimally viable but leaves some context unexplained, such as target composition selection and default layer timeline behavior. It is not seriously deficient because the schema covers all parameters, but it is not rich enough for complex selection 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?
The input schema already has 100% parameter description coverage, so the description does not need to add parameter details. The description adds no parameter semantics beyond what the schema already provides.
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 uses a specific verb ('Add') and specific resource ('solid color layer') with a clear target ('to a composition'). This clearly distinguishes it from sibling tools like add_text_layer or add_shape_layer.
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 usage context is implied by describing the layer type, but the description does not explicitly say when to choose this over other layer-add tools or mention any preconditions such as needing an open composition. No exclusions or alternatives are given.
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 bears full burden for behavioral disclosure. It tells the agent this tool opens a file (a read operation), but it doesn't specify if it loads the project into memory, replaces the current project, or requires that no project is already open. It doesn't mention error behavior for missing files or unsupported formats.
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, concise sentence with no wasted words. It is front-loaded with the core action and resource. Every word serves a purpose.
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 simplicity (one required parameter, no output schema), the description is largely complete for basic use. However, it could benefit from noting whether the tool interacts with the current project state or if it has side effects like closing other projects. The lack of annotations means slightly more descriptive burden, but the tool is straightforward.
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 baseline is 3. The description does not add any additional meaning beyond what the schema provides for the 'path' parameter. It doesn't explain format expectations (e.g., absolute vs relative paths) or whether wildcards are allowed.
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 verb 'Open' and the resource 'existing After Effects project'. It distinguishes this from sibling tools like 'create_project' (which creates new projects) and 'close_project' (which closes projects). The scope is precise and unambiguous.
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 this should be used to open an existing project (as opposed to creating a new one with create_project), but it provides no explicit guidance on when to use it, prerequisites (e.g., whether the file must exist, permissions), or when not to use it. No alternatives or context are mentioned.
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. It discloses the recursive behavior and the specific data included (names, match names, expressions, keyframe counts), which gives useful insight into what to expect. It does not explicitly state it is read-only, but 'dump' and 'diagnostics' imply a non-destructive inspection.
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, front-loaded sentence that efficiently conveys the core action and content without any wasted words. It is concise and to the point.
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?
The description adequately covers what the tool does and its diagnostic purpose, but with five parameters and no output schema, it leaves gaps: layer selection is ambiguous (multiple identifiers), and there is no mention of potential large output or performance implications. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (maxDepth has a description), and the description does not compensate for the other parameters. It does not explain how compId, compName, layerName, or layerIndex are used for layer selection, their precedence, or why none are required. This leaves significant ambiguity in invoking the tool.
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 function: 'Recursively dump a layer's property tree' with specific contents (names, match names, expressions, keyframe counts) and purpose (diagnostics). It distinguishes itself from siblings like get_layer_info or get_expression by focusing on a comprehensive recursive dump.
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 phrase 'for diagnostics' provides clear context for when to use this tool, implying it is for debugging or inspection rather than normal querying. However, it does not explicitly name alternative tools or state when not to use it, leaving some ambiguity.
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, the description does the work: it lists the report contents, notes that animated values are sampled over time with a marker-based default, and implies a read-only verification role, though it doesn't warn about potentially large outputs or performance costs.
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?
Two sentences, first delivers the core scope, second states the intended use. No filler words, all information relevant.
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?
The description enumerates report contents and sampling behavior, which is substantial given no output schema, but it doesn't clarify how compId vs compName resolution works when both are optional, and it doesn't discuss the return format or size, leaving some ambiguity for a complex report tool.
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?
All 4 parameters have schema descriptions covering 100%, so the baseline applies. The description mentions sampling 'at markers by default', which mirrors the schema's sampleTimes description without adding new parameter-level semantics.
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 this tool produces a full composition report including layers, geometry, text, fonts, expressions, keyframes, and animated values, distinguishing it from sibling tools like get_composition_info or get_layer_info which likely return narrower data.
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?
It explicitly says 'Use it to verify the real state of a comp', providing a clear use case, but it does not name alternative tools or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. 'List all compositions' clearly indicates a non-mutating read operation, and 'in the project' scopes the action. It does not explicitly confirm absence of side effects or describe return details, but the wording is sufficiently transparent for a zero-parameter list 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 one short, front-loaded sentence with no filler, repetition, or unnecessary detail. Every word carries meaning, and it is minimally sufficient for the tool's zero-parameter nature.
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 zero-parameter list tool, the description is quite complete, but it could be more explicit about returning an array or which project is considered 'the project' (e.g., the currently open project). Without an output schema, a slight clarification about the return value would close the remaining gap.
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, so there is no parameter semantics to document. The schema description coverage is trivially 100%, and the description adds enough context with 'all compositions in the project' even though it cannot elaborate on nonexistent parameters.
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 uses a specific verb ('List'), identifies the resource ('compositions'), and states the scope ('in the project'). It clearly differentiates from sibling tools like get_composition_info, create_composition, and delete_composition, which are for individual or state-changing operations.
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 the tool is for retrieving an overview of all compositions in the project, but it does not state explicit when-to-use or compare with alternatives. Sibling tools like get_composition_info provide contrast, but no direct guidance or exclusion is given.
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, the description carries the full burden. It discloses that a file is written to disk and that a file path is returned, which are key behavioral traits. It does not cover edge cases like overwriting or missing compositions, but covers the core side effect adequately.
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?
Two sentences, front-loaded with the verb and resource. Every word earns its place, and there is no wasted content.
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 simple render tool, the description covers the main purpose and return value. The only gap is that compId/compName are optional but the description does not clarify how the target composition is selected (e.g., current active comp). Given the schema already documents parameters, this is a minor omission.
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 baseline is 3. The description adds context about the output format (PNG) and return value, but does not enrich parameter meaning beyond the schema. It hints at fileName/outputDir defaults indirectly via the default behavior stated in 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 states a specific verb+resource+output: 'Render a single frame of a composition to a PNG file on disk.' It clearly distinguishes from sibling tools by focusing on visual rendering and returning a file path, unlike tools that manipulate project structure.
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 phrase 'so the AI can inspect what the comp actually looks like' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, leaving the guidance slightly implicit.
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:

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

Score Badge

Copy to your README.md:

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

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/davidcasan/MCP-AE'

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