After Effects MCP
Server Quality Checklist
Latest release: v1.10.0
- Disambiguation2/5
Several tools have overlapping or unclear boundaries, such as run-script vs execute-script, apply-effect vs add-any-effect, and check-bridge vs run-bridge-test. Multiple help tools (get-help, mcp_aftereffects_get_effects_help) and rendering tools (start-render, render-aerender) could confuse an agent. The descriptions help but the overlaps are significant enough to cause misselection.
Naming Consistency3/5Most tool names follow a kebab-case verb-noun pattern (e.g., create-composition, list-layer-effects), but there are notable inconsistencies: setLayerKeyframe and setLayerExpression use camelCase, and mcp_aftereffects_get_effects_help uses snake_case with a prefix. While still readable, the mixed conventions are more than minor deviations.
Tool Count2/5With 50 tools, the set is very large and exceeds the 25+ threshold for 'too many'. While After Effects is complex, many tools overlap (e.g., three ways to apply effects, two script runners, two render methods), inflating the count. A more focused set of ~20-30 tools would likely cover the same functionality with less redundancy.
Completeness4/5The tool set covers a broad range of After Effects operations: compositions, layers, effects, presets, text, audio, animation, inspection, and rendering. Minor gaps exist, such as no direct tool for listing all compositions or deleting a composition, but these can be worked around via execute-script, and the overall lifecycle is well covered.
Average 3.7/5 across 50 of 50 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 38 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'test', which hints at a non-destructive action but does not explain side effects, return values, or whether it actually modifies the composition. This is insufficient for an agent to reason about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It lacks essential details, making it more of a placeholder than a helpful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should compensate with behavioral and return-value context. It does not explain what 'testing' entails, what the operation parameter does, or what the agent should expect after calling it, leaving a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all three parameters (compIndex, layerIndex, operation) documented, including an enum for operation. The description adds no additional meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb ('test') and a resource area ('animation functionality in After Effects'), but it is vague about what exactly is being tested. It does not distinguish this tool from siblings like setLayerKeyframe or setLayerExpression, which are also related to animation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites, typical scenarios, or comparison with sibling tools, leaving the agent to guess.
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 restates the basic operation. It does not mention whether applying an effect replaces existing effects, how failures are handled, what side effects occur, or whether it requires specific permissions. This is minimal beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and easy to parse, though it is too brief for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, a nested object, no annotations, no output schema, and many closely related sibling tools, a one-sentence description is completely inadequate. It lacks guidance on how to identify effects, how to handle settings, differences from similar tools, and expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no information about parameters, and the schema itself contains redundant aliases (effect, effectName, effectMatchName, effectIdentifier) without clear priority. Still, because the schema documents all parameters, a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply an effect') and target ('a layer in After Effects'), making the core purpose understandable. However, it does not distinguish this tool from close siblings like 'add-any-effect' or 'apply-effect-template', which also apply effects 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/5Does 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-any-effect' or 'apply-preset', nor any indication of how to choose among the overlapping effect parameters (effect, effectName, effectMatchName). The description provides no context for selection 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 present, so the description must carry the full burden of behavioral disclosure. It only states the action and identification method, but does not mention side effects (e.g., replacing existing effects), permissions, error behavior, or what happens after addition. 'Add' implies mutation, but other behavioral traits remain 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of fluff. It efficiently conveys the core purpose and method without unnecessary words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema, the tool lacks an output schema and annotations. The description does not clarify return values, prerequisites (e.g., valid comp/layer indices), or behavior in error cases. For a mutation tool in a complex environment, this minimal description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a detailed description (e.g., effect, compIndex, layerIndex, effectSettings). The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Add any After Effects effect to a layer' with a specific method ('by matchName or display name'). It distinguishes from template/preset-adders by emphasizing 'any' effect, but does not differentiate from the sibling 'apply-effect' tool, making the purpose clear but not fully sibling-distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'apply-effect', 'apply-effect-template', or 'apply-preset'. The description gives no context or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions marker features (comment, label color, etc.) but does not disclose side effects, defaults (e.g., markerType defaults to 'layer'), or potential failure modes. The mutation aspect is implied but not elaborated, which is insufficient for a tool with this complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the primary action. The second sentence adds relevant detail about marker capabilities without unnecessary elaboration. Every word contributes value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no annotations, and no output schema, the description is too thin. It does not explain how to target a layer (layerName vs layerIndex), the need for compIndex, or the distinction between layer and comp markers. The schema covers parameter syntax, but the description fails to provide the higher-level context needed for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description lists some parameters (comment, label, chapter, URL, duration) but does not add meaning beyond the schema's own parameter descriptions. It provides a high-level summary without extra detail, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add a marker to a layer or composition at a specified time.' It identifies the verb (add), resource (marker), and scope (layer/composition). It does not explicitly distinguish from the sibling 'add-markers-bulk', but the singular wording implies single-marker use, so it is mostly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'add-markers-bulk', or when to choose layer markers vs composition markers. The description implies usage but offers no explicit context or exclusions, leaving the agent to infer 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a template is applied, without indicating whether existing effects are replaced, whether the operation is reversible, whether any selection is required, or what happens with customSettings. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It directly states the action, resource, and target, and every word earns its place. No unnecessary details or repetitive phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with four parameters, a nested object, and no output schema or annotations. The description is too sparse to fully support an agent's decision-making: it lacks behavioral details, usage context, and any mention of what happens during/after application. The schema explains parameters but not the operation's side effects or success criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all parameters, including enums and the nested customSettings object. The description itself adds little beyond the schema, but the schema already conveys the meaning adequately. There is no contradiction or missing parameter context that the description must compensate for, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply'), resource ('effect template'), and target ('layer in After Effects'), making the core action clear. However, it does not explicitly distinguish itself from sibling tools like 'apply-effect' or 'apply-preset', leaving potential ambiguity about whether 'template' differs from a general effect or preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention exclusions, prerequisites, or scenarios where a different tool would be more appropriate, despite the presence of closely related sibling tools such as 'apply-effect' and 'apply-preset'.
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 'apply' without explaining whether it overwrites existing properties, requires a valid preset path, or has any side effects. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and contains no fluff. It is appropriately concise for the tool's simplicity, earning a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the one-sentence description is insufficient. It omits what the agent should expect after applying (e.g., return value, error conditions, effect on layer). While parameters are well-documented, the tool's behavior is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters (compIndex, layerIndex, presetPath) with clear context (1-based indices, absolute path). With 100% schema coverage, the baseline is 3, and the description adds no extra parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 (.ffx preset file) to a target (layer). It is specific enough to differentiate from general effect tools, though it does not explicitly name sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like apply-effect or list-presets. There are no stated prerequisites, exclusions, or alternative tools, leaving the agent without context for proper 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely restates the action ('Create a new composition') without revealing any side effects, required context, default behaviors, or return values. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, boilerplate sentence that is front-loaded and has no waste. While it is brief, it is not overly verbose, and the schema covers parameter details. It could be slightly more informative, but it remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters including a nested object, no output schema, and no annotations. The description is far too minimal to be complete; it fails to mention what happens to the existing project, whether an open project is required, what the return/information out is, or any limitations. A richer description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 7 parameters, so the schema already provides detailed meanings. The description's phrase 'with specified parameters' adds no extra semantic value, but the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new composition in After Effects, with a specific verb ('Create') and resource ('composition'). It distinguishes itself from sibling tools like set-composition-properties (which modifies existing comps) and create-text-layer (which creates 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/5Does 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. It does not mention prerequisites (e.g., an open project), when not to use it, or how it relates to sibling tools like set-composition-properties. The context is implied but not explicit.
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 of disclosing behavior. It only mentions searching by name/path and does not describe return format, matching semantics, read-only nature, or error behavior, which is a significant gap for a search 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is appropriately sized for a simple search tool and front-loads the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the search returns (e.g., list of file paths). It also fails to clarify matching rules (substring vs exact) or default search roots, leaving important usage context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptive parameter details, so the baseline is 3. The description's 'by name or path' aligns with the query parameter and adds minimal meaning beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Search') and resource ('After Effects .ffx presets') with a specific scope ('by name or path'). It is distinct from sibling tools like apply-preset and list-presets, but does not explicitly differentiate from list-presets, which could overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use search-presets versus list-presets or other alternatives. The description only states what the tool does, leaving the selection decision to the agent without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects and behavior. It only says 'set an effect property keyframe' and mentions optional easing controls, but does not disclose whether it creates a new keyframe or modifies an existing one, how it resolves target properties, what errors may occur, or any side effects such as altering existing keyframes. The lack of behavioral detail is a significant gap for a tool with this complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the core action and a high-level feature (graph interpolation/easy-ease) compactly. However, it is so brief that it sacrifices useful context, but for conciseness and structure it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, nested objects, multiple targeting strategies, no output schema), the description is far too thin. It does not explain how the tool handles keyframe placement (by time vs. index), how property path resolution works, or what happens when multiple fallback parameters are provided. The schema is rich, but the description adds almost no contextual completeness, leaving the agent with many unanswered operational questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all 12 parameters have individual descriptions in the schema. The tool description itself adds no additional meaning to the parameters; it merely mentions 'graph interpolation and easy-ease controls,' which are already detailed in the keyframeOptions schema. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Set') and the target resource ('an effect property keyframe'), and mentions optional graph interpolation and easy-ease controls, distinguishing it from sibling tools like set-effect-property (which sets a static property value) or setLayerKeyframe (which targets layer-level keyframes). The purpose is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites (e.g., the effect must already exist) or conditions (e.g., the property must be keyframable). It only states what it does, leaving the agent to infer usage context. There is no mention of exclusions or alternative tool recommendations.
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 only states 'Get help' without conveying what output to expect, whether it returns a list of commands, or if it has any side effects. The read-only nature is implied but not stated, and no additional behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple help tool with no parameters and no output schema, the description provides the essential purpose but lacks details about what kind of help is returned (e.g., command list, usage examples, or links). Since there is no output schema, the description should explain the return value, but it does not, leaving a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so the baseline score is 4. The description does not need to add parameter information because there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get help on using the After Effects MCP integration'. It is more specific than a tautology and identifies the tool as general help, but it does not explicitly distinguish itself from the sibling tool 'mcp_aftereffects_get_effects_help', which appears to be a more specialized help option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention situations where users should prefer the dedicated effects help tool or any other tool, and it offers no exclusions or contextual examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states it lists presets from folders, but does not disclose whether After Effects needs to be running, whether it is a purely filesystem read, what format results take, or potential performance impacts of recursive search. The verb 'list' implies a read operation, but key behavioral details 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, and contains no extraneous information. It is appropriately concise for the tool it describes, earning its place with every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain what the tool returns (e.g., an array of file paths). It also does not mention any prerequisites, such as whether After Effects must be running, or how it compares to sibling tools. The schema covers parameters, but the overall context for using the tool is incomplete, especially given the presence of similarly named tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already provides detailed parameter semantics, including defaults and constraints. The description adds no additional meaning beyond mentioning 'common or provided folders,' which loosely maps to 'presetRoots' but adds no new information 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List available After Effects .ffx presets from common or provided folders,' which uses a specific verb ('List'), a clear resource ('.ffx presets'), and scope (folders). It distinguishes from sibling tools like 'search-presets' (search vs. list) and 'apply-preset' (apply vs. list), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tool 'search-presets' suggests a possible distinction, but the description does not explain when to choose 'list-presets' over 'search-presets' or other tools. The usage context is entirely implied by the tool's 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 carries the full burden of disclosing behavior. It merely states the purpose without mentioning that the operation is read-only, what output to expect, or any other behavioral traits. The implication of 'help' being non-destructive is weak.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly stated sentence with no filler words. It conveys the core purpose efficiently and is appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple help tool, but it lacks details about the output format or what kind of help is returned. Since there is no output schema and no annotations, the description should explain what the agent will receive, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the baseline for parameter semantics is 4. The description adds no parameter information, but none is needed since there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing help on using After Effects effects. The verb 'Get help' and the resource 'After Effects effects' distinguish it from general help tools like 'get-help' and effect listing tools like 'list-available-effects', though it doesn't elaborate on what the help includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus similar siblings such as 'get-help' or 'list-available-effects'. It does not mention any alternatives, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 discloses that the script is 'read-only', which is a meaningful safety trait, but it does not explain return values, error handling, or how parameters are passed, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and a key safety trait without any redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too sparse. It omits return value information, usage guidance, and the distinction from 'execute-script'. Given the presence of a nested parameters object, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the schema already documents their meaning. The description adds no extra parameter-level context, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a read-only script in After Effects, using a specific verb and resource. However, it does not explicitly distinguish itself from sibling 'execute-script', which likely also runs scripts, so it lacks full 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The existence of 'execute-script' implies a distinction, but the description does not clarify the intended use case.
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 states the action without explaining consequences like overwriting existing keyframes, prerequisites (comp/layer must exist), or error 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It clearly states the core function in a front-loaded manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with five parameters and no output schema or annotations, this description is minimal. It lacks context about when to use, what happens on keyframe conflicts, and any return values, making it incomplete for an AI agent to safely invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are described in the schema, so schema_description_coverage is 100%. The description does not add any parameter-specific meaning beyond what the schema already provides, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Set' as a specific verb and identifies the resource as 'a keyframe for a specific layer property,' which distinguishes it from sibling tools like set-effect-keyframe. The phrase 'at a given time' adds temporal 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/5Does 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-effect-keyframe or batch-set-layer-properties. There are no exclusions or suggested scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic mutating action ('set or remove') but does not mention side effects, permissions required, behavior on invalid inputs, or whether the expression replaces existing ones. The schema's note about empty string removing an expression is the only behavioral detail, but that is already in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core action without extraneous words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and the input schema is fully descriptive, but the description lacks usage context, behavior expectations, and guidance on error cases or side effects. Given no annotations and no output schema, a bit more context would be helpful, but the schema mitigates some of this. Overall, it is minimally complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 minimal semantic value beyond schema, merely saying 'specific layer property' while the schema already details each parameter (compIndex, layerIndex, propertyName, expressionString) with clear explanations. No additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs two related actions: setting or removing an expression on a layer property. It uses a specific verb (set/remove) and resource (expression for a layer property), which distinguishes it from siblings like setLayerKeyframe that handle keyframes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 setLayerKeyframe or apply-effect. There is no mention of prerequisites, limitations, or scenarios that favor this tool over others.
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 states the action ('Center') without revealing that this modifies layer positions, how centering is calculated (e.g., to composition center), or what happens when conflicting parameters (allLayers, selectedOnly, layerName) are combined. This lack of safety/edge-case context is a notable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the three target scopes in a compact list. It contains no filler, wasted words, or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with five parameters, no output schema, and no annotations. The description is too terse to be complete: it does not specify how centering is applied, what happens with conflicting options, or what the result/return value is. For an agent to invoke this correctly, additional behavioral details are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter individually described, so the schema does the heavy lifting. The description adds minimal semantic value beyond mapping the scopes ('one layer' to layerName/layerIndex, 'selected layers' to selectedOnly, 'all layers' to allLayers), but it does not explain parameter combinations or precedence rules, which would be useful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Center') and clearly specifies the resource and scope: 'one layer, selected layers, or all layers in a composition.' It distinguishes the tool's function from sibling tools, none of which mention centering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when centering layers is needed) but provides no explicit guidance on when not to use it or alternatives. It also does not clarify the precedence of parameters like allLayers vs selectedOnly, or layerName vs layerIndex, leaving potential ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This is a destructive operation with no annotations to signal the risk. The description merely says 'Delete' and mentions targeting, but it does not disclose that deletion is irreversible, what happens if both layerName and layerIndex are provided, or what errors occur if no target is specified. The description carries the full burden of behavioral disclosure and fails to address these important safety and edge-case behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action ('Delete a layer from a composition'), followed by the key targeting detail. No filler or redundant content; every word serves the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description does not explain essential operational details. It fails to specify that exactly one of layerIndex or layerName is required (since the schema marks all parameters as optional), or what happens if both or neither are provided. It also does not describe error behavior for missing compositions or layers. Given the simplicity of the tool, these gaps make the description incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described in the input schema. The description adds 'Target the layer by layerIndex or layerName,' which reiterates the schema's own parameter descriptions but does not add deeper meaning such as mutual exclusivity, precedence, or required-target logic. It provides marginal value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete a layer from a composition') with a clear resource (a layer) and context (composition). It distinguishes from sibling tools like duplicate-layer and inspect-layer by naming a unique operation. It also specifies targeting via layerIndex or layerName, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'Delete' and the resource type. However, there is no explicit guidance on when to use this tool vs alternatives, no mention of exclusions (e.g., cannot delete locked layers), and no note about requiring a composition to be active. The description provides clear context but no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions per-channel control and optional keyframing but does not disclose what happens if no level is provided, whether existing levels/keyframes are overwritten, or any side effects. The behavior is only superficially summarized, adding little beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that starts with the action and resource, then adds key features. No wasted words, and it conveys the essential purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema documenting parameters, the overall tool behavior is under-specified. It does not clarify required parameters' roles, the effect of omitting optional level fields, or how keyframing behaves (e.g., whether it replaces existing keyframes). With no annotations and no output schema, more context is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 only paraphrases what the schema already states (per-channel via leftLevel/rightLevel, keyframing via timeInSeconds) without adding new contextual meaning or usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the resource ('audio levels'), and the unit ('dB'), and specifies the target ('audio or AV layer'). It also mentions per-channel control and keyframing, which distinguishes it from sibling tools like setLayerKeyframe that handle generic layer properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to adjust audio levels on a layer. However, it does not explicitly suggest when to prefer this over alternatives like setLayerKeyframe or animate-to-audio, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 for behavioral disclosure. It only states the action ('set or keyframe') without mentioning overwriting behavior, effect existence requirements beyond 'existing', error handling, or the irreversible nature of modifying property values. For a mutation tool, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with a clear verb and resource. It contains no filler words and is appropriately front-loaded, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complex schema coverage (13 parameters, nested objects), the description is only one sentence and does not explain return values, behavior when timeInSeconds is absent/present, precedence rules between the multiple targeting parameters, or interaction between value, expressionString, and keyframing. Output schema is absent, so no return information is provided elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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's 'using name/index/path' usefully groups the targeting mechanisms, but adds no new semantic detail beyond what each parameter description already covers. It does not clarify precedence or interactions among targeting parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('set or keyframe') and resource ('any property on an existing layer effect') with targeting method ('using name/index/path'). It clearly distinguishes from siblings like apply-effect (adds effects) and set-effect-keyframe (focuses on keyframing) by covering both setting and keyframing on existing effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing layer effect' implies a prerequisite: the effect must already be applied, suggesting not to use this for adding effects (use apply-effect instead). However, it does not explicitly differentiate from the closely related sibling set-effect-keyframe or state when to prefer one over the other.
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, but it only states the core action without detailing side effects like adding a layer to the composition's stack or the layer's effect on underlying layers. It also omits prerequisites, reversibility, or any impact on 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the essential information without any filler. It is appropriately sized for the tool's simplicity and immediately conveys the action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema richly documents all parameters, making invocation possible, but the description lacks broader context such as what an adjustment layer does in a composition or how this fits into a workflow. With no output schema and no annotations, the description alone provides minimal contextual guidance beyond the core action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters (6) have schema descriptions with defaults and units (e.g., name default, size defaults to comp dimensions, duration in seconds), resulting in 100% schema coverage. The description adds no additional parameter meaning, aligning with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an adjustment layer in a specified composition or the active comp, using a specific verb and resource. It distinguishes this from sibling tools like create-text-layer or create-composition, which create different entities or layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when an adjustment layer is needed) and mentions the target composition, but it does not explicitly contrast with alternatives or state exclusions. There's no mention of other layer creation tools, so the guidance is clear only through the tool's name and primary action.
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 must carry the behavioral burden. 'List' implies a read-only operation, which is accurate, but the description does not disclose potential performance implications of listing all effects, the default maxResults, or the return format. It adds the optional text filter behavior, but overall transparency is minimal yet not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource. It is concise, contains no fluff, and effectively communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description provides the basic operation but lacks details about the return value structure (e.g., whether it returns names, objects with matchName and category). Since there is no output schema, the description should clarify what is returned, making this a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description's mention of 'optional text filter' aligns with the query parameter but adds no additional semantics beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all effects available in the After Effects installation, using the specific verb 'List' and identifying the resource with scope. It also distinguishes itself from sibling tools like list-layer-effects (which lists effects on a layer) and list-presets (which lists presets) by specifying 'available in this After Effects installation.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 list-layer-effects or search-presets. There is no explicit 'when to use' or 'when not to use' context, so the agent is left to infer usage solely from the name and purpose.
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 indicates a destructive action ('remove') but does not clarify edge cases such as what happens if the effect is not found, or how removeAll interacts with other parameters. The permanence of the removal and any side effects are unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It front-loads the action and resource, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a basic understanding of the tool's purpose but lacks details about parameter interactions and edge-case usage. For a 6-parameter tool, this is minimal but not seriously deficient given the complete schema descriptions. The absence of an output schema and the tool's straightforward nature keep the description acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the baseline is 3. The description adds minimal semantic value by distinguishing 'one specific effect' from 'all effects', but the schema already documents each parameter's meaning. The description does not go beyond the schema in explaining parameter choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: removing one or all effects from a layer. The verb 'remove' and the resource 'effect' are specific and accurately reflect the tool's name, distinguishing it from sibling tools that add, apply, or list effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. However, the action is straightforward and implied: if you need to remove effects, use this tool. Additional guidance on when to use removeAll versus specifying an effect would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for transparency. It does disclose that the tool 'applies test effects', indicating side effects, but it does not explain what those effects are, whether they are destructive, reversible, or impact the current project. The behavior beyond 'verify communication' is vague, leaving the agent uncertain about possible outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that directly conveys the tool's function without any filler or redundancy. It is front-loaded with the action ('Run') and the resource ('bridge test effects script'), earning high marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is the sole context. It provides the basic purpose but leaves gaps about the nature of 'test effects' and the expected outcome. While it is minimally viable, an agent might struggle to predict the tool's impact on the environment, so the description could be more detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, meaning there are no parameters. The description correctly makes no mention of parameters, and because there are none, there is no semantic gap. Baseline 4 is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Run the bridge test effects script') and its dual purpose ('verify communication and apply test effects'). This distinguishes it from siblings like 'run-script' (generic script runner) and 'check-bridge' (only checks communication), making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or that it should be used before/after other operations. The purpose implies a testing scenario, but the description fails to explicitly state this context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 states the data returned but does not mention that it is a read-only operation, error behavior, or how it handles missing layers or ambiguous layer selection between layerName and layerIndex.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's function without extraneous words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple getter with no output schema, the description names the key returned values (clip frames, source frame range, duration in frames), which gives the agent a solid understanding of output. However, it omits any detail about return format or edge-case behavior, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameters are well-documented in the schema. The description adds no additional semantic detail about parameters beyond mentioning 'layer,' so it does not exceed the baseline for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get') and identifies the exact resource and outputs: a layer's clip start/end frames, source frame range, and duration in frames. This clearly distinguishes it from sibling tools like inspect-layer, which are more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use it—when you need frame-range information for a layer—but it does not explicitly state alternatives or exclusions. There is no guidance on choosing this over inspect-layer or other layer inspection tools, though the scope is inferable.
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 must disclose behavioral traits on its own. It mentions 'optional recursive property details,' hinting at nested property inclusion, but does not explicitly state that the operation is read-only, nor does it disclose performance implications of deep recursion, output format, or error handling. The verb 'List' suggests a safe read operation, but the description lacks explicit reassurance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and resource, with no wasted words. It is concise and structurally effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is fairly minimal. It clearly communicates the tool's purpose but does not elaborate on return values, edge cases, or practical examples. For a list operation, it is adequate but leaves room for more instructional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for all 5 parameters, so the baseline is 3. The description adds only that 'optional recursive property details' are available, which loosely maps to includeProperties and maxDepth, but does not enhance understanding beyond the schema's explicit parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists effects on a specific layer, using a specific verb ('List') and resource ('effects on a layer'). This distinguishes it from sibling tools like list-available-effects, which lists all effects in the application, by scoping to a layer within a composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting a layer's effects but does not explicitly state when to use this tool versus alternatives, such as when to use list-available-effects or inspect-layer. No when-not-to-use or alternative guidance is provided, so it relies on the user to infer context.
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 bears the full burden. It discloses the comp selection behavior (compName/compIndex or active comp) but omits details about side effects, failure modes, or creation defaults such as default position. The mutation nature is implied by 'create' but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose, the second explains comp selection. Every sentence earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema richly describes all 7 parameters, and the description adds comp selection logic. However, there is no output schema and no mention of return values or failure behavior, leaving some context incomplete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 a note about comp selection, overlapping with the schema's own descriptions, but does not add new semantics for parameters like position, zoom, or oneNode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a camera layer in a composition' with a specific verb and resource, and adds comp selection details that distinguish it from sibling create tools like create-composition or create-adjustment-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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating camera layers and explains how to target a comp (by name, index, or active), but it does not explicitly discuss when to use this tool versus alternatives or provide exclusions. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Change' which implies mutation but does not disclose side effects such as whether unspecified properties are preserved, how duration changes affect existing keyframes, or whether changes are reversible. This lack of detail for a mutation tool 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that get straight to the point: what changes and how to select the comp. Every phrase earns its place, and there is no fluff or repetition of obvious details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has six optional parameters and no output schema, the description adequately covers the core purpose and selection mechanism. It does not mention the width+height pairing constraint, but the schema covers this. While it lacks explicit side-effect warnings, the basic usage for an agent is sufficiently clear, though it could be more complete with behavioral notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all six parameters, including the constraint that width and height must be set together and that compName/compIndex are alternative selectors. The description repeats these settings and adds the 'or active comp' selection context, which slightly reinforces the schema but adds no new syntax or behavioral details. With 100% schema coverage, the description's redundancy is acceptable but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Change a composition's settings' which clearly identifies the action (change) and resource (composition). It enumerates the editable settings (duration, frameRate, width+height) and specifies comp selection via compName/compIndex or active comp, distinguishing it from create-composition and layer-focused tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, indicating what can be changed and how to select the target composition. It implies this is for modifying existing compositions rather than creating them, but it does not explicitly exclude alternatives or state when to prefer other tools. Sibling tools like create-composition suggest the distinction, but the description itself lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the transparency burden. It states the core operation and optional rename, which implies the original is preserved, but it does not disclose details such as the insertion position of the duplicate, the active comp fallback, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the primary action first and includes only necessary qualifiers. Every word contributes meaning; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no annotations, and no output schema, the description covers the core purpose and targeting but omits cross-parameter constraints and return/error behavior. The schema fills many gaps, but the description could be more complete regarding parameter relationships.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all five parameters, earning the baseline of 3. The description adds marginal value by restating layerIndex/layerName targeting and optional renaming, but it does not introduce constraints like exclusivity between layerName and layerIndex.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Duplicate' and defines the resource 'layer in a composition', then adds optional renaming and target selection via layerIndex or layerName. This clearly distinguishes it from sibling tools like delete-layer, inspect-layer, or setLayerKeyframe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool is for creating a copy of a layer and states how to target it. While it does not explicitly name alternatives or exclusions, the purpose is self-evident and no conflicting sibling tool exists, so the implied usage is clear.
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 and clearly signals a read-only retrieval ('Get results'), but it does not disclose what the result payload looks like, whether it can fail, or whether it has side effects. The behavioral description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and low complexity, the description is mostly adequate, but the absence of an output schema leaves 'results' undefined. The agent must guess whether it returns a string, object, or status, which is a notable gap for a tool with no other documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is 100% covered (empty properties), so the baseline for no parameters applies. The description does not need to explain parameters since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Get results') and scopes it to the last script executed in After Effects, clearly distinguishing it from sibling execution tools like run-script and execute-script. The subject and scope are immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'last script executed' implies the tool should be used after running a script, providing clear context, but it does not explicitly state when to use it versus alternatives or what happens if no script has been executed. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 discloses that the tool adds multiple markers and supports both layer and composition types, which is useful. However, it does not clarify whether markers are appended or replace existing ones, how errors are handled, or any side effects. With no annotation support, this is adequate but has clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and enriched with a concrete use case. Every sentence earns its place and there is no redundancy or filler. It is concise while still providing purpose and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, nested markers array) and rich schema, the description provides sufficient context for typical use. It covers what the tool does and when to use it. There is no output schema, but the description does not need to cover return values unless required. It lacks details on edge cases like partial failures or atomicity, but overall it is complete enough 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema, except for the contextual reference to analyze-audio-waveform, which implies the markers array likely comes from detected peaks. This is minimal extra value; the schema already describes all parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: "Add multiple layer or composition markers at once." It explicitly differentiates from the sibling tool add-marker by emphasizing the 'multiple' and 'at once' aspect, making it unambiguous which tool to use for bulk operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: "Use this after analyze-audio-waveform to place markers at detected peaks, or to add any set of markers in a single call." This clearly indicates when to use the tool versus alternatives, though it does not explicitly name the single-marker sibling or state 'do not use for single markers.' The guidance is strong but slightly implicit regarding exclusions.
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?
The description clearly indicates a read-only operation ('Get') and lists the specific data types returned, which helps set expectations. However, it does not disclose potential edge cases like layers without audio or error conditions, so it carries most but not all transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It lists exactly what the tool returns without extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the return contents (metadata, path, markers, keyframes) which is sufficient given the simple getter nature. It does not need an output schema because the description enumerates the returned data. However, it does not mention any prerequisites about the layer having audio.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for all three parameters with descriptions. The tool description adds no additional parameter-specific semantics beyond what the schema states, so baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource: audio metadata, source file path, existing markers, and audio level keyframes. This clearly distinguishes it from mutation tools like set-audio-levels and analyze-audio-waveform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any explicit guidance on when to use this tool versus alternatives. There is no mention of when to prefer it over analyze-audio-waveform or set-audio-levels, so the usage context is implied only.
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 burden. It discloses that the tool checks statuses and reads log tails, implying a read-only operation. However, it does not explicitly state that it has no side effects, what happens for invalid PIDs, or any permission requirements, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, highly informative sentence. Every clause adds value: the tool scope, the specific checks, and the log output. No redundant or filler content exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity status tool with one optional parameter and no output schema, the description adequately covers what the tool reports (running/finished statuses and log tails). It lacks explicit mention of the return format, but the description gives enough conceptual detail for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the pid parameter is described as 'Optional specific render PID. If omitted, reports all tracked renders.' The tool description adds no additional parameter detail, so it does not elevate beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and identifies the exact resource ('background aerender renders started with render-aerender'). It clearly distinguishes this tool from siblings by scoping it to aerender background renders and specifying outputs (running/finished status, log tails), which sets it apart from render-queue or start-render.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use this tool: after renders have been started with render-aerender. It clearly implies the usage context (checking status of those background renders) without explicitly naming alternatives or exclusions, but the scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the whole composition is duplicated first, preserving all layers/effects/animations, details how nested precomps are handled without modifying originals, and mentions auto-detection of Arabic with RTL. It falls short of explicitly stating whether the source composition itself is modified, but overall it is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the primary purpose and uses every sentence to add value (duplication behavior, nested precomp handling, RTL logic, caller responsibility). It is appropriately sized for the tool's complexity, though slightly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core functionality well: duplication, text swapping, path handling, and RTL detection. It does not explicitly mention return values or what happens after creation, but given the complexity and rich schema, the description is largely complete. Slight gaps exist around source comp modification and any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema, especially for the complex `path` parameter (explaining precomposition duplication/reuse) and clarifying that `translations` should contain already-translated strings. This extra guidance enhances understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a localized duplicate of a composition by swapping in translated text for text layers. It uses a specific verb ('Create') and specifies the resource ('localized duplicate of a composition'), and the mention of 'same logic as create-text-layer' helps distinguish it from that sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (localizing a composition) and notes that translation is the caller's job, but it does not explicitly state when not to use it or compare it to alternatives like create-text-layer or duplicate-layer. Usage context is clear but without explicit exclusions.
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 transparently explains the comp-selection precedence and the template prerequisite, which adds useful behavioral context. However, it does not disclose whether the render starts automatically, how existing render-queue items are affected, or what the return value or error behavior is—gaps that matter for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the core action, followed by selection rules and a necessary prerequisite. Every sentence earns its place, with no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 optional parameters, no required parameters, no output schema, and no annotations, the description covers the core task and key decision logic (comp selection, template existence). It could more explicitly state that this tool only queues/configures and that a separate sibling such as start-render is needed to actually start rendering, but the schema handles parameter details and the overall picture is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters, so a baseline of 3 applies. The description adds meaning beyond the schema by framing compName as most reliable, clarifying compIndex as a fallback, and explaining the active-comp behavior when both are empty. It also reinforces that templates must pre-exist, which directly applies to the two template parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add a composition to the After Effects render queue and configure its output.' It uses a specific verb and resource, and the comp-selection details distinguish it from sibling tools like start-render or render-queue, which focus on different stages of the rendering workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete selection guidance: compName is 'most reliable', compIndex is 1-based and used only if compName is omitted, and leaving both empty uses the active comp. It also notes the prerequisite that templates must already exist. It does not explicitly contrast with sibling tools like start-render or render-status, but the intended usage is reasonably clear.
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 a key side effect—'Setting position clears its existing keyframes first'—and enumerates the properties affected, which is useful transparency for a mutation tool. It does not mention other potential side effects like whether other property sets clear keyframes, but this is a minor 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence adds value. It summarizes what the tool does, how operations are targeted, and an important side effect without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch property-setting tool with no output schema, the description covers the main functionality, property options, and a notable side effect. It does not mention return values or error behavior, but these are less critical and the schema fills in comp selection and property formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all parameters, including the operations array structure and property details. The description adds context about keyframe clearing and the batch nature, but the schema already explains the parameter meanings well, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb-resource pair ('Set transform/visibility properties on MANY layers') and clearly distinguishes this batch operation from singular tools like setLayerKeyframe. The scope ('MANY layers') and property list are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies a batch use case ('on MANY layers in one call') and lists the properties that can be set, which differentiates from single-layer alternatives. However, it does not explicitly state when not to use it or name alternative tools for single-layer operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the process: sample frames across the duration, composite them into a labeled grid, and return a single image. It also addresses comp selection (name, 1-based index, or active comp). It does not mention timeout or resource implications, but the behavior is well-articulated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core value proposition ('See a composition's whole timeline at a glance'), followed by the method and selection instructions. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations exist, so the description must cover the return value and key behaviors. It does so by stating the output is a single labeled image and explaining comp selection. The remaining parameters are well-documented in the schema, and the use case is clear. Minor gaps like timeout behavior are not critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema: it reiterates the comp selection options and clarifies '1-based index', but does not elaborate on count, maxWidth, or timeoutMs. This is sufficient since the schema already documents each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: rendering N frames from a composition and compositing them into a single labeled thumbnail grid. It uses a specific verb (render/composite) and resource (composition timeline), distinguishing it from sibling tools like see-frame or get-layer-clip-frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context ('Use this to perceive motion, timing, and easing cheaply') and explains the advantage of one image over many. It does not explicitly name alternatives or state when not to use it, but the guidance is sufficient for an AI to choose appropriately.
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 burden of behavioral disclosure. It does explain the auto-detection of direction and default alignment for RTL, which is valuable. However, it doesn't mention behavior around composition selection, error handling, or side effects (e.g., whether it replaces existing layers). This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core action, and every sentence adds value. It efficiently covers the unique feature (Arabic/RTL) and the practical 'works in any language' note without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema), the description covers the essential context: what the tool does, its primary differentiator, and compatibility. It doesn't explain return values or errors, but for a creation tool that's typically implicit. It's nearly complete for the target use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining how `direction` interacts with `alignment` (auto-detection, forcing, default right-alignment for RTL) and by suggesting font families that support Arabic. This clarifies the most nuanced parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Create a text layer') and clearly distinguishes this tool from siblings like create-adjustment-layer or create-composition by highlighting full Arabic/RTL support. It immediately communicates the tool's unique value proposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: whenever a text layer is needed, especially for Arabic/RTL content. It doesn't explicitly name alternatives or exclusions, but the phrasing 'Works on After Effects in any language' implies broad applicability. Slight lack of explicit alternative guidance prevents a 5.
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, and it provides useful behavioral details: it renders the current frame, returns a side-by-side and a difference map, and explains that the difference map is bright where they differ. It does not disclose whether the operation is non-destructive or what happens with invalid reference paths, but it does not contradict annotations and offers more than a minimal description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, with two sentences that are front-loaded with the primary verb and resource. It packs meaningful details (rendering, output types, difference map interpretation, and comp selection) into a compact space without redundant or verbose wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description sufficiently explains what the tool returns and how to specify inputs, allowing an agent to invoke it confidently. It could additionally mention the time parameter or error handling, but those are at least partially covered by the input schema, so the overall completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptive text, so the baseline is 3. The description does not add new meaning beyond what the schema provides—it only restates the comp selection rule and the need for an on-disk path, both already in the schema. No additional parameter semantics are introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource phrase, 'Compare a composition against a reference image,' and clearly distinguishes the tool from siblings like see-frame or contact-sheet. It further details the two outputs (side-by-side and difference map) and explains the purpose of seeing exactly where the render deviates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to compare a composition against a reference and converge on a match. It does not explicitly name alternatives or exclusions, but within the context of sibling tools this is the only comparison-focused tool, making the usage clear.
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 of behavioral disclosure. It explicitly mentions destructive actions ('clear the whole queue', 'remove a single item by index'), which is good, and notes that list returns 'status and output path'. However, it does not disclose whether clear is irreversible, whether permissions are needed, or how the 'remove' action behaves with an invalid index. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose ('Inspect or manage') then efficiently enumerates the specific actions and their targets. Every word adds value; no repetition of parameter names or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action tool with two parameters and no output schema, the description is quite complete: it covers all three actions and hints at return data for list. It lacks details on error handling or edge cases (e.g., invalid index), but given the tool's moderate complexity and the clear param descriptions, this is sufficient. The presence of sibling tools like render-status further reduces the need for extensive explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds meaningful context beyond the schema: it ties 'index' to the remove action ('remove a single item by index') and clarifies the list output ('status and output path'). This reinforces and extends the parameter semantics already provided in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Inspect or manage' with a clear resource 'After Effects render queue' and enumerates specific actions (list, clear, remove). It distinguishes from sibling tools like render-status and start-render by focusing on queue inspection and mutation rather than status or rendering execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys usage context by listing the three actions available ('list', 'clear', 'remove') and their effects, implying when to use this tool versus render-status or start-render. It does not explicitly name alternative tools or state when-not-to-use, but the action-based guidance is clear enough for an agent to select this tool for queue management tasks.
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 carry the transparency burden. It discloses key behavior (create vs. modify, two shape input methods), but it does not explain what happens if both maskRect and maskPath are provided, nor does it mention error cases, coordinate assumptions, or side effects. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the primary purpose and following with essential usage. Every clause is informative, with no fluff or repetition of schema content. It is an model of concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters and no output schema, the description covers the central choices (shape type, add/modify) but omits mention of property parameters like maskOpacity, maskFeather, and maskExpansion, which are left to the schema. It also doesn't address edge cases or return behavior. Still, the essential usage is well-covered, so it's adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds value by clarifying the OR relationship between maskRect and maskPath, a semantic not fully captured in the individual parameter descriptions. It also reinforces the maskIndex add/modify behavior, though this is already present in the schema. Overall, it provides a modest increment beyond structured definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create or modify a mask on a layer.' It names the specific resource (mask on a layer) and the actions (create/modify), which distinguishes it from sibling tools like setLayerKeyframe or setLayerExpression. The verb+resource combination 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides actionable usage: 'Provide the shape as maskRect ... OR maskPath' and explains the distinction between adding and modifying via maskIndex. It does not explicitly mention when not to use this tool or name alternatives, but the context is clear for a mask-specific operation. This falls short of a 5 because it lacks explicit exclusionary guidance.
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 transparency burden and handles it well. It discloses mode-specific behaviors (continuous waveform following vs. pulse-and-decay peaks), keyframe generation details (one per sample), and property targeting (plain layer vs. effect property). It also notes format dependencies, though it stops short of mentioning undo or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
It is a dense but well-structured paragraph: purpose, then modes, then compatibility and targeting. Every sentence contributes useful information without fluff, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 22 parameters and no output schema, the description covers all critical aspects: main purpose, mode semantics, supported audio formats, and property targeting. It could mention preconditions like composition existence, but overall it is highly complete for the given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining how numPoints maps directly to keyframe count and is intentionally capped lower than analyze-audio-waveform. It also clarifies how curve affects peaks mode, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate After Effects keyframes for a layer property directly from an audio file's waveform, in one call.' It clearly distinguishes itself from the sibling analyze-audio-waveform by saying 'no need to call analyze-audio-waveform and compute keyframes by hand first,' and elaborates on two modes to clarify its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context, explaining when to use it (for audio-driven keyframes) and describing two modes with example effects. It references the sibling analyze-audio-waveform for format compatibility. While it doesn't explicitly enumerate alternatives like setLayerKeyframe, it clearly implies this is the preferred automated approach versus manual keyframing.
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?
The description strongly implies read-only behavior via 'inspect' and 'SEE its exact state', and provides detailed output expectations. However, it does not explicitly state that no modifications occur, which with no annotations leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the purpose and using a list structure to enumerate covered properties without repeating schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and absence of an output schema, the description provides a thorough account of return contents (transform, effects, masks, markers, source, text) and selection logic, making it self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents all six parameters (100% coverage). The description adds a brief note on selection options (compName/compIndex, layerIndex/layerName, active comp) but does not add semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deeply inspects one layer and enumerates the exact state elements (type, transform, effects, masks, markers, source, text). This distinguishes it from sibling tools like inspect-comp or list-layer-effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It frames the tool as a pre-edit inspection step ('before making precise edits') and specifies that it targets a single layer, selected by comp and layer identifiers. It lacks explicit alternatives/exclusions, so not a 5.
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?
No annotations exist, so the description carries the burden. It transparently discloses downscaling (maxWidth 512), native-resolution option (maxWidth 0), performance/cost rationale, and the still-vs-playback caveat. This provides valuable behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence earns its place: use case, selection method, output caveats, and defaults. It front-loads the core purpose with 'SEE what a composition actually looks like' and remains readable despite the detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description adequately explains return type (images), parameter defaults, and behavioral caveats. It leaves some details to the schema (e.g., timeoutMs) but covers the core usage envelope well, including the self-correct workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning around maxWidth (fast/cheap, native resolution), comp selection (name/index/active), and underscores the still limitation. This enriches, rather than merely repeats, schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders composition frames to images for visual verification, using specific verbs like 'render' and listing concrete problem cases (clipped text, wrong colors, RTL shaping). This distinguishes it from siblings like inspect-comp (structured state) and other render tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use 'after edits' to catch visual issues, and gives examples of problems the DOM doesn't reveal. It also implies when_not_to_use by noting time-based effects differ from playback, but doesn't name alternative tools directly (though includeState references inspect-comp).
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 the return format (normalized amplitude values and peak times), the transcoding behavior for non-WAV formats, dependency on ffmpeg, and the env var override. This adds substantial behavioral context beyond the input schema, though it doesn't mention error conditions or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: purpose, prerequisite step, return details, and format handling. Each sentence earns its place, no fluff. The structure front-loads the core purpose and then provides critical workflow and dependency information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two params, no output schema, and no annotations, the description covers the essential workflow (get-audio-info first), output shape, and format constraints. It doesn't explain what 'peaks/transients' mean or specify time intervals, but these are not critical for selecting or invoking the tool correctly. Overall, it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying filePath semantics ('WAV works with no extra dependency; other formats need ffmpeg') and numPoints ('Higher = more detail'). These reinforce and extend the schema descriptions, making the tool easier to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Analyze an audio file to extract waveform amplitude data and detect peaks/transients.' This is a specific verb+resource+scoped purpose, and it distinguishes from siblings like get-audio-info (which likely returns metadata) and animate-to-audio (which uses audio for animation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'First call get-audio-info to retrieve the sourceFilePath, then pass it here.' It also explains when ffmpeg is needed versus native WAV support. However, it doesn't explicitly contrast with alternatives like animate-to-audio or state when not to use this tool, so it falls short of a fully explicit when-not/alternatives statement.
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 the full burden of behavioral disclosure. It does disclose normalization, auto-detection of input range, mapping, and target selection. However, it omits the destructive default behavior of clearing existing keyframes (clearExisting defaults to true in the schema), which is a significant side effect for a mutation tool. The description should warn that existing keyframes are removed by default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose + examples, input mode constraints, normalization pipeline, and target selection. It is front-loaded with the core verb and resource, and avoids fluff while covering the essential operating model. No redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 22 parameters, nested objects, no output schema, and no annotations, the description is quite comprehensive. It explains the main workflow, input modes, normalization, and targeting. The primary gap is the missing disclosure of destructive default (clearing existing keyframes) and lack of any statement about modifying the After Effects project state, which would be expected for a mutation tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 raises this by explaining the conceptual pipeline: how data/values+interval relate, how inputMin/inputMax auto-detection works, and how effect selectors (effectIndex/effectName/effectMatchName) redirect targeting. This adds meaning beyond the individual parameter descriptions by tying them into the normalization and targeting workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Generate After Effects keyframes for a layer property directly from an arbitrary numeric data series.' It distinguishes itself from the sibling animate-to-audio by explicitly stating 'not audio; see animate-to-audio for that' and by listing example data types. This clearly separates its scope from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use this tool: for any time-ordered numeric series, and explicitly excludes audio, directing users to animate-to-audio. It also explains the two input modes ('Provide either `data` ... or `values` + `interval` ... - not both') and when to use effect property targeting vs default layer property, providing clear context for selecting among the sibling tools.
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 transparency burden. It discloses the exact output content—settings (size, fps, duration, work area) and layer summary fields—and the comp selection fallback. It does not explicitly state that the tool is side-effect-free, but the 'inspect' and 'Map' framing strongly implies a read-only operation; a direct statement would make it a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: output specification, usage guidance, and parameter selection. The first sentence is dense but every item in the enumeration is informative; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing every output category in detail (composition settings and a comprehensive layer summary field list). It also explains comp selection and the recommended next action, making the tool fully self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameter semantics, including compName being recommended, compIndex being 1-based, and active comp fallback. The description essentially restates this selection logic without adding new parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Map a whole composition') and enumerates exactly what is returned: settings plus every layer with a detailed summary. It clearly differentiates from the sibling tool inspect-layer by noting that one should 'call inspect-layer for one layer's full detail.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the intended use case: 'Use this to navigate a comp and decide what to edit, then call inspect-layer for one layer's full detail.' It also provides clear selection guidance for compName/compIndex and the active comp fallback, so the agent knows when and how 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 full transparency burden. It discloses background/headless execution, the save-first default, projectPath override, immediate return, and waitMs behavior. It omits error-handling details but covers core behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with purpose, and each sentence adds value: purpose, differentiation, requirement, default behavior, and return semantics. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 9-parameter schema and no output schema, the description sufficiently covers main usage, prerequisites, async behavior, and follow-up. It does not spell out the return value format, but 'Check progress with render-status' implies a handle is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds prose context for projectPath and waitMs, clarifying how they alter execution. It also explains the saveFirst default, enriching the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a composition to a file in the background using aerender, and explicitly contrasts it with start-render. This distinguishes it from siblings and gives a specific verb, resource, and execution mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Unlike start-render, this does NOT freeze your After Effects UI'. Also states the project-save requirement and directs the user to render-status for progress, effectively outlining a workflow.
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 of disclosure. It communicates that the tool is a read-only verification and lists what it reports, implying non-destructive behavior. It also discloses the health-check nature and a possible remediation step. It could be stronger with an explicit non-mutating statement, but it is already clearly safe and informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loads the purpose with 'Health check'. Every sentence earns its place: purpose and output, usage timing, and troubleshooting tip. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), but the description compensates by listing the expected returned fields (version, AE version, bridge folder, project/active comp). It also tells the agent when to run it and what to do on mismatch, making the tool fully usable without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema has no properties. The description wisely avoids inventing parameter details and focuses on behavior and output, which aligns with the baseline for parameterless tools. Nothing more is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with 'Health check' and uses specific verb 'verify', clearly stating it checks that the After Effects MCP Bridge panel is open and responding. It enumerates the report contents (version, AE version, bridge folder, open project/active comp), which unambiguously identifies the tool's function and differentiates it from sibling tools like run-bridge-test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Run this FIRST when anything times out or behaves oddly', giving a clear condition for use. It also provides an alternative action for a version mismatch: re-run `npm run install-bridge` and restart After Effects, which tells the agent what to do next rather than just describing the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/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 discloses critical behaviors: code runs as a function body, must return JSON-serializable values, the script is wrapped in a single undo group, and errors return message plus line number. It also notes not to call beginUndoGroup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence provides necessary guidance. It is front-loaded with the core purpose and immediately follows with usage examples and critical constraints. No redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary code, the description is remarkably complete. It covers return contract, serialization, undo behavior, access points, error format, and gives a concrete example. No output schema exists, so the description correctly takes on the burden of explaining what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description significantly enhances the script parameter by explaining the function-body execution model, return value requirements, and error behavior. The timeoutMs parameter is only described in the schema, but the description adds no further detail, which is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs arbitrary ExtendScript in After Effects and returns the result. It also differentiates from sibling tools by positioning itself as the catch-all for cases not covered by dedicated tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance to use the tool for anything the dedicated tools do not cover, with a long list of examples. It clearly implies the alternative (dedicated tools) but does not name specific sibling tools or provide an explicit 'when not to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses critical blocking behavior, AE UI unresponsiveness, timeout semantics, and post-timeout continuity. This is exemplary behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, important warning, and usage guidance. Every sentence earns its place with no filler, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a blocking operation with a single parameter and no output schema, the description covers the core purpose, operational impact, timeout behavior, and follow-up steps. It is sufficiently complete for an agent to invoke and handle the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for timeoutMs, and the schema already describes the parameter. The description adds practical context about when to raise the timeout and what happens if it expires, going beyond the schema's literal definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Render all QUEUED items') on a specific resource ('After Effects render queue'), clearly distinguishing it from sibling tools like add-to-render-queue and render-queue. The scope is explicit, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit prerequisites ('Add items first with add-to-render-queue'), guidance on timeout handling ('raise timeoutMs for long renders; if the wait times out the render still continues'), and a clear alternative for checking status ('check status later with render-queue'). This fully informs when and how to use the tool.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/omar-hesham/after-effect-mcp-with-claude'
If you have feedback or need assistance with the MCP directory API, please join our Discord server