Exode MCP in Devin: Adding the Server as a Custom MCP

What a cloud session can reach

The Exode MCP server reads and writes .exode JSON files in a workspace directory. In a Devin session, that directory is inside the machine Devin uses, with whatever the session cloned. So the first requirement is that your .exode files are committed, not sitting only on your desktop.

The live editor tools act on a running editor window. A cloud session has no editor window, so those tools are out of reach. Everything that works on files, which is most of the catalog, works normally.

Add a custom MCP on the Customize page

Open Customize, go to the MCPs tab, and choose Add custom MCP. Devin supports stdio, SSE and HTTP transports for custom servers; Exode is stdio, so provide the command and its arguments.

Adding custom servers needs the Manage MCP Servers permission, and the setting is scoped to personal, organization or enterprise. If the button is not there, you do not have that permission and an admin has to add it or grant it.

Name:    exode
Transport: STDIO
Command: npx
Args:    -y claude-exode-mcp
Env:     WORKSPACE_ROOT=/workspace/<your-repo>

Or add it with the Devin CLI

If you run Devin from a terminal, the CLI has its own MCP commands. Everything after -- is the launch command, and the scope flag decides whether the entry is local, project or user level. A project scope is usually right for animation work, because it travels with the repository and points at the files it applies to.

devin mcp add exode -s project -- npx -y claude-exode-mcp

# check it connected
devin mcp list

Point the server at the right folder

Leave WORKSPACE_ROOT unset and the server resolves paths against the parent directory of where it was started, which in a cloud session is rarely the folder you meant. Set it explicitly and every path in a prompt becomes predictable.

If a tool reports that a file does not exist, check the workspace root before changing the prompt. That is the failure nine times out of ten.

Prompts that suit a cloud session

Because you are not watching the canvas, ask for changes you can review as a diff and verify with tools. Structural work is a good fit: adding states, splitting a large artboard, applying design tokens, importing a Lottie file and converting it, or scaffolding components across several screens.

Ask for validation in the same prompt. A session that adds twelve states across four files should end with validate_artboard on each one, so the pull request you review is known to be internally consistent.

• Good fit: state machines, token application, imports, scaffolding, exports.
• Poor fit: judging easing, fixing a curve that feels wrong, visual composition.
• Always ask for: validate_artboard on every file touched.

Where a local client is better

For a single animation you will tune by eye, use Cursor or Claude Code on your own machine, where the editor is a keystroke away and the live tools work. Devin earns its place when the work is broad and reviewable rather than fiddly and visual.