How do I use After Effects MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@After Effects MCP Server Create a 1920x1080 composition with a text layer saying 'MCP Works!'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

After Effects MCP Server

by rtx1025189518-source

Overview Schema Related Servers Score Discussions

JavaScript

Local

🎬 After Effects MCP Server

Node.js Build License Platform

✨ A Model Context Protocol (MCP) server for Adobe After Effects that enables AI assistants and other applications to control After Effects through a standardized protocol.

Related MCP server: After Effects MCP Server

📦 Features

🎥 Core Composition Features

Create compositions with custom settings (size, frame rate, duration, background color)
List all compositions in a project
Get project information such as frame rate, dimensions, and duration

🧱 Layer Management

Create text layers with customizable properties (font, size, color, position)
Create shape layers (rectangle, ellipse, polygon, star) with colors and strokes
Create solid/adjustment layers for backgrounds and effects
Create camera layers with configurable zoom and position
Create null objects for animation control
Modify layer properties like position, scale, rotation, opacity, timing
Toggle 2D/3D mode for layers
Set blend modes (normal, multiply, screen, etc.)
Track matte support (alpha, luma, inverted)
Duplicate layers with optional rename
Delete layers from composition
Create/modify masks with feather, expansion, and opacity

🌀 Animation Capabilities

Set keyframes for layer properties (Position, Scale, Rotation, Opacity, etc.)
Apply expressions to layer properties for dynamic animations
Batch set properties across multiple layers at once

⚙️ Setup Instructions

🛠 Prerequisites

Adobe After Effects (2022 or later)
Node.js (v14 or later)
npm or yarn package manager

📥 Installation

Clone the repository

git clone https://github.com/Dakkshin/after-effects-mcp.git
cd after-effects-mcp

Install dependencies
```
npm install
# or
yarn install
```
Build the project
```
npm run build
# or
yarn build
```
Install the After Effects panel
```
npm run install-bridge
# or
yarn install-bridge
```
This will copy the necessary scripts to your After Effects installation.

🔧 Update MCP Config

Option 1: Using .mcp.json (Recommended for Claude Code)

The repository includes a .mcp.json file for easy configuration. Copy or reference it in your MCP settings:

{
  "mcpServers": {
    "AfterEffectsMCP": {
      "command": "node",
      "args": ["PATH/TO/after-effects-mcp/build/index.js"]
    }
  }
}

Option 2: Manual Configuration

Go to your client (e.g., Claude or Cursor) and update your config file:

{
  "mcpServers": {
    "AfterEffectsMCP": {
      "command": "node",
      "args": ["C:\\Users\\Dakkshin\\after-effects-mcp\\build\\index.js"]
    }
  }
}

▶️ Running the Server

Start the MCP server
```
npm start
# or
yarn start
```
Open After Effects
Open the MCP Bridge Auto panel
- In After Effects, go to Window > mcp-bridge-auto.jsx
- The panel will automatically check for commands every few seconds
- Make sure the "Auto-run commands" checkbox is enabled

🚀 Usage Guide

Once you have the server running and the MCP Bridge panel open in After Effects, you can control After Effects through the MCP protocol. This allows AI assistants or custom applications to send commands to After Effects.

📘 Creating Compositions

You can create new compositions with custom settings:

Name
Width and height (in pixels)
Frame rate
Duration
Background color

Example MCP tool usage (for developers):

mcp_aftereffects_create_composition({
  name: "My Composition", 
  width: 1920, 
  height: 1080, 
  frameRate: 30,
  duration: 10
});

✍️ Working with Layers

You can create and modify different types of layers:

Text layers:

Set text content, font, size, and color
Position text anywhere in the composition
Adjust timing and opacity

Shape layers:

Create rectangles, ellipses, polygons, and stars
Set fill and stroke colors
Customize size and position

Solid layers:

Create background colors
Make adjustment layers for effects

🕹 Animation

You can animate layers with:

Keyframes:

Set property values at specific times
Create motion, scaling, rotation, and opacity changes
Control the timing of animations

Expressions:

Apply JavaScript expressions to properties
Create dynamic, procedural animations
Connect property values to each other

🛠 Available MCP Tools

Command	Description
`create-composition`	Create a new composition
`run-script`	Run a JS script inside AE
`get-results`	Get script results
`get-help`	Help for available commands
`setLayerKeyframe`	Add keyframe to layer property
`setLayerExpression`	Add/remove expressions from properties
`setLayerProperties`	Set layer properties (position, scale, rotation, opacity, blendMode, threeDLayer, trackMatteType, enabled, etc.)
`batchSetLayerProperties`	Apply properties to multiple layers
`getLayerInfo`	Get layer info (position, 3D status)
`createCamera`	Create camera layer
`createNullObject`	Create null object for animation
`duplicateLayer`	Duplicate a layer
`deleteLayer`	Delete a layer
`setLayerMask`	Create/modify layer masks

👨‍💻 For Developers

🧩 Project Structure

src/index.ts: MCP server implementation
src/scripts/mcp-bridge-auto.jsx: Main After Effects panel script
install-bridge.js: Script to install the panel in After Effects

📦 Building the Project

npm run build
# or
yarn build

Note: This project uses esbuild for fast builds, replacing the previous TypeScript compiler approach that could run out of memory on larger codebases.

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Star History

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

13 tools

apply-effectC

Apply an effect to a layer in After Effects

ParametersJSON Schema

Name	Required	Description
`compIndex`	Yes	1-based index of the target composition in the project panel.
`effectName`	No	Display name of the effect to apply (e.g., 'Gaussian Blur').
`layerIndex`	Yes	1-based index of the target layer within the composition.
`presetPath`	No	Optional path to an effect preset file (.ffx).
`effectCategory`	No	Optional category for filtering effects.
`effectSettings`	No	Optional parameters for the effect (e.g., { 'Blurriness': 25 }).
`effectMatchName`	No	After Effects internal name for the effect (more reliable, e.g., 'ADBE Gaussian Blur 2').

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits (e.g., does it replace existing effects, require certain permissions?). It does not. The minimal description adds no behavioral insight 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/5

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

Single sentence, no fluff. However, for a tool with 7 parameters, it could be slightly longer to improve usability without sacrificing conciseness.

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

Completeness2/5

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

No output schema, no side effects described, and no explanation of how parameters interact (e.g., effectName vs effectMatchName). The description is insufficient for the tool's 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%, so baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides, so no improvement.

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 effect) and target (layer in After Effects), which is specific. However, it does not differentiate from sibling tools like apply-effect-template, relying on the tool name alone.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., apply-effect-template), no prerequisites, and no when-not-to-use scenarios. The description is too brief to provide usage context.

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

apply-effect-templateB

Apply a predefined effect template to a layer in After Effects

ParametersJSON Schema

Name	Required	Description
`compIndex`	Yes	1-based index of the target composition in the project panel.
`layerIndex`	Yes	1-based index of the target layer within the composition.
`templateName`	Yes	Name of the effect template to apply.
`customSettings`	No	Optional custom settings to override defaults.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided. Description does not disclose side effects (e.g., whether previous effects are overwritten), permission requirements, or undo behavior. For a mutation tool, this is insufficient.

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

Conciseness4/5

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

Single sentence, 10 words, front-loaded. Efficient but lacks depth; could include a bit more context without losing conciseness.

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

Completeness2/5

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

No output schema; description does not explain what happens after applying (e.g., return value, success/failure indication). Incomplete for an AI agent to understand full behavior.

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

Parameters3/5

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

Schema covers 100% of parameters with descriptions. Description adds no extra meaning beyond the schema; thus 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/5

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

Description clearly states the action (apply), the resource (predefined effect template), and target (layer in After Effects). Distinct from siblings like 'apply-effect' and 'create-composition'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as 'apply-effect' or 'setLayerKeyframe'. No mention of context or prerequisites.

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

create-compositionB

Create a new composition in After Effects with specified parameters

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Name of the composition
`width`	Yes	Width of the composition in pixels
`height`	Yes	Height of the composition in pixels
`duration`	No	Duration in seconds (default: 10.0)
`frameRate`	No	Frame rate in frames per second (default: 30.0)
`pixelAspect`	No	Pixel aspect ratio (default: 1.0)
`backgroundColor`	No	Background color of the composition (RGB values 0-255)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, so the description must disclose behavioral traits. It only says 'with specified parameters' but doesn't describe side effects (e.g., whether an existing project is required, if compositions are created in the active project, or if it modifies existing state). This is insufficient for a creation 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/5

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

Single concise sentence with no filler. However, it could be slightly expanded to include key behavioral notes without losing conciseness.

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

Completeness2/5

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

With 7 parameters including a nested object and no output schema, the description is too brief. It doesn't explain what happens after creation (e.g., return value, where the composition appears). The length is inadequate for the tool's 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%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides. For example, it doesn't explain the relationship between parameters or default behavior.

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 verb+resource: 'Create a new composition in After Effects'. It distinguishes from sibling tools like 'apply-effect' or 'setLayerExpression' which have different 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?

No guidance on when to use this tool versus alternatives (e.g., when to set duration vs not). No prerequisites or exclusions mentioned. The agent receives no decision support.

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

get-helpB

Get help on using the After Effects MCP integration

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

Description only states 'Get help' without revealing what the help contains (e.g., list of commands, syntax, examples) or any behavioral traits like response format or rate limits. Since no annotations are provided, the description carries full burden and fails to disclose behavior.

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?

Extremely concise single sentence. For a zero-parameter help tool, this is appropriately sized and front-loaded. Loses 1 point for lacking any structure or additional context.

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

Completeness3/5

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

Given no output schema and no annotations, the description minimally explains the tool's purpose but omits what kind of help is returned (e.g., text, URL, interactive). It is adequate but limited, especially for a help tool that might need to guide further use.

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?

No parameters exist, and schema coverage is 100% (vacuous). According to rubric, 0 params baseline is 4. The description does not add param info but none is needed.

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 'get' and resource 'help' and specifies the context 'using the After Effects MCP integration', making the purpose unambiguous. It distinguishes from sibling tools like 'apply-effect' or 'create-composition' which perform specific actions.

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

Usage Guidelines2/5

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

No guidance provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use, or specific scenarios where help is appropriate. The description lacks any usage context.

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

get-resultsA

Get results from the last script executed in After Effects

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations exist, so description must disclose behavior. It merely states it gets results without describing what happens if no script was executed, error conditions, or output format.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no unnecessary content.

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

Completeness2/5

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

With no output schema and no annotations, the description is too minimal. It does not specify return type, error handling, or prerequisites, leaving the agent underinformed.

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?

No parameters exist (schema coverage 100%), and description adds no extra meaning beyond the schema. Baseline for zero parameters is 4.

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 'Get' and the resource 'results from the last script executed in After Effects', distinguishing it from sibling tools like run-script.

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?

Usage is implied: after running a script, use this tool to retrieve results. However, no explicit guidance on when not to use or alternatives is provided.

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

mcp_aftereffects_applyEffectC

Apply an effect to a layer in After Effects

ParametersJSON Schema

Name	Required	Description
`compIndex`	Yes	1-based index of the target composition in the project panel.
`effectName`	No	Display name of the effect to apply (e.g., 'Gaussian Blur').
`layerIndex`	Yes	1-based index of the target layer within the composition.
`effectSettings`	No	Optional parameters for the effect (e.g., { 'Blurriness': 25 }).
`effectMatchName`	No	After Effects internal name for the effect (more reliable, e.g., 'ADBE Gaussian Blur 2').

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as error handling, persistence of changes, or effect dependency. The agent cannot infer reliability or side effects.

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

Conciseness4/5

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

The description is a concise single sentence. It is front-loaded with the core purpose, but for a tool with 5 parameters, slightly more context could be beneficial without sacrificing conciseness.

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

Completeness2/5

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

Given the tool's complexity (5 params, nested object, no output schema), the description is incomplete. It lacks information about return values, error scenarios, and effect prerequisites, which are critical for agent decision-making.

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 covers all 5 parameters with clear descriptions, including examples. The tool description adds no additional semantic value, but the schema itself is sufficient, leading to a baseline score of 3.

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

Purpose4/5

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

The description clearly states the action and resource ('Apply an effect to a layer in After Effects'). However, it does not differentiate from sibling tools like 'apply-effect' or 'apply-effect-template', which may cause ambiguity.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. This leaves the agent without context for tool selection.

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

mcp_aftereffects_applyEffectTemplateC

Apply a predefined effect template to a layer in After Effects

ParametersJSON Schema

Name	Required	Description
`compIndex`	Yes	1-based index of the target composition in the project panel.
`layerIndex`	Yes	1-based index of the target layer within the composition.
`templateName`	Yes	Name of the effect template to apply.
`customSettings`	No	Optional custom settings to override defaults.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations present, so description must disclose behavior. It only states the basic action, omitting details such as whether effects are replaced or appended, or what happens to existing effects.

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

Conciseness4/5

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

Single sentence, no redundancy. Could be slightly expanded for clarity, but efficient for its length.

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

Completeness2/5

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

With no output schema, annotations, or behavioral details, the description leaves gaps. Fails to help an AI understand template effects or when to use this over sibling tools like 'apply-effect'.

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%, so parameters are already documented. Description adds no further explanation, e.g., for 'customSettings' or template behavior. Baseline 3 applies.

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

Purpose4/5

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

Description clearly states action (apply), resource (effect template), and target (layer). Differentiates from sibling 'mcp_aftereffects_applyEffect' by specifying 'template', but does not explicitly contrast.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'apply-effect' or 'apply-effect-template'. No prerequisites, when-not, or context provided.

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

mcp_aftereffects_get_effects_helpB

Get help on using After Effects effects

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It only states it gets help but does not disclose what kind of help (e.g., documentation, examples, error messages) or whether it is read-only. The behavior is minimally transparent.

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

Conciseness5/5

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

The description is a single concise sentence with no unnecessary words. It is appropriately front-loaded and efficient.

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

Completeness3/5

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

Given the absence of parameters and output schema, the description provides the basic purpose. However, it lacks information about the type of help returned and how to use the tool in context. It is adequate but not rich.

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

Parameters4/5

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

There are no parameters, so schema coverage is 100% by default. According to the baseline rule for 0 params, a score of 4 is appropriate. The description adds no parameter semantics.

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

Purpose4/5

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

The description clearly states the tool gets help on After Effects effects. It is a specific verb-resource pairing. However, it does not differentiate from the sibling 'get-help' tool, which may be more generic.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'get-help' or 'get-results'. There is no mention of use cases or exclusions.

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

run-bridge-testA

Run the bridge test effects script to verify communication and apply test effects

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

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 states 'verify communication and apply test effects' but does not explain side effects, whether it is destructive, what changes occur, or any prerequisites. This is insufficient for a tool with no annotations.

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

Conciseness5/5

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

The description is a single concise sentence with no wasted words. Every part adds value: it names the action, the resource, and the purpose.

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

Completeness3/5

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

Given the tool has no parameters and no output schema, the description covers the basic purpose. However, without annotations, more context about expected outcomes or usage scenarios would improve completeness.

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

Parameters4/5

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

There are no parameters, so schema coverage is 100%. The description correctly provides no parameter info since none exist. With zero parameters, baseline is 4.

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 specific verb 'run' and resource 'bridge test effects script', and states the purpose: 'verify communication and apply test effects'. This clearly distinguishes it from sibling tools like apply-effect or run-script.

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 using the tool to verify communication and apply test effects, but provides no explicit guidance on when to use it versus alternatives (e.g., run-script, apply-effect). No exclusions or context are given.

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

run-scriptC

Run a read-only script in After Effects

ParametersJSON Schema

Name	Required	Description	Default
`script`	Yes	Name of the predefined script to run
`parameters`	No	Optional parameters for the script

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It states 'read-only', indicating non-destructive behavior, but fails to mention error handling, return values, or side effects beyond mutation.

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

Conciseness4/5

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

The description is a single sentence, front-loading the key action and scope. It is appropriately concise, though it could be slightly more informative without sacrificing brevity.

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

Completeness2/5

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

Given the lack of output schema and the presence of a nested object parameter, the description does not explain what happens after running the script (e.g., output, errors). Essential context about the script's behavior and return values is missing.

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

Parameters3/5

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

The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional meaning beyond the schema's 'Name of the predefined script to run' and 'Optional parameters'. The 'read-only' qualifier might imply no side effects but does not enhance parameter understanding.

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

Purpose4/5

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

The description clearly states the verb 'run', the resource 'script', and the domain 'After Effects', and adds the qualifier 'read-only', which distinguishes it from sibling tools that apply effects or create compositions. However, it does not specify what types of scripts are available or their purpose.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like apply-effect or setLayerExpression. The description does not provide any context about the tool's scope or limitations.

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

setLayerExpressionB

Set or remove an expression for a specific layer property.

ParametersJSON Schema

Name	Required	Description
`compIndex`	Yes	1-based index of the target composition in the project panel.
`layerIndex`	Yes	1-based index of the target layer within the composition.
`propertyName`	Yes	Name of the property to apply the expression to (e.g., 'Position', 'Scale', 'Rotation', 'Opacity').
`expressionString`	Yes	The JavaScript expression string. Provide an empty string ("") to remove the expression.

TDQS

B3.1/5.0

Behavior2/5

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

The description states 'Set or remove', indicating mutation, but does not disclose side effects (e.g., overwriting existing expressions), authorization needs, or any limitations. With no annotations, the description carries the full burden of behavioral disclosure but falls short.

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

Conciseness4/5

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

The description is a single efficient sentence with no waste. However, it could be slightly restructured to front-load the most critical info (e.g., that an empty expressionString removes the expression), which is already in the schema.

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

Completeness2/5

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

With no output schema and no annotations, the description is incomplete. It does not explain return behavior, error conditions, or how this tool relates to siblings like setLayerKeyframe. For a 4-parameter mutation tool, more context is needed.

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

Parameters3/5

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

Schema description coverage is 100% (all 4 parameters have individual descriptions). The tool description adds no extra meaning 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/5

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

The description uses a specific verb 'Set or remove' and identifies the resource as 'an expression for a specific layer property'. It clearly distinguishes from sibling tools like setLayerKeyframe (keyframes) and apply-effect (effects), as expressions are a distinct concept.

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 (e.g., setLayerKeyframe for keyframes, apply-effect for effects). There is no mention of prerequisites, such as ensuring the layer exists or the property supports expressions.

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

setLayerKeyframeB

Set a keyframe for a specific layer property at a given time.

ParametersJSON Schema

Name	Required	Description
`value`	No	The value for the keyframe (e.g., [x,y] for Position, [w,h] for Scale, angle for Rotation, percentage for Opacity)
`compIndex`	Yes	1-based index of the target composition in the project panel.
`layerIndex`	Yes	1-based index of the target layer within the composition.
`propertyName`	Yes	Name of the property to keyframe (e.g., 'Position', 'Scale', 'Rotation', 'Opacity').
`timeInSeconds`	Yes	The time (in seconds) for the keyframe.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits such as whether it overwrites existing keyframes, whether it is destructive, or any side effects. The minimal description leaves ambiguity about its behavior.

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

Conciseness4/5

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

The description is a single, clear sentence. It is concise and front-loaded with the key action. However, it could be slightly more structured to improve readability.

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

Completeness3/5

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

Given the lack of output schema and the tool's role in animation, the description does not explain keyframe behavior, return values, or prerequisites. It covers the basics but leaves gaps for an AI agent to understand the full context.

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

Parameters3/5

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

Schema coverage is 100%, so the schema documents all parameters. The description adds value for the 'value' parameter by providing examples of expected formats (e.g., [x,y] for Position). However, it does not add meaning to other parameters beyond the schema.

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

Purpose5/5

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

The description clearly states the action ('Set a keyframe'), the target ('specific layer property'), and the context ('at a given time'). It distinguishes itself from sibling tools like setLayerExpression and 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?

No guidance is provided on when to use this tool versus alternatives (e.g., setLayerExpression). The description does not mention prerequisites, typical use cases, or when not to use it.

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

test-animationC

Test animation functionality in After Effects

ParametersJSON Schema

Name	Required	Description
`compIndex`	Yes	Composition index (usually 1)
`operation`	Yes	The animation operation to test
`layerIndex`	Yes	Layer index (usually 1)

TDQS

C2.2/5.0

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 does not disclose whether the tool is read-only, modifies state, requires specific permissions, or has side effects. 'Test' could imply a dry run but is ambiguous.

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

Conciseness2/5

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

Description is very short (5 words) but at the expense of necessary clarity. Every sentence should earn its place; here it fails to convey critical information.

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

Completeness2/5

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

Given no output schema, no annotations, and a generic description, the definition is incomplete. It does not explain what 'testing' entails, what the tool returns, or how to interpret results.

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 each parameter having a description. The tool description adds no extra semantics, but the schema itself is clear. Baseline 3 is appropriate.

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

Purpose2/5

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

Description states 'Test animation functionality' but the verb 'test' is generic and does not specify what exactly it does (e.g., validate, dry-run, preview). It fails to distinguish from sibling tools like setLayerKeyframe and setLayerExpression which actually modify 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/5

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

No guidance on when to use this tool vs alternatives. Sibling tools exist for setting keyframes and expressions, but the description does not indicate under what circumstances 'test' is appropriate.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0

Disambiguation2/5

Several tools have overlapping purposes and names, e.g., apply-effect and mcp_aftereffects_applyEffect have identical descriptions, causing ambiguity. The presence of both generic help (get-help) and specific help (mcp_aftereffects_get_effects_help) further blurs distinctions.

Naming Consistency2/5

Naming conventions are mixed: some tools use snake_case with hyphens (e.g., apply-effect), others use camelCase (setLayerExpression), and some have a redundant mcp_aftereffects_ prefix. This lack of a consistent pattern makes the tool set harder to navigate.

Tool Count4/5

With 13 tools, the count is reasonable for an After Effects MCP server. However, the presence of duplicate tools (e.g., apply-effect and mcp_aftereffects_applyEffect) inflates the count unnecessarily, suggesting some redundancy.

Completeness4/5

The tool set covers core After Effects workflows: creating compositions, applying effects, setting keyframes and expressions, running scripts. Minor gaps exist (e.g., no import/export or deletion tools), but overall the surface is fairly complete for typical automation tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

After Effects MCP
io.oneprism
An MCP connector for Adobe After Effects. Real, editable layers and keyframes, not scripts.
Multimedia Processing Design Tools
1
StoryStudio
io.github.HelloElo-Fr
AI image, video, voice and music generation over MCP, routed to Veo 3.1, Seedance 2.0 and more.
AI & Machine Learning Image & Video Processing Audio Processing
1
ViewMax MCP A
io.github.bytevirts
Remote MCP for AI video, image, music and speech generation.
Audio Processing Image & Video Processing Speech Processing
141
MaxVideoAI
com.maxvideoai
Plan, compare, price, generate, and recover AI video from compatible MCP clients.
AI & Machine Learning Image & Video Processing
1

Related MCP Servers

After Effects MCP Server
Design Tools Multimedia Processing
TheLlamainator
A
license
C
quality
D
maintenance
Enables AI assistants to control Adobe After Effects for composition, layer, effect, preset, marker, and audio automation through a bridge panel.
Updated 6 months ago (2026-03-15 10:05 UTC)
30
84
16
MIT
After Effects MCP Server
Design Tools Image & Video Processing
brandkickagency
A
license
A
quality
D
maintenance
Enables AI assistants to control Adobe After Effects through a WebSocket-based CEP panel, supporting composition, layer, animation, effects, and render operations.
Updated 7 months ago (2026-02-03 13:09 UTC)
10
84
3
MIT
after-effects-mcp
SheinbergStudio-Dev
-
license
Not graded
quality
Not graded
maintenance
Enables AI assistants to control Adobe After Effects through a standardized MCP protocol, providing tools for composition creation, layer management, and animation.
Updated 5 months ago (2026-04-01 03:23 UTC)
mcp-ae
Multimedia Processing Image & Video Processing Design Tools
shibin0
F
license
Not graded
quality
D
maintenance
Enables control of Adobe After Effects via natural language, allowing project manipulation, layer creation, animation, and rendering through MCP.
Updated 6 months ago (2026-02-25 10:34 UTC)

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/rtx1025189518-source/MCP'

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

🎬 After Effects MCP Server

Table of Contents

📦 Features

🎥 Core Composition Features

🧱 Layer Management

🌀 Animation Capabilities

⚙️ Setup Instructions

🛠 Prerequisites

📥 Installation

🔧 Update MCP Config

Option 1: Using .mcp.json (Recommended for Claude Code)

Option 2: Manual Configuration

▶️ Running the Server

🚀 Usage Guide

📘 Creating Compositions

✍️ Working with Layers

🕹 Animation

🛠 Available MCP Tools

👨‍💻 For Developers

🧩 Project Structure

📦 Building the Project

🤝 Contributing

Star History

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API