Skip to main content
Glama
shinjiyu

ae-meta-mcp

by shinjiyu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

ae-meta-mcp

Lightweight After Effects MCP: a Cursor Agent runs ExtendScript inside a running After Effects via a single ae_exec tool — same mental model as Blender MCP (execute_blender_code) and CocosMetaMCP (cocosmcp_exec).

Cursor Agent  ──stdio MCP──▶  Node MCP server  ──HTTP :11488──▶  CEP panel (Express-free)  ──evalScript──▶  AE 2024

Tools (MVP)

Tool

Description

ae_health

Check the bridge is reachable; returns AE version + project info

ae_exec

Run arbitrary ExtendScript (ES3), returns JSON

ae_scene_info

Summarize project / comps / active comp layers

Related MCP server: After Effects MCP Custom

Requirements

  • Windows 10/11

  • After Effects 2024 (24.x), CEP 11

  • Node.js >= 18

Install (Windows)

cd D:\workspace\ae_meta_mcp
npm install

# 1. Enable unsigned CEP extensions (PlayerDebugMode)
.\scripts\enable-debug-mode.ps1

# 2. Copy the panel into the CEP extensions folder
.\scripts\install-cep.ps1

# 3. Restart After Effects, then: Window -> Extensions -> ae-meta-mcp (keep it open)

In AE: Edit → Preferences → Scripting & Expressions → check Allow Scripts to Write Files and Access Network.

Wire up Cursor

Generate a snippet for your checkout:

npm run setup:cursor

Paste it into ~/.cursor/mcp.json (or project .cursor/mcp.json), then toggle ae-meta-mcp off/on in Cursor's MCP settings. See examples/cursor-mcp.json.

Verify

  1. ae_health → { ok: true, aeVersion: "24.x" }

  2. ae_exec create a comp:

    var c = app.project.items.addComp("MCP Test", 1920, 1080, 1, 10, 30);
({ name: c.name, width: c.width, height: c.height })

  3. ae_scene_info → list includes MCP Test

  4. Close the panel, run ae_exec again → bridge-unreachable error

Writing ExtendScript

ae_exec runs ES3 (no let/const, arrow functions, template literals, etc.). See skills/ae-extendscript/SKILL.md for constraints, the object model, and recipes.

Layout

mcp/      Node stdio MCP server (index, core, context, bridge-client)
plugin/   CEP panel (manifest, client UI, Node http host, jsx)
scripts/  install-cep.ps1, enable-debug-mode.ps1, setup-cursor.mjs
skills/   ae-extendscript agent skill
examples/ cursor-mcp.json
docs/     DEV.md (design doc)

Troubleshooting

Symptom

Fix

No ae-meta-mcp under Extensions

Run enable-debug-mode.ps1; check manifest HostList; restart AE

/health connection refused

Panel not open; port in use

EvalScript error

Script isn't ES3; test via File → Scripts → Run Script File

Empty result

Last line must be an expression or return

Write-file fails

Enable "Allow Scripts to Write Files and Access Network"

MCP tool not found

Reload MCP in Cursor; check the args path

Security

The bridge binds 127.0.0.1 only. ae_exec is full local control of AE — use for local development only.

License

MIT

Available Tools

3 tools
ae_execA

Execute arbitrary ExtendScript inside the running After Effects (like Blender's execute_blender_code / Cocos cocosmcp_exec). The script runs in AE's ES3 engine. Constraints:

  • NO let/const (use var)

  • NO arrow functions (use function(){})

  • NO template literals (use string concatenation)

  • NO for..of / async / await / class The last expression (or a 'return') is serialized to JSON and returned. Example: app.project.activeItem ? app.project.activeItem.name : null

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesExtendScript (ES3) expression or IIFE body.

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the runtime environment (ES3), constraints on JavaScript features, and the return serialization behavior. It does not cover error handling or side effects, but is otherwise transparent.

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

Conciseness4/5

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

The description is well-structured with bullet points for constraints and an example, making it easy to parse. It is slightly verbose but every sentence adds value, and the format aids readability.

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 complexity of a code execution tool and only one parameter, the description is fairly complete. It covers the execution environment, constraints, return format, and provides an example. Missing details about error handling or response format do not significantly hinder understanding.

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

Parameters4/5

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

Schema coverage is 100%, and the description adds significant meaning beyond the schema: it explains the parameter 'code' is ExtendScript/ES3, describes constraints, and gives an example. This adds value beyond the schema's simple string type.

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 executes arbitrary ExtendScript in After Effects, with a specific verb ('Execute') and resource ('ExtendScript inside After Effects'). It distinguishes itself from siblings by comparing to similar tools and providing constraints and an example.

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 usage, including the ES3 engine and constraints, but does not explicitly compare to siblings ae_health or ae_scene_info. However, the nature of the tool (code execution) is distinct enough that guidelines are implied.

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

ae_healthA

Check whether the After Effects CEP bridge is reachable; returns AE version and project info.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states that the tool checks reachability and returns version/project info, but does not disclose what happens on failure (e.g., error message, exception), whether side effects exist, or prerequisite conditions (e.g., After Effects must be open).

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, well-formed sentence that front-loads the action and the return value. No extraneous words.

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 simple nature of a health check with no parameters, the description provides the key outputs (AE version, project info). However, it could specify the return structure (e.g., object with fields) for 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 schema has zero parameters with 100% coverage, meeting the baseline of 4. The description adds no extra parameter meaning since none exist, but the purpose is clear.

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 explicitly states 'Check whether the After Effects CEP bridge is reachable' with a specific verb and resource, and distinguishes from siblings like 'ae_exec' (execute commands) and 'ae_scene_info' (scene info) by focusing on connectivity health.

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 implies usage as a precondition (e.g., before other operations), but does not explicitly state when to use or not use this tool versus alternatives. However, for a health check, the context is clear.

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

ae_scene_infoA

Summarize the AE project: compositions, active comp and its layers (like Blender get_scene_info).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior2/5

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

No annotations exist, so description must fully disclose behavior. It only states 'summarize' without detailing side effects, permissions, or return value format. Incomplete for a tool with zero 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?

Single, focused sentence that efficiently conveys purpose and includes a helpful analogy. No wasted words.

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 no parameters, no output schema, and a straightforward purpose, the description covers necessary information. Could mention that it's read-only or highlight key return fields, but acceptable for a simple tool.

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, so schema coverage is 100% trivially. Description adds no param info, but the baseline for zero-param tools 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 action (summarize) and the resource (AE project: compositions, active comp, layers). The Blender reference adds context, making it 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?

No explicit when-to-use guidance or alternative distinctions provided. Sibling tools ae_exec and ae_health are not compared. The purpose is implied but not formalized.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedae_exec
    • First observedae_health
    • First observedae_scene_info
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: ae_exec executes arbitrary scripts, ae_health checks connectivity, and ae_scene_info summarizes the project. No overlap or ambiguity.

Naming Consistency4/5

All tools follow a consistent 'ae_' prefix with descriptive names (exec, health, scene_info). While not all verb_noun, the pattern is predictable and clear.

Tool Count4/5

Three tools is minimal but appropriate for a focused scripting server. Each tool serves a distinct core function without being overly thin.

Completeness4/5

The server covers the essential operations: code execution, connectivity check, and project overview. Minor gaps like direct composition manipulation exist, but the set is complete for its stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers