After Effects MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Several tools have overlapping purposes, such as apply-effect, mcp_aftereffects_applyEffect, and apply-effect-template vs mcp_aftereffects_applyEffectTemplate. The help tools also overlap somewhat. An agent would find it hard to distinguish between these duplicates.
Naming Consistency2/5
Naming conventions are wildly mixed: hyphenated names like run-script and get-results, camelCase like setLayerKeyframe and setLayerExpression, and snake_case with mixed case like mcp_aftereffects_applyEffect. There's no consistent verb_noun pattern.
Tool Count4/5
The raw count of 13 tools is within the reasonable range, but the presence of duplicates inflates the count. It's not excessive, but the set could certainly be trimmed to eliminate redundant tools.
Completeness3/5
The core After Effects operations are covered (create composition, set keyframes, expressions, apply effects, run scripts), but there are gaps like modifying compositions, adding layers, or rendering. The run-script tool may fill some gaps, but the surface feels incomplete for a full workflow.
Average 3.2/5 across 13 of 13 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 says 'test', implying a safe operation, but does not explain side effects, return values, or whether the composition is modified. This is insufficient for a tool in a creative environment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified and lacks necessary context. It is concise but not effectively structured to convey key information, earning a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that tests animation operations, the description should clarify what the test does, how results are returned, and how it relates to specific operations like keyframe and expression. With no output schema and no annotations, the description is insufficient for an agent to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with clear descriptions for all three parameters, including the operation enum. The description itself adds no parameter-specific detail, so the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('test') and a resource ('animation functionality in After Effects'), giving a general sense of the tool's purpose. However, it is vague about what aspect of animation is tested and does not distinguish it from sibling tools like run-bridge-test or setLayerKeyframe/setLayerExpression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent without direction on selecting this tool over the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It offers no transparency about side effects (e.g., modifying the layer's effect stack), error conditions, or whether the effect is appended or replaces existing effects. The single sentence provides only the obvious action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified rather than appropriately concise. It lacks any structured detail or context that would make it useful for an agent deciding how to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a tool that has 5 parameters including a nested object and two effect identifier variants, the description leaves out important context such as prerequisites, side effects, error behavior, and when to use effectName versus effectMatchName. The schema covers parameter meaning but not operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself does not explain any parameters, but the input schema covers all 5 parameters with detailed descriptions and examples, so schema coverage is 100%. The baseline for high schema coverage is 3, and the description adds no extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (apply) and target (an effect to a layer in After Effects). However, it does not differentiate from sibling tools like 'apply-effect' or 'apply-effect-template', which might have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring an active composition or selected layer, nor does it explain when to prefer effectMatchName over effectName.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavioral details. It only states the action (apply an effect) without explaining side effects (e.g., modifying the layer), requirements (e.g., indices must be valid), or the behavior when parameters conflict (e.g., effectName vs. effectMatchName). The description adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized for a basic tool purpose statement and is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema, no annotations), the one-sentence description is insufficient. It does not explain return values, error behavior, or the relationship between optional parameters. The schema covers parameter definitions but the description lacks contextual completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters having descriptions, so the baseline is 3. The tool description does not add any parameter-specific meaning beyond the schema. It does not clarify how to choose between effectName, effectMatchName, or presetPath, but the schema already provides adequate descriptions for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Apply an effect to a layer in After Effects.' It uses a specific verb ('apply') and identifies the resource ('effect') and target ('layer'). However, it does not distinguish from the sibling tool 'apply-effect-template', which also applies effects. Thus, it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context such as requiring an active composition or layer. No sibling tools are referenced, and there is no implied usage beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does not mention side effects, whether the operation is destructive (e.g., overwrites existing effects), error conditions, or any implicit behavior like requiring a specific application state. The minimal text leaves the agent without critical safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary verb and object. It wastes no words and is easy to scan. However, the brevity borders on under-specification, so it does not earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters including a nested object and an enum, plus no output schema, the description should explain more about the effect of applying templates, what 'customSettings' can override, and possible results or side effects. The one-liner does not provide enough context for an agent to confidently invoke the tool in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-specific details beyond naming the action. It does not explain how 'customSettings' interacts with the predefined templates or what 'templateName' values imply, but the schema already handles parameter names and types adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('apply a predefined effect template') and the target resource ('a layer in After Effects'). It is specific enough to distinguish from generic effect application, though it does not explicitly contrast with sibling tools like 'apply-effect'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, such as having a composition open or a layer selected, nor any exclusions or contextual cues for when to choose this over other effect-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility for behavioral disclosure. It only states that the tool provides help, but does not describe what form the help takes, whether it is read-only, what topics are covered, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It contains no unnecessary words or information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter help tool with no output schema, the description is minimally viable. However, it lacks context about what types of help are available and does not mention the effect-help sibling, leaving some ambiguity about the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the schema already confirms no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get help on using the After Effects MCP integration' clearly states the tool's purpose with a specific verb and resource. It is distinguishable from the sibling 'mcp_aftereffects_get_effects_help' by focusing on the entire integration rather than effects-specific help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions. It only implies that users should turn here when they need help, but doesn't differentiate from the effect-help sibling or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. It only states the action without disclosing side effects (e.g., whether existing effects are replaced, whether it modifies the layer permanently, or what happens with customSettings).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. It is front-loaded and immediately communicates the tool's core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters including a nested object and an enum, the description provides minimal context. It does not explain return values, potential errors, or the purpose/effects of templates. With no output schema or annotations, the description is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all four parameters described, including an enum for templateName. The description adds no additional parameter semantics, but the baseline 3 is appropriate when schema handles the documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply') and the resource ('predefined effect template to a layer in After Effects'). It is specific enough to distinguish from sibling 'apply-effect' by mentioning 'template'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'mcp_aftereffects_applyEffect'. There are no contextual cues, exclusions, or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It is silent on side effects, error conditions (e.g., missing property, invalid value type), whether existing keyframes are overwritten, or what the tool returns. The single sentence provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose without any filler. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description is too minimal to cover return values, failure modes, or operational context (e.g., whether this is an insert, update, or destructive operation). Given the moderate complexity, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with descriptions for each parameter including example values for the 'value' parameter. The tool description itself adds no additional parameter semantics, but given the thorough schema, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Set a keyframe') on a specific resource ('a specific layer property') with temporal context ('at a given time'). It is distinct from siblings like setLayerExpression and apply-effect, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or scenarios where another tool would be more appropriate. With many sibling tools available, this lack of direction leaves 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 provided, the description carries the full burden of behavioral disclosure. It only states the core action and gives no details about side effects (e.g., modifying the current project), permissions, or what happens if a composition with the same name already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. It contains no unnecessary words and is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich and covers parameter details, but the description lacks context about behavioral expectations (e.g., whether a project must be open, whether it returns a composition ID). For a create operation, this is a notable but minor gap, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the description does not need to add much. The phrase 'with specified parameters' adds no specific meaning beyond what the schema already provides, matching 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Create a new composition in After Effects with specified parameters'. The verb 'create' and resource 'composition in After Effects' are specific, and it is distinct from sibling tools like run-script 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, such as an open After Effects project, nor does it compare with sibling tools like apply-effect or run-script.
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. The non-destructive, read-only nature of a help tool is apparent from the name and description, but the description does not disclose return format, prerequisites, or any potential side effects. It adds only the purpose, not deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose with no redundancy or filler. It is perfectly 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero parameters, no output schema), so the description is mostly adequate. However, it does not specify the scope of help (e.g., which effects, level of detail) or how it relates to the other sibling tools, leaving some ambiguity for an agent deciding between alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, and the description does not need to elaborate. Since there are no parameters, the schema is completely self-explanatory, and the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('get help') and resource ('After Effects effects'), making the tool's purpose understandable. It is somewhat distinct from the sibling 'get-help' by being effects-specific, but it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the generic 'get-help' sibling or other tools. The description lacks any mention of alternatives or exclusions, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does indicate the dual set/remove capability, but it omits important details such as whether setting overwrites existing expressions, what happens if the property does not exist, or any error/permission requirements. This is a meaningful gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and object. Every word is purposeful, with no filler or redundancy. It is highly concise while still conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters and no output schema, the description provides only a minimal statement of purpose. It does not explain overwrite behavior, error conditions, or how this tool fits into a typical workflow. The schema covers parameter specifics, but the description leaves significant operational ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions already explain the meaning of each field, including the empty-string removal behavior for expressionString. The tool description adds little beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set or remove' and the resource 'expression for a specific layer property', accurately capturing the tool's function. It is distinct from sibling tools like setLayerKeyframe (keyframes) and apply-effect (effects), leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting or removing expressions on layer properties, but it does not explicitly distinguish when to choose this tool over alternatives like setLayerKeyframe or apply-effect. There is no explicit 'when to use' or exclusion guidance, only the implied context from the tool's name and description.
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. It clearly discloses the read-only nature, which is a key behavioral trait, but it does not detail what happens on execution, error behavior, or whether parameters affect safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, front-loading the action and key constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with no output schema and no annotations. It leaves unclear return values, how to discover available scripts, and any prerequisite conditions. The read-only qualifier helps but doesn't compensate for the lack of operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents 'script' and 'parameters'. The description adds no additional meaning about parameter formats, valid script names, or parameter passing rules, so it matches the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('run') and explicitly states the tool executes a 'read-only script' in After Effects, which distinguishes it from mutating tools like setLayerKeyframe or apply-effect. The read-only qualifier clarifies 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for non-destructive script execution via the 'read-only' qualifier, but it does not explicitly state when to prefer this over siblings like get-results or get-help, nor does it mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool gets results, which implies a read-only operation, but it does not disclose what happens if no script has been run, whether results are cleared after retrieval, or any error conditions. The description adds minimal behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straight-to-the-point sentence that wastes no words. The key action and object are front-loaded, making it instantly clear and appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter getter, the description covers the primary purpose, but it lacks an explicit mention of the return value's structure or format. Since there is no output schema, the agent only knows it will receive 'results' without any indication of shape, which is a notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides full coverage by definition. Since there are no parameters to document, the description is not required to add parameter-level semantics, and the baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Get' clearly identifies this as a retrieval operation, and the resource is specifically 'results from the last script executed in After Effects', which distinguishes it from sibling tools like run-script or setLayerExpression. The scope is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used after running a script by referencing 'the last script executed', but it does not explicitly mention run-script as a prerequisite or state when not to use this tool. No alternatives are named, so the usage context is only implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions 'apply test effects', implying the tool mutates state, but it does not explain any safety implications, side effects, or what 'verify communication' means operationally. There is no mention of prerequisites, return values, or potential disruptions, leaving a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and purpose. Every word earns its place: 'Run' (verb), 'bridge test effects script' (resource), 'verify communication and apply test effects' (purpose). There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema) and the clear purpose stated, the description is largely complete. It tells the agent what the tool does and why. However, it does not elaborate on what 'test effects' are or how results are observed, which could be useful for full completeness, but this is not critical for a zero-parameter test script.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline per rubric is 4. The description adds contextual meaning by explaining the script's purpose, but since there are no parameters to document, it does not need to compensate for missing schema details. The description is sufficient for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Run the bridge test effects script'—a specific verb and resource. It also explains the intended outcome: 'to verify communication and apply test effects'. This distinguishes it from sibling tools like run-script, which is generic, and apply-effect, which likely targets specific effects rather than a test script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you want to verify communication and apply test effects. It does not explicitly mention alternatives or exclusions, but the purpose is self-contained enough to guide usage. Without specifying when not to use it, it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/keemyschmidt/AE-MCP-TEST'

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