Adobe MCP Servers

Challenge

An LLM has no native way to drive a professional NLE or motion graphics application. After Effects and Premiere Pro expose scripting through ExtendScript, an old, ES3-only dialect, running inside Adobe’s CEP panel runtime, not something a modern model can call directly or safely. The problem was building a real bridge: an LLM on one side, decades-old scripting constraints on the other, with every tool call validated before it is allowed to touch a project file.

Process

Each server is a TypeScript MCP server built on the official MCP SDK; I defined every tool against a Zod schema, so a model’s tool call is validated before it ever reaches Adobe. Because there is no direct process bridge into CEP, I route commands through file-based IPC to an ExtendScript runtime running inside the panel, constrained to an ES3-compatibility ruleset the whole tool surface has to respect. That ruleset shapes the entire integration: no modern JavaScript conveniences inside the ExtendScript layer, careful serialization across the file boundary, and tool definitions I wrote defensively against a scripting environment that was never designed for this.

Both servers live in private repositories with no public code link, so the evidence for this work is demonstrated live or via a recorded walkthrough on request. Ninety-seven tools are defined across the two servers; 43 have been validated end to end against a live Premiere Pro session, with validation of the remaining tools ongoing.

Result

The two servers integrate an LLM into a real, professional creative pipeline (After Effects and Premiere Pro) rather than a toy scripting sandbox, built and proven entirely within enterprise IT constraints. It is internal tooling for a video production team, not a commercial product, and the validated 43-of-97 tool surface already supports real work while the remaining tools continue to be brought online.