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., "@After Effects MCP create a 1080p composition and add a text layer"
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.
Servidor MCP local para controlar Adobe After Effects desde OpenCode, Claude Desktop, Claude Code, ChatGPT Desktop con Codex, Codex CLI, Cursor y otros clientes compatibles con Model Context Protocol.
Permite inspeccionar proyectos, crear composiciones, agregar capas, importar
archivos, ejecutar ExtendScript y renderizar con aerender. Funciona por
stdio, no abre puertos de red y procesa las operaciones JSX en serie.
Repositorio: https://github.com/leo10m2010/mcp-after
Lee AGENTS.md y docs/CLIENTS.md. Detecta el
cliente del usuario, aplica solo la configuracion correspondiente, conserva su
configuracion existente y verifica la conexion antes de modificar After Effects.
Prompt que un usuario puede entregar a otra IA:
Instala y configura este MCP de After Effects para el cliente que estoy usando:
https://github.com/leo10m2010/mcp-after
Sigue AGENTS.md, conserva mi configuracion actual y verifica la conexion.Related MCP server: After Effects MCP Server
Cliente | Proveedor habitual | MCP local | Metodo recomendado |
OpenCode | OpenAI, Anthropic y otros | Si |
|
Claude Desktop | Anthropic | Si | Settings > Developer > Edit Config |
Claude Code | Anthropic | Si |
|
ChatGPT Desktop con Codex | OpenAI | Si | Settings > MCP servers o |
Codex CLI / IDE | OpenAI | Si |
|
Cursor | Configurable | Si |
|
ChatGPT web | OpenAI | No local | Requiere una app MCP remota HTTPS |
ChatGPT Desktop con Codex, Codex CLI y la extension IDE comparten la misma configuracion MCP. ChatGPT web no lee la configuracion local.
Windows 10 u 11.
Node.js 20 o superior.
Adobe After Effects instalado.
En After Effects, activar:
Preferencias > Secuencias de comandos y expresiones > Permitir que las secuencias de comandos escriban archivos y accedan a la red.
El servidor detecta automaticamente la version mas reciente instalada en
C:\Program Files\Adobe.
No es necesario clonar el repositorio. El ejecutable imprime la configuracion correcta para cada cliente:
npx -y github:leo10m2010/mcp-after --print-config opencode
npx -y github:leo10m2010/mcp-after --print-config claude-desktop
npx -y github:leo10m2010/mcp-after --print-config claude-code
npx -y github:leo10m2010/mcp-after --print-config cursor
npx -y github:leo10m2010/mcp-after --print-config codex
npx -y github:leo10m2010/mcp-after --print-config codex-toml
npx -y github:leo10m2010/mcp-after --print-config chatgpt-desktop
npx -y github:leo10m2010/mcp-after --print-config chatgptCombina este bloque con opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"after-effects": {
"type": "local",
"command": ["npx", "-y", "github:leo10m2010/mcp-after"],
"enabled": true
}
}
}Reinicia OpenCode y verifica:
opencode mcp listArchivo listo: examples/opencode.json.
Abre Claude Desktop.
Entra a Settings > Developer > Edit Config.
Claude abre %APPDATA%\Claude\claude_desktop_config.json.
Combina el siguiente servidor dentro de mcpServers sin borrar otros MCP.
{
"mcpServers": {
"after-effects": {
"command": "npx",
"args": ["-y", "github:leo10m2010/mcp-after"]
}
}
}Cierra Claude Desktop completamente y vuelve a abrirlo.
En el cuadro de mensaje, abre Connectors > Manage connectors y confirma
que after-effects muestra sus herramientas.
Archivo listo:
examples/claude-desktop.json.
Instalacion para todos los proyectos del usuario:
claude mcp add --scope user --transport stdio after-effects -- npx -y github:leo10m2010/mcp-after
claude mcp listAbre una nueva sesion de Claude Code y usa /mcp para comprobar el servidor.
La app de escritorio de ChatGPT con Codex admite servidores locales stdio.
Puede configurarse de dos formas:
Abre Settings > MCP servers > Add server.
Elige STDIO.
Nombre: after-effects.
Comando: npx.
Argumentos: -y y github:leo10m2010/mcp-after.
Guarda y selecciona Restart.
Alternativamente, instala desde una terminal:
codex mcp add after-effects -- npx -y github:leo10m2010/mcp-after
codex mcp listLa app de ChatGPT Desktop, Codex CLI y la extension Codex comparten
~/.codex/config.toml. Configurar una de ellas configura las otras en el mismo
host. En la interfaz, usa /mcp para ver el servidor.
codex mcp add after-effects -- npx -y github:leo10m2010/mcp-after
codex mcp listConfiguracion TOML equivalente:
[mcp_servers.after-effects]
command = "npx"
args = ["-y", "github:leo10m2010/mcp-after"]
startup_timeout_sec = 30
tool_timeout_sec = 3600
default_tools_approval_mode = "writes"Archivo listo: examples/codex.toml.
Crea o combina .cursor/mcp.json:
{
"mcpServers": {
"after-effects": {
"command": "npx",
"args": ["-y", "github:leo10m2010/mcp-after"]
}
}
}Reinicia Cursor. Archivo listo: examples/cursor.json.
ChatGPT web no puede iniciar este proceso local ni leer ~/.codex/config.toml.
Las apps MCP de la web requieren un endpoint remoto HTTPS.
Este servidor incluye after_effects_run_jsx, que puede ejecutar codigo y
acceder a archivos locales. No lo publiques mediante un tunel abierto. Para usar
modelos OpenAI con el After Effects de la misma computadora, usa ChatGPT Desktop
con Codex o Codex CLI.
Una version remota requiere otro componente con HTTPS, autenticacion, permisos, restricciones de herramientas y acceso seguro a la computadora donde corre After Effects. Consulta la documentacion oficial de MCP para ChatGPT.
El MCP es independiente del proveedor. No contiene claves de OpenAI o Anthropic y no selecciona el modelo. El cliente decide que modelo llama las herramientas.
En OpenCode:
Ejecuta opencode models.
Selecciona un identificador disponible, por ejemplo uno con prefijo
openai/ o anthropic/.
Cambia el campo model o usa el selector de modelos.
Conserva intacto mcp.after-effects.
Reinicia OpenCode si modificaste opencode.json.
En Claude, el proveedor lo gestiona Claude. En Codex y ChatGPT Desktop con
Codex, el proveedor lo gestiona OpenAI. Cambiar de cliente no requiere reinstalar
el MCP; solo agrega la misma orden npx en el nuevo cliente.
npm install --global github:leo10m2010/mcp-afterDespues puede usarse after-effects-mcp en lugar de npx -y ...:
{
"command": "after-effects-mcp"
}Herramienta | Funcion |
| Comprueba instalacion, rutas y proceso activo. |
| Lee proyecto, composiciones, capas, transformaciones y efectos. |
| Crea un proyecto nuevo y protege cambios sin guardar. |
| Abre un proyecto y protege cambios sin guardar. |
| Guarda o ejecuta Guardar como. |
| Crea una composicion con dimensiones, duracion y FPS. |
| Agrega y formatea una capa de texto. |
| Agrega una capa solida. |
| Importa footage, secuencias, composiciones o proyectos. |
| Ejecuta ExtendScript ES3 para operaciones avanzadas. |
| Renderiza un proyecto guardado mediante |
Inspecciona el proyecto abierto de After Effects y dime que composiciones tiene.Crea una composicion 1920x1080 de 10 segundos y agrega un titulo animado.Importa C:\Recursos\logo.svg y usalo en la composicion Final.Guarda el proyecto y renderiza la composicion Final en C:\Renders\final.mov.El agente debe inspeccionar el proyecto antes de editar. Guardar, descartar cambios o renderizar requiere una solicitud expresa del usuario.
AFTER_EFFECTS_PATH: ruta absoluta de AfterFX.exe.
AFTER_EFFECTS_RUNNER_PATH: ejecutable usado para enviar JSX.
AERENDER_PATH: ruta absoluta de aerender.exe.
Estas variables se agregan en env dentro de la configuracion MCP del cliente.
node --version
npx --version
npx -y github:leo10m2010/mcp-after --version
npx -y github:leo10m2010/mcp-after --print-config opencodeProblemas comunes:
Si aparece npx ENOENT, ejecuta where.exe npx y usa la ruta de npx.cmd.
Si After Effects no aparece, configura AFTER_EFFECTS_PATH.
Si JSX no responde, activa el permiso de scripts en Preferencias de Adobe.
Si el cliente no muestra herramientas, cierralo completamente y reinicialo.
Claude Desktop escribe logs MCP en %APPDATA%\Claude\logs.
Consulta la guia ampliada en docs/CLIENTS.md.
git clone https://github.com/leo10m2010/mcp-after.git
cd mcp-after
npm ci
npm test
npm run smokenpm test valida sintaxis, configuraciones y protocolo sin After Effects.
npm run smoke comprueba la instalacion local sin abrir After Effects.
npm run smoke -- --live ejecuta lecturas reales.
npm run smoke -- --live --new-project modifica el estado de la aplicacion y
solo debe usarse con un proyecto limpio.
El servidor local no abre puertos.
No guarda claves de proveedor.
Abrir o reemplazar proyectos rechaza cambios sin guardar por defecto.
Guardar, descartar y renderizar deben ser acciones solicitadas por el usuario.
after_effects_run_jsx tiene acceso amplio a After Effects y archivos locales.
No expongas este servidor directamente a Internet.
Add a solid layer to a composition. Dimensions, duration, and position default to the composition values.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Solid | |
| color | Yes | ||
| width | No | ||
| height | No | ||
| position | No | ||
| pixel_aspect | No | ||
| composition_id | No | ||
| timeout_seconds | No | ||
| composition_name | No | ||
| duration_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a write operation ('Add'), consistent with readOnlyHint=false. However, it fails to disclose behavioral traits such as whether the composition must exist, whether the operation modifies the current project, or any side effects. With annotations providing minimal info, the description carries insufficient burden.
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?
The description is concise with two efficient sentences, no redundancy, and front-loaded purpose. However, given the tool's complexity (10 parameters), it is arguably too brief to cover essential information.
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 10 parameters, no output schema, and minimal annotations, the description is incomplete. It does not explain what the tool returns, how composition is identified, or the meaning of defaults. The agent lacks sufficient context to use the tool correctly without external knowledge.
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 0%, and the description adds no parameter-specific information beyond noting defaults. It does not explain color format, position structure, or the role of composition_id versus composition_name. The description fails to compensate for the lack of schema documentation.
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 clearly states the tool adds a solid layer to a composition, with defaults for dimensions, duration, and position. This distinguishes it from sibling tools like after_effects_add_text implicitly, but could be more explicit about what a 'solid layer' entails.
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 guidance is provided on when to use this tool versus alternatives (e.g., after_effects_add_text, after_effects_import_file). There is no mention of prerequisites or context for when adding a solid layer is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add and style a text layer in a composition. Select the composition by id or exact name; when omitted, the active composition is used.
| Name | Required | Description | Default |
|---|---|---|---|
| font | No | PostScript font name, for example ArialMT. | |
| text | Yes | ||
| in_point | No | ||
| position | No | [x, y] or [x, y, z]. Defaults to composition center. | |
| font_size | No | ||
| out_point | No | ||
| fill_color | No | ||
| layer_name | No | ||
| start_time | No | ||
| justification | No | center | |
| composition_id | No | ||
| timeout_seconds | No | ||
| composition_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false and destructiveHint=false, so the description's mention of 'add' and styling is consistent but adds little beyond basic operation. The fallback behavior is a useful trait.
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 succinct sentences, no fluff, front-loaded with the primary action. Efficiently communicates the core functionality.
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 13 parameters and no output schema, the description is too sparse. It only covers composition targeting, leaving many parameter behaviors unexplained, which limits the agent's effective use.
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 15% (2 of 13 parameters documented). The description adds context for composition selection but does not explain the majority of parameters (e.g., font_size, fill_color).
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 clearly states the tool adds and styles a text layer in a composition, using specific verbs and resource. It distinguishes from sibling tools like after_effects_add_solid.
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 guidance on selecting a composition by id or name, with fallback to active. However, no when-not-to-use or alternative tool mentions for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a composition in the current After Effects project and optionally place it in a project folder.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| width | No | ||
| height | No | ||
| frame_rate | No | ||
| folder_name | No | ||
| pixel_aspect | No | ||
| open_in_viewer | No | ||
| timeout_seconds | No | ||
| background_color | No | ||
| duration_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false) and the description adds no behavioral details beyond stating the action 'Create'. It does not mention side effects, resource limits, or behaviors like overwriting, which are important 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?
The description is a single, concise sentence, but it lacks structure to aid scanning. While it is not verbose, it omits important details that could be better organized.
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?
Given 10 parameters, no output schema, and no explanation of return values or side effects, the description is far from complete. It fails to inform the agent about what the composition creation entails or what happens upon success/failure.
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?
With 0% schema description coverage, the description should compensate by explaining key parameters, but it only hints at 'folder_name' via 'optionally place it in a project folder'. All other parameters (width, height, frame_rate, etc.) are undocumented in the description.
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 clearly states the verb 'Create' and the resource 'composition' in the context of a current After Effects project, which distinguishes it from sibling tools like after_effects_add_solid that add elements within a composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like after_effects_add_solid or after_effects_add_text, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import footage, an image sequence, a layered composition, or another project into the current After Effects project.
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | No | ||
| file_path | Yes | Absolute path to the file to import. | |
| import_as | No | footage | |
| timeout_seconds | No | ||
| force_alphabetical | No | ||
| destination_folder_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds no new behavioral details beyond confirming it modifies the project state. This is adequate but not enriched.
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?
The description is a single, concise sentence that front-loads the core action and resource types. No redundant information.
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, the description covers the main purpose but lacks details on parameter semantics and behavioral nuances. It is minimally adequate given the annotations and schema presence.
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 low (17%). The description links the import types (footage, composition, etc.) to the import_as enum, adding some value. However, other parameters like sequence, force_alphabetical, and destination_folder_name are left unexplained.
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 clearly states the tool imports footage, image sequences, layered compositions, or projects into After Effects. It uses specific verbs and resources, distinguishing it from sibling tools like adding solids or text.
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 context makes it clear when to use this tool (when importing external files), but no explicit when-not-to-use or alternatives are provided. Sibling tools imply different use cases, but the description doesn't articulate exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new project and dismiss the After Effects Home/New Project screen. Unsaved changes are protected by default. Optionally save the new project immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | No | Optional absolute path where the new project will be saved. | |
| timeout_seconds | No | ||
| on_unsaved_changes | No | What to do if the current project has unsaved changes. The default refuses to replace it. | error |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations: it explains that unsaved changes are protected by default (the on_unsaved_changes default), the Home screen is dismissed, and saving can happen immediately. This provides behavioral context not captured by annotations alone.
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 sentences with no fluff. The first sentence delivers the core purpose, the second adds important behavioral detail. Every word 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 tool with 3 parameters and no output schema, the description covers the main flow: creating, dismissing Home, safe handling of unsaved changes, optional save. It could mention timeout_seconds behavior, but overall it is sufficiently 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?
With 67% schema coverage, the description adds context for the on_unsaved_changes parameter (explains default behavior) and reinforces the optional nature of project_path. For timeout_seconds, no extra info is given, but overall the description enriches parameter understanding.
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 clearly states the tool creates a new project and dismisses the Home screen. It distinguishes from siblings like open_project or save_project by focusing on creation. Action and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to create a new project) and mentions handling unsaved changes, but does not explicitly state when not to use it or suggest alternatives (e.g., use open_project for existing projects). Guidance is adequate but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open an .aep, .aepx, or template project. Unsaved changes are protected by default; choose save or discard explicitly when needed.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Absolute path to the After Effects project. | |
| timeout_seconds | No | ||
| on_unsaved_changes | No | What to do if the current project has unsaved changes. The default refuses to open another project. | error |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by explaining the default behavior for unsaved changes, even though annotations already mark the tool as destructive. It does not contradict annotations and expands on safety precautions, warranting a score above baseline.
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?
The description is exceptionally concise at two sentences, with the critical action and file types front-loaded. Every sentence provides necessary information without redundancy, earning a top score.
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?
Given the tool's simplicity (3 parameters, no output schema), the description covers the essential purpose and key behavioral constraint. It lacks details on return values or error cases, but for an open operation this is sufficient; a perfect score would require those details.
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?
With 67% schema description coverage, the baseline is 3. The tool description adds value by elaborating on the `on_unsaved_changes` parameter's effect ('choose save or discard explicitly'), which aligns with the parameter's enum choices and default, making it more actionable.
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 clearly states the action ('Open') and the specific file types ('.aep, .aepx, or template project'), making the tool's purpose unambiguous. It distinguishes well from sibling tools like 'new_project' and 'save_project' by focusing on opening existing files.
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 provides guidance on handling unsaved changes ('Unsaved changes are protected by default; choose save or discard explicitly when needed'), which is helpful. However, it does not contrast with alternatives such as 'new_project' or 'import_file', nor does it specify prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the current After Effects project, compositions, layers, transforms, and effects. Launches After Effects if needed but does not modify the project.
| Name | Required | Description | Default |
|---|---|---|---|
| max_items | No | Maximum project items returned. | |
| include_layers | No | Include layer details for each composition. | |
| timeout_seconds | No | Maximum wait while After Effects starts or responds. | |
| max_layers_per_comp | No | Maximum layers returned for each composition. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds the behavioral trait of launching After Effects if needed, which supplements the annotations and clarifies the tool's non-modifying nature.
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?
The description is two sentences, front-loading the purpose and adding a key behavioral note. Every sentence is efficient and necessary.
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?
Without an output schema, the description should clarify return format but only vaguely mentions inspected items. It adequately explains parameters and behavior but leaves the output structure ambiguous.
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 each parameter has a clear description. The tool description does not add further semantic context beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'inspect' and the resource 'After Effects project', and specifies the scope: compositions, layers, transforms, and effects. It distinguishes from sibling tools that add, create, import, or modify the project.
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 implies usage for inspection without modification but does not explicitly state when not to use or provide alternatives like after_effects_status for lighter checks. Guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a saved After Effects project through aerender. Specify a composition or omit it to render queued items. This writes output files and may run for a long time.
| Name | Required | Description | Default |
|---|---|---|---|
| sound | No | ||
| end_frame | No | ||
| composition | No | Exact composition name. Omit to use the project's render queue. | |
| output_path | No | Absolute output path. Image sequences may use a [#####] token. | |
| start_frame | No | ||
| project_path | Yes | Absolute path to a saved project. | |
| frame_increment | No | ||
| timeout_seconds | No | ||
| output_module_template | No | ||
| reuse_running_instance | No | ||
| render_settings_template | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states the tool is destructive (writes files) and long-running. Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description reinforces and adds performance expectations. No contradictions.
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?
The description is very concise: three sentences, each serving a purpose. The first states the main action, the second clarifies composition usage, and the third notes side effects and runtime. No unnecessary 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?
Given the tool's complexity (11 parameters, no output schema, destructive), the description is incomplete. It lacks details on most parameters, return values, success criteria, and prerequisites. The agent would need to infer how to set up the render correctly from minimal information.
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 27%, and the description provides minimal parameter details. It mentions the 'composition' parameter (specify or omit) and implies 'project_path' is required, but fails to explain other key parameters like sound, start_frame, end_frame, output_path, timeout, etc. The description does not compensate for the low schema coverage.
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 clearly states the tool's purpose: 'Render a saved After Effects project through aerender.' It specifies the resource (saved project), verb (render), and method (aerender). The mention of specifying a composition or omitting it distinguishes this tool from sibling tools, which cover other After Effects operations like adding solids or opening projects.
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 guidance on when to use the tool: to render a saved project. It explains the two modes (specify composition or use render queue) and notes that it writes output files and may run for a long time, implying it's for final output. It does not explicitly exclude alternatives, but since no other render tool exists among siblings, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run arbitrary ExtendScript inside After Effects for advanced operations not covered by focused tools. The code executes inside a function, may use app/project APIs, and should use an explicit return with JSON-serializable data. Use ES3-compatible syntax only. This is a powerful local tool: JSX can modify projects and access files.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ES3-compatible ExtendScript function body. | |
| timeout_seconds | No | Maximum wait for the script result. | |
| undo_group_name | No | Optional After Effects undo group around the script. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive. The description adds valuable context: code runs inside a function, can modify projects/files, must use ES3 syntax, and should return JSON. This goes beyond the annotations, but could mention synchronous execution and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, no redundancy. Could be trimmed slightly, but overall efficient and well-structured.
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 custom script runner with 3 parameters and no output schema, the description adequately explains execution context, syntax, and safety. Missing details about error handling or return values, but acceptable given the complexity.
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 covers 100% of parameters with descriptions. The tool description reinforces the code parameter's syntax constraints but doesn't add new meaning beyond what's already in 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?
Description clearly states the tool runs arbitrary ExtendScript for operations not covered by focused tools, distinguishing it from the sibling tools that handle specific actions like adding solids or text.
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?
Explicitly says to use for 'advanced operations not covered by focused tools,' providing a clear when-to-use guideline. However, it doesn't explicitly state when not to use or list alternative tools, so it's slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the current project. Provide project_path for Save As; omit it to save to the project's existing path.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | No | Optional absolute .aep or .aepx destination path. | |
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds no context beyond 'save'. It does not explain overwrite behavior, confirmation dialogs, or potential errors. The description carries minimal burden beyond the annotations.
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?
The description is exceptionally concise: two sentences with no fluff. The primary action is front-loaded, and the parameter guidance follows immediately. Every word 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 simple save operation, the description is minimal but functional. It lacks details on return values, error handling, or what happens on overwrite. Given no output schema and limited context, it could be more complete (e.g., 'Returns success or throws an error').
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 description adds clear semantics for project_path ('Save As' vs 'save to existing path') which complements the schema's description. However, timeout_seconds is not addressed, leaving its role implicit. With 50% schema coverage, the description partially compensates.
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 clearly states the purpose ('Save the current project') and distinguishes between Save and Save As by explaining the role of project_path. It uses specific verbs and resource, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic guidance on when to supply project_path vs when to omit it, but it does not explicitly discuss when to use this tool versus alternatives (e.g., saving before closing, periodic saves). The context from sibling tools is implicit but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the local After Effects and aerender installation paths and whether After Effects is already running. This does not launch or modify After Effects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description reinforces these by confirming no modification or launch, adding behavioral context beyond annotations. No contradictions.
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 with no unnecessary words. The first sentence clearly states the action and resource; the second clarifies boundaries.
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 description is fully complete for a parameterless read-only tool. No output schema needed as the description adequately covers what the tool returns.
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 input schema has zero parameters, and the description explains the output focus (paths and running status). Schema coverage is 100%, so no additional parameter info needed.
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 uses specific verbs ('Check') and resources ('installation paths', 'running status'), clearly distinguishing from sibling tools which are actions or other queries like project info.
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 explicitly states what the tool does (check status) and what it does not do ('does not launch or modify'), providing clear context. However, it does not explicitly mention when not to use it or alternatives, though sibling tools imply action vs. check distinction.
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.
v1.1.0after_effects_add_solidafter_effects_add_textafter_effects_create_compositionafter_effects_import_fileafter_effects_new_projectafter_effects_open_projectafter_effects_project_infoafter_effects_renderafter_effects_run_jsxafter_effects_save_projectafter_effects_statusScored across 11 tools
Each tool targets a distinct operation—adding solids, adding text, creating compositions, importing files, managing projects, rendering, and running scripts—with no overlap in purpose.
All tools follow a consistent 'after_effects_verb_noun' pattern, making it easy to predict function from name.
11 tools cover the core After Effects workflows without being excessive; each tool has a clear role.
The set covers project, composition, layer, import, and render operations. Missing some specific layer types (e.g., shapes) but the JSX runner fills advanced gaps.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for Google Veo AI video generation
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
