Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ae-mcp-server create a comp called Main, add a text layer, and fade it in over 2 seconds"
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.
Adobe After Effects を AI アシスタント(Claude Desktop / Claude Code など)から操作するための MCP サーバーです。 An MCP server that lets AI assistants control Adobe After Effects through ExtendScript.
MCP クライアントがツールを呼び出す
サーバーが ExtendScript (JSX) を一時ファイルとして生成
macOS は osascript(DoScript)、Windows は AfterFX.exe -r で起動中の After Effects に実行させる
JSX が結果を JSON ファイルに書き出し、サーバーがそれを読んで MCP クライアントに返す
After Effects は同時に1つのスクリプトしか実行できないため、呼び出しは内部でキューに積まれます。
Related MCP server: After Effects MCP
After Effects(macOS / Windows)
Node.js 18 以上
After Effects の設定 環境設定 > スクリプトとエクスプレッション > 「スクリプトによるファイルの書き込みとネットワークへのアクセスを許可」 をオン (結果ファイルの書き出しに必要です)
git clone https://github.com/<your-name>/ae-mcp-server.git
cd ae-mcp-server
npm install
npm run buildclaude mcp add after-effects -- node /absolute/path/to/ae-mcp-server/dist/index.jsclaude_desktop_config.json){
"mcpServers": {
"after-effects": {
"command": "node",
"args": ["/absolute/path/to/ae-mcp-server/dist/index.js"]
}
}
}変数 | 説明 |
| (macOS) 対象アプリ名。例: |
| (Windows) |
| 1回のスクリプト実行の待機上限(ミリ秒、既定 60000) |
ツール | 内容 |
| AE バージョン、プロジェクトパス、アイテム一覧 |
| コンポジション一覧 |
| コンポジション作成 |
| レイヤー一覧 |
| テキストレイヤー追加 |
| 平面レイヤー追加 |
| 矩形 / 楕円のシェイプレイヤー追加 |
| 位置・スケール・回転・不透明度の設定( |
| エフェクト追加とプロパティ設定 |
| ファイルのインポート(コンポへの追加も可) |
| レンダーキューに追加してレンダリング |
| 保存 / 名前を付けて保存 |
| 任意の ExtendScript を実行(関数本体として評価され、 |
ae_run_jsx の例:
// code
var comp = __findComp(args.comp);
return { name: comp.name, layers: comp.numLayers };
// args
{ "comp": "Main" }ExtendScript は ES3 です(let / const / JSON / Array.prototype.forEach などは使えません)。
レイヤーの追加や変更は1つのアンドゥグループにまとめられるので、After Effects 側で一度 Undo すれば戻せます。
ae_run_jsx は任意のコードを実行できます。信頼できる MCP クライアントからのみ使ってください。
スクリプト実行中に After Effects でダイアログが開いていると、タイムアウトします。
ae_render は完了までブロックします(既定の待機上限は1時間)。
MIT
Add an effect to a layer by match name (e.g. 'ADBE Gaussian Blur 2') and optionally set its properties by name or index.
| Name | Required | Description | Default |
|---|---|---|---|
| comp | No | Composition name or id. Omit to use the active composition. | |
| layer | Yes | Layer name, or 1-based layer index. | |
| properties | No | Map of effect property name (or index as string) to value. | |
| effectMatchName | Yes | Effect match name, e.g. 'ADBE Gaussian Blur 2'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden and falls short. For a mutation tool it never says what happens if the match name is not found, whether the effect is appended to the existing stack, whether the operation is undoable, or what the call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler that states the action, the key parameter, and the optional property-setting behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 the only source of behavioral context, and it omits the return value, error cases, and effect-stack ordering. It is adequate for the happy path but leaves an agent guessing about failure behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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's references to match name, name-vs-index property keys, and the optional property map largely restate what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource combination ('Add an effect to a layer') and states the key identifying input (match name) with a concrete example. It is clearly distinct from the layer-creation and transform siblings, though it never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: you need a comp and a target layer, and comp may be omitted to use the active one. There is no explicit when-to-use/when-not guidance, no mention of prerequisites such as the comp being open, and no named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a shape layer containing a filled rectangle or ellipse.
| Name | Required | Description | Default |
|---|---|---|---|
| comp | No | Composition name or id. Omit to use the active composition. | |
| name | No | ||
| size | No | [width, height] in pixels. | |
| shape | No | rectangle | |
| position | No | [x, y] in pixels. Defaults to comp center. | |
| fillColor | No | RGB color, each channel 0-1, e.g. [1, 0.5, 0]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It omits that this is a mutating write operation, where the new layer is inserted in the stack, what happens if the named comp is missing, or whether the project must be saved afterward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It is efficient, though the extreme brevity is arguably under-specification rather than disciplined conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter mutation tool with no annotations and no output schema, one sentence is not enough. An agent lacks confirmation of write semantics, comp targeting default, layer placement, and any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, so the schema already documents size, position, and fillColor. The description adds only that the shape is 'filled' and that the shape is either a rectangle or ellipse, restating enum values already in the schema, and says nothing about the undocumented name parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (add) and resource (shape layer) plus the payload (a filled rectangle or ellipse), which cleanly separates it from the layer-creating siblings ae_add_text_layer and ae_add_solid_layer. It does not, however, spell out the distinction between this and ae_add_solid_layer for an agent new to the toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative guidance. The description never mentions prerequisites such as needing a target composition or that the comp parameter can be omitted to fall back to the active composition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a solid layer to a composition. Defaults to the full composition size.
| Name | Required | Description | Default |
|---|---|---|---|
| comp | No | Composition name or id. Omit to use the active composition. | |
| name | No | Solid | |
| color | No | RGB color, each channel 0-1, e.g. [1, 0.5, 0]. | |
| width | No | ||
| height | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses one trait beyond the schema: omitting dimensions defaults to full composition size. But it omits where the layer is inserted in the stack, what the call returns (a new layer id/index), and any permission or project-state requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with zero filler. The primary action comes first and the default-behavior note follows, which is the right ordering.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter, zero-annotation, no-output-schema tool, the description is too thin. It omits return value, layer placement, and the interaction between omitted width/height and the active composition, leaving meaningful gaps for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, so the schema documents comp and color but leaves name, width, and height undocumented. The description partially compensates by explaining the width/height default ('full composition size'), but says nothing about the name parameter or color semantics beyond the schema's own note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb+resource: 'Add a solid layer to a composition.' The term 'solid layer' implicitly distinguishes it from the sibling ae_add_text_layer and ae_add_shape_layer. However, it never explicitly contrasts with those siblings, keeping it below the top tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use vs when-not guidance. It does not state prerequisites such as whether an active composition must exist, nor does it route the agent away from ae_add_text_layer / ae_add_shape_layer for non-solid layers. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a text layer to a composition.
| Name | Required | Description | Default |
|---|---|---|---|
| comp | No | Composition name or id. Omit to use the active composition. | |
| font | No | PostScript font name, e.g. 'ArialMT'. | |
| name | No | Layer name (defaults to the text). | |
| text | Yes | Text content. | |
| fontSize | No | ||
| position | No | [x, y] in pixels. Defaults to comp center. | |
| fillColor | No | RGB color, each channel 0-1, e.g. [1, 0.5, 0]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. 'Add' implies a mutation to project state, but the description says nothing about whether the composition must exist, whether the layer is undoable, what happens on invalid font names, or what the call returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero waste. It is efficient, though its brevity borders on under-specification rather than genuine conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 7-parameter mutation tool with no annotations and no output schema, yet the description is one generic sentence. It omits mutation semantics, project/composition preconditions, and default behaviors the agent needs to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the schema already documents comp, font, name, text, position, and fillColor in detail. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (add) and resource (text layer) applied to a composition. The 'text layer' resource naturally distinguishes it from siblings such as ae_add_solid_layer and ae_add_shape_layer, though it does not name those alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 ae_add_solid_layer, ae_add_shape_layer, or ae_run_jsx for text creation. No prerequisites (e.g. requiring an open project or active composition) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new composition and make it the active item in the viewer.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Composition name. | |
| width | No | ||
| height | No | ||
| duration | No | Duration in seconds. | |
| frameRate | No | ||
| pixelAspect | No |
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 usefully discloses a non-obvious side effect — the new composition becomes the active item in the viewer — which goes beyond the tool name. However it says nothing about which project receives the composition, name-collision behavior, required permissions, or failure modes, leaving major behavioral gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the core action front-loaded and no filler. Every clause earns its place, including the viewer-activation detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter creation tool with no annotations and no output schema, one sentence is insufficient. Missing are creation target (active project), default-value expectations beyond the schema, name uniqueness behavior, and any indication of what the tool returns to identify the new composition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (name and duration described; width, height, frameRate, pixelAspect undocumented). The description contributes zero parameter information and does not compensate for the coverage gap, so an agent must guess at frameRate units, pixelAspect meaning, and dimension constraints from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a new composition') and even adds a scope detail (becomes the active item in the viewer). It is clearly distinguishable from read-side siblings like ae_list_compositions, though it does not explicitly name or route against any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use context, no prerequisites, and no mention of alternatives such as ae_list_compositions or the layer-adding tools that would typically follow composition creation. Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current After Effects version, project file path, and a list of all project items.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the return contents (version, path, item list), which substitutes for the missing output schema, but says nothing about whether the call is read-only, has side effects, or requires a loaded project.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One declarative sentence with no filler, front-loading the verb and resource. Every clause earns its place by naming a distinct return field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-arg read tool with no output schema, the description supplies the essential return shape (version, path, items). It is nearly complete, missing only the read-only/no-side-effect reassurance an agent might want before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is empty, so there is nothing to document; baseline 4 applies. The description correctly avoids inventing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return') and resource ('project info') and enumerates the exact contents: AE version, project file path, and all project items. This distinguishes it from narrower siblings like ae_list_compositions and ae_list_layers, though it never names those alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no exclusions, and no mention of when to prefer this over ae_list_compositions or ae_list_layers. The word 'current' is the only contextual cue, so usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a footage/image/audio file into the project, optionally adding it to a composition as a layer.
| Name | Required | Description | Default |
|---|---|---|---|
| comp | No | Composition name or id. Omit to use the active composition. | |
| path | Yes | Absolute path to the file on the machine running After Effects. | |
| addToComp | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It says what is imported but not whether the file is linked or copied, whether re-importing duplicates existing footage, what happens on unsupported formats, or what the call returns (no output schema). For a mutating import tool this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the core action first and the optional behavior trailing. No wasted words and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 3-parameter tool, but with no annotations and no output schema the description leaves the success result and failure modes unstated. An agent can call it, but cannot predict what it gets back or how failures surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: 'comp' is well documented and 'path' has a note about the AE host machine. The description supplies the missing meaning for the undocumented 'addToComp' flag by explaining the optional add-as-layer behavior, so it adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Import a footage/image/audio file into the project') and clarifies the optional layer creation, which distinguishes it from the generated-layer siblings like ae_add_text_layer and ae_add_solid_layer. It stops short of explicitly naming alternatives, so it is clear rather than fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'optionally adding it to a composition as a layer' clause implies when addToComp should be used, and the trailing parameter description builds on it. There is no explicit when-to-use guidance versus siblings or prerequisites (e.g., that the path must be reachable by the After Effects host).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all compositions in the project with size, duration and frame rate.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden; it partially does so by naming the returned fields, which implies a read-only enumeration with no side effects. However, it says nothing about pagination, permissions, or whether large projects are truncated, so the behavioral picture is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that states the action, scope and output fields with no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-annotation tool with no output schema, the one-line description covers purpose and the main return fields. It would be stronger if it mentioned composition names/IDs, which an agent likely needs to chain into other tools, but nothing critical is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case; there is nothing in the input schema to clarify or contradict. No parameter detail is needed or missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource (list compositions) with explicit scope ('in the project') and the fields returned (size, duration, frame rate). It is unmistakably distinct from siblings like ae_create_composition or ae_list_layers without needing their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the way to enumerate compositions, but the description names no alternative, no prerequisite, and no condition for choosing it over ae_get_project_info or ae_list_layers. Minimum-viable guidance for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the layers of a composition.
| Name | Required | Description | Default |
|---|---|---|---|
| comp | No | Composition name or id. Omit to use the active composition. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and adds almost nothing: it doesn't say whether the operation is safe/read-only (only implied by 'List'), whether it returns nested/precomp layers, layer ordering, or the shape of each layer entry. For a listing tool this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. It is efficient, though the brevity comes at the cost of the missing context addressed elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool this is roughly adequate, but with no output schema the description should have hinted at what a 'layer' entry contains (name, id, type, index) so an agent can chain results into ae_set_layer_transform or ae_add_effect. It is minimum viable, not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'comp' parameter is fully documented as a name-or-id with an active-composition fallback. The description adds no parameter detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (layers of a composition), so an agent immediately knows what it does. It does not distinguish itself from siblings like ae_list_compositions or explain how it relates to the add_*_layer tools, which is the only gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to call this versus alternatives, no prerequisites, and no note on whether it should be used before mutation tools such as ae_set_layer_transform or ae_add_effect. The only usage hint is implied by the phrase 'of a composition'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a composition to the render queue and optionally render it. Blocks until rendering finishes.
| Name | Required | Description | Default |
|---|---|---|---|
| comp | No | Composition name or id. Omit to use the active composition. | |
| render | No | false = only queue the item. | |
| timeoutMs | No | Max wait in ms (default 1 hour for render). | |
| outputPath | Yes | Absolute output file path. | |
| outputModuleTemplate | No | e.g. 'Lossless', 'H.264 - Match Render Settings - 15 Mbps' (if available). | |
| renderSettingsTemplate | No | e.g. 'Best Settings'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that it blocks until rendering finishes, which is important behavioral context. However, it doesn't cover side effects like file creation, potential failures, permissions required, or what happens if queued without rendering. The blocking behavior is a key disclosure but incomplete coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the action and include the blocking behavior. No wasted words, very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is quite sparse. It covers the blocking behavior but leaves out important context such as potential side effects (file writes), error handling, and how the render flag interacts with other parameters. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter details beyond what the schema provides. Baseline 3 is appropriate when schema does all the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (add/render) and resource (composition/render queue). It does distinguish itself from siblings like ae_list_compositions or ae_create_composition, but does not explicitly mention them. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides some implied usage: adding to queue and optionally rendering, and it blocks. However, there's no explicit guidance on when to use this tool versus other render-related tools, or when to use the render flag. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run arbitrary ExtendScript (ES3) inside After Effects. The code is the BODY of a function: use return to send a JSON-serializable value back, and read inputs from args. Helpers available: __findComp(ref), __findLayer(comp, ref), __layerInfo(layer). Example: return app.project.numItems;
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Value exposed to the script as `args`. | |
| code | Yes | ExtendScript function body. | |
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the ES3 dialect, that code runs as a function body, that `return` yields a JSON-serializable value, that inputs arrive via `args`, and which helpers exist. It omits error/failure behavior and the timeout default, which matters for long-running or failing scripts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core purpose, then the contract, then a concrete example. No filler; every clause conveys information needed to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-output-schema, no-annotation code-execution tool, the description covers the calling contract (function body, args, return) and helper surface. The main gap is timeoutMs semantics and error surfacing, which an agent would want before running a heavy script.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (args and code documented, timeoutMs not). The description goes beyond the schema by explaining how `args` is exposed and what `return` does, which is essential to writing correct code. It adds no meaning for timeoutMs, keeping it short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: run arbitrary ExtendScript inside After Effects. It is clearly the generic escape-hatch tool, distinguishable at a glance from the specific sibling operations (ae_add_text_layer, ae_render, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the tool's generic nature; there is no explicit guidance on when to prefer this over the specific sibling tools, nor any preconditions (e.g., project must be open). An agent must infer the routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the current project. Provide 'path' to Save As (.aep).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Absolute .aep path for Save As. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It indicates Save As behavior when a path is provided, but omits important traits such as whether it overwrites an existing file, what happens when saving an unsaved project without a path, required permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and then the conditional Save As detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, and the description covers how to invoke Save As. However, it lacks key behavioral context about file writing, overwrite behavior, and failure modes, which an agent would need for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully documented in the schema as 'Absolute .aep path for Save As.' The description's mention of 'path' to Save As adds no meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Save') and resource ('current project'), and clearly differentiates Save from Save As by noting that providing 'path' triggers Save As. No sibling tool shares this exact resource, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies the condition for Save As ('Provide path') versus the default Save behavior, giving clear context for invocation. However, it does not discuss alternatives or exclusions, though no close sibling alternative exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set transform properties of a layer. If 'time' is given, keyframes are set at that time (seconds) instead of static values.
| Name | Required | Description | Default |
|---|---|---|---|
| comp | No | Composition name or id. Omit to use the active composition. | |
| time | No | Time in seconds; creates a keyframe. | |
| layer | Yes | Layer name, or 1-based layer index. | |
| scale | No | Percent, e.g. [100, 100]. | |
| opacity | No | ||
| position | No | ||
| rotation | No | Degrees. | |
| anchorPoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the keyframe-vs-static branch triggered by 'time', which is real behavior beyond the schema. It does not say whether omitted properties are left untouched or reset, whether existing keyframes are overwritten, or what permissions/undo semantics apply to this mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and followed immediately by the one non-obvious behavior. Nothing is padded or redundant, though the brevity borders on under-specification for an 8-parameter mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter write tool with zero annotations and no output schema, the description leaves key gaps: whether unspecified properties remain unchanged, whether values are absolute or relative, and what the effect on existing keyframes is. The schema enforces additionalProperties=false but the description does not help the agent reason about partial updates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%, with comp, time, layer, scale and rotation documented but opacity, position and anchorPoint left bare. The description adds the consequence of 'time' (creates a keyframe rather than a static value), which enriches that parameter, but contributes no meaning for the three undocumented transform parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Set transform properties of a layer.' This is clearly distinct from the add_*/list_*/render siblings, none of which mutate transform values. It stops short of enumerating which transform properties (position, scale, rotation, opacity, anchorPoint), leaving the agent to open the schema for the full picture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence about 'time' explains a conditional behavior (keyframe vs. static) but frames it as mechanics rather than when-to-use guidance. There is no statement about which situations call for this tool, no prerequisite for an active/selected composition, and no note that at least one transform property should accompany 'layer'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0ae_add_effectae_add_shape_layerae_add_solid_layerae_add_text_layerae_create_compositionae_get_project_infoae_import_fileae_list_compositionsae_list_layersae_renderae_run_jsxae_save_projectae_set_layer_transformScored across 13 tools
Most tools target distinct resources and actions (comps, layers, effects, render, import), and the three add_*_layer variants are differentiated by layer type. The main overlap is ae_run_jsx, a catch-all escape hatch that can technically duplicate any other tool's job, though it is clearly framed as a last resort.
Every tool uses a consistent ae_ prefix followed by a snake_case verb_noun pattern (ae_get_project_info, ae_add_text_layer, ae_set_layer_transform). No mixing of conventions or verb styles.
13 tools is well within the ideal range and each maps to a meaningful After Effects operation (project inspection, comp/layer creation, transforms, effects, import, render, save). No filler or redundant tools.
Core lifecycle is covered: inspect, create comps/layers, transform, add effects, import, render, and save. Gaps exist for destructive operations (delete/remove layer or composition) and per-layer property edits, but ae_run_jsx provides a general-purpose escape hatch that lets an agent work around them.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
MCP server for Hailuo (MiniMax) AI video generation
Official faktry MCP server: generate and edit images, video, audio, and PDFs.
