Exode MCP Server: Connect Exode to Your AI Coding Tool

What the Exode MCP server actually changes

A .exode file is JSON. The server reads that JSON, changes it, and writes it back. Every tool takes a path to a file plus the values to set, which means the agent is editing the same file your editor opens, not a screenshot or a description of it.

The tool catalog covers five areas: artboards and objects, animation and spring physics, state machines and logic, imports and exports, and validation. The tools page lists them by group with the real names the agent calls.

• Artboards: list, read, summarise and configure size, fit mode and responsiveness.
• Animation: keyframes, timelines, springs, stagger, wiggle, motion paths.
• States: inputs, transitions with conditions, flow rules, logic nodes, object interactions.
• Components: scaffold a button, switch, slider or card with its state machine already wired.
• Exports: a React component, a static webpage, a .bexode runtime bundle, or a rendered video.

One package, seven clients

The server speaks MCP over stdio. Any client that can launch a stdio server can run it, so the same package works across the tools below. What differs is where each client keeps its config file and how it wants that file written.

Where the server reads and writes files

Paths inside a tool call are relative to a workspace root. Set the WORKSPACE_ROOT environment variable to the folder that holds your .exode files. If you leave it unset, the server uses the parent directory of wherever it was launched.

This is the most common reason a first prompt fails. The agent is connected and the tools run, but a path like "screens/login.exode" resolves against a folder that does not contain it. Set WORKSPACE_ROOT once and the paths in your prompts become predictable.

{
  "mcpServers": {
    "exode": {
      "command": "npx",
      "args": ["-y", "claude-exode-mcp"],
      "env": { "WORKSPACE_ROOT": "/Users/you/projects/motion" }
    }
  }
}

What a good prompt looks like

The agent does not know your design. It knows the file and the tools. Prompts that name states, inputs and feel produce usable motion on the first try. Prompts that name pixels produce something you then have to fix by hand.

Compare "make the button nicer" with "add a saved toggle with two states, Idle and Saved, driven by a boolean input. Hover scales to 1.04, press to 0.96, and the switch to Saved overshoots slightly, then settles." The second one maps onto real tools: an input, two states, and a spring on the transition.

What the server will not do for you

The server edits files. It does not judge whether the motion feels right, and it cannot see your app. Review the result in the ExodeUI editor before you ship it, especially timing and easing, which are the parts people notice when they are wrong.

The live editor tools are the exception to the file-based model: they act on the editor that is currently open, so they only work while the desktop app is running on the same machine. A cloud agent session will not have them.

If the animation never needs a visual editor, a code library such as GSAP or Framer Motion is a simpler path. ExodeUI earns its place when the same motion has to be designed, tuned and then shipped to more than one platform.

Pick the client you already use

Each guide covers the config for one client, the way to check that the tools loaded, one prompt to try, and the failure that client tends to produce. Start with the tool you already have open.

• Claude Code: one command, then the state machine prompts guide.
• Cursor: a project-level mcp.json entry, then the UI animation guide.
• Windsurf: mcp_config.json, plus the 100-tool ceiling to plan around.
• VS Code: the servers key, which trips people up after copying a Claude config.
• Codex: config.toml, shared by the CLI and the IDE extension.
• Devin: a custom MCP, and an honest look at what a cloud session can reach.
• Claude Desktop: the config file path for macOS and Windows.