after-effects-mcp-enhanced

Overview Schema Source Related Servers Discussions Admin

run-command

Execute predefined After Effects commands to automate project tasks like creating compositions, layers, and applying effects, returning results or a request ID.

Instructions

Run a predefined AE command. Uses upstream parameter names; createNullObject uses compId. Returns a correlated result or a durable request ID.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "command": "<command>"
    },
    "name": "run-command"
  }
}

Input Schema

Name	Required	Description	Default
`command`	Yes
`parameters`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Sep 8, 2026

TDQS

B3.2/5.0

Behavior3/5

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

The description discloses that it returns either a correlated result or a durable request ID, implying both synchronous and asynchronous behavior. However, it does not mention side effects, permissions, or whether commands may mutate state. With no annotations, it carries the burden and only partially addresses it.

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

Conciseness5/5

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

The description is two concise sentences, front-loading the core purpose and then adding a relevant detail about parameter naming and return types. No unnecessary words or repetition.

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

Completeness4/5

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

Given the tool's generic nature spanning 19 commands, the description provides a reasonable high-level overview. It addresses the return type and gives a parameter naming hint. Without an output schema, it could be more explicit about the structure of the result, but the current level is adequate for initial context.

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

Parameters2/5

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

Schema coverage is 0% and the generic parameters object provides no per-command details. The description adds a single example (createNullObject uses compId) and notes upstream parameter naming, but fails to explain meaningful parameter usage for the remaining 18 commands. The compensation is minimal.

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

Purpose4/5

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

The description clearly states it runs a predefined AE command, establishing the verb and resource. It distinguishes from siblings by focusing on predefined commands rather than arbitrary execution, though it could list or reference the command set more explicitly.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like execute-jsx or other sibling tools. The mention of upstream parameter names is about semantics, not usage context. There is no 'when to use' or 'when not to use' information.

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

Deploy Server