Spline V2 lets Coding Agents as Real-Time 3D Design Collaborators

The genuinely new idea: the editor itself becomes the agent's API

Spline is a real-time 3D design platform for building interactive 3D scenes directly in a visual editor — "make anything 3D," in the vendor's own positioning on spline.design. And Spline already ships AI-assisted generation: the Spline AI page describes bringing the power of AI to the third dimension, letting users generate 3D content from prompts. The reported Spline V2 release takes that idea one structural step further: instead of bolting an integration onto the side of the editor, the V2 desktop app reportedly bundles a local Model Context Protocol (MCP) server, so coding agents can sit inside a live 3D scene, read what is there, and change it without flattening the scene to an image or exporting a file.

That distinction matters. Most AI-to-3D workflows today are file-based: a model generates a mesh, hands you a GLB, and the collaboration ends at the download. Or they are screenshot-based: the agent looks at a render, guesses at the underlying structure, and you rebuild its suggestion by hand. The MCP-in-the-editor pattern avoids both failure modes, because the agent edits the same document the designer is looking at, with the same undo stack and the same layer tree.

A note on sourcing, stated plainly: at the time of this retrofit, Spline's public site confirms the 3D platform and its AI generation capability, and the MCP specification confirms the open protocol mechanics described below — but no vendor announcement page for a "V2 MCP launch" was reachable during verification. The V2-specific details in this article (release timing, bundled server, client auto-registration) are presented as reported capabilities, not as vendor-confirmed facts. If you are evaluating this for production work, confirm the current state against Spline's own changelog before committing a pipeline to it.

Why MCP is the right plumbing for this

MCP is an open-source standard for connecting AI applications to external systems, maintained with public documentation and examples spanning tools like Claude Code, Figma, and Blender at modelcontextprotocol.io. The core abstraction is simple: a host application exposes tools (things the model can do) and resources (things the model can read), and any MCP-compatible client can discover and call them over a standard protocol.

That generality is what makes the Spline story plausible and interesting. A 3D editor is, under the hood, a structured document: a scene graph of objects, each with transforms, materials, and behaviors. Exposing that document through MCP tools — list objects, read properties, create mesh, set material, move object — turns the editor into something a coding agent can operate the way it operates a codebase: read first, then write, then verify. The agent does not need a Spline-specific plugin. It needs MCP, which it already speaks.

The same pattern already works elsewhere in the design world. Figma's MCP exposure lets agents read and manipulate design files; Blender's MCP integrations let agents drive a 3D scene programmatically. Spline applying the same pattern to its own editor is the expected move, not a surprising one — the surprise would have been if real-time 3D editors stayed file-only while everything else became agent-addressable.

The reported V2 integration, as described

According to the launch reporting this article is based on, Spline V2 ships the MCP server inside the rebuilt desktop app for macOS and Windows — not as a separate download, not as a browser extension, and not as a standalone server package. The reported behavior: opening the desktop app registers the server entry with supported AI clients (Claude Code, Cursor, Codex, Google Antigravity, and VS Code are the clients named in the reporting), and restarting the AI client picks up the registration the way any MCP tool configuration loads.

Two of those details deserve independent scrutiny before you rely on them. First, the desktop-only scope: the reporting is explicit that the MCP server does not work in the browser, which is consistent with how a local MCP server must run (local process, local document access), but it means browser-first teams should not plan around this release. Second, the auto-registration behavior — the app writing server entries into client config files — is convenient but also the kind of behavior vendors frequently revise; a typical MCP client config looks like this, and you should know where yours lives regardless of what the installer does for you:

# Illustrative MCP client config locations — verify yours per client docs
~/.cursor/mcp.json          # Cursor
~/.claude.json              # Claude Code (config-managed)

Exact paths vary by client and version. The point is not the path — it is that MCP registration is ordinary config-file mechanics, and anything an installer writes, you can inspect and hand-edit.

Once wired, the reported prompt flow is: you type a request like "create a floating island" into your coding agent, the agent turns it into structured MCP tool calls, Spline routes those calls to whichever 3D editor tab is open (creating a new file if none is open), and the model reads the live scene first, decides what to change, and writes the change back to the same document. You get a live scene back — not a PNG, not a detached asset file.

What you can actually ask it to do

The worked example in the launch reporting is the floating island: a low-poly island with a small house and a hovering torus portal, generated from a single text prompt. From there, the surface area is whatever the editor exposes through MCP, and the architecture makes several classes of task natural:

• Generate meshes from text prompts. Spline's own AI agent can build or edit scenes from prompts, so the MCP layer can invoke generation as a tool. "Add a low-poly forest to the back of the scene" becomes one prompt instead of a modeling session.
• Edit existing geometry. Because the model can read the scene before writing, property edits, transforms, and material swaps are grounded in the actual document rather than guessed from a screenshot.
• Move between design and code in one turn. The model can read the canvas and the code running over it — scene logic, state machines, interaction handlers — and change the visual and the code together, which is the workflow that file-based AI 3D tools cannot offer.
• Keep the project editable. Every change stays inside the Spline project: the timeline, the layers, the undo stack. Nothing gets flattened into an asset the designer can no longer touch.

The honest framing, which survives regardless of which V2 details check out: this is design collaboration, not design replacement. The model is a junior designer with read/write access to the same document — fast at variants, still in need of direction and review.

Setting it up, with verification steps

Because the V2 specifics are reported rather than vendor-confirmed, treat setup as a verify-as-you-go exercise rather than a blind install:

1. Confirm the release exists. Check Spline's official site and changelog for the V2 desktop app for macOS or Windows before downloading anything. Do not install from mirrors or guessed URLs.
2. Launch the desktop app and look for MCP server registration with your installed AI clients. If auto-registration is supported in your build, it happens at launch.
3. Restart the AI client you want to use. MCP config loads at client launch — this is the step people forget across every MCP integration, not just this one.
4. Verify the tool surface. Ask your agent to list the available Spline tools before asking it to build anything. The tool list is the contract; it tells you what the model can actually touch.
5. Start with a read-only probe. "Describe the objects in the open scene" exercises the read path with zero write risk. Then try a small write:

Create a low-poly floating island with a small house on top
and a torus-shaped portal hovering 2 units above it.

6. Watch the editor tab update. The scene should stay live and editable, with changes reflected in the layer tree and undoable through the normal undo stack.

Troubleshooting principles that hold for any local MCP server: server not appearing in your client means the registration did not load — quit and reopen both apps, then check the client's config file directly. Browser-only workflow means this release is not for you yet. A client not on the supported list is unconfirmed, not broken — check for updates on both sides before concluding anything.

Where the limits are

Read the reporting critically and the limits are real, whether or not every detail verifies:

• Desktop-only scope (macOS and Windows per the reporting; no Linux mentioned, no browser). Most 3D-heavy teams run a desktop editor anyway, so this is a scoping line, not a blocker — but draw it before promising a client a workflow.
• No standalone server package. The MCP server reportedly ships only inside the desktop app: no self-hosting, no headless deployment, no CI-driven scene generation. If your pipeline needs programmatic scene builds without a designer at a desk, that gap matters.
• Capability is bounded by the exposed tool surface. Whatever the editor publishes through MCP is the whole universe the agent can act on. Generation plus property edits cover a lot, but they are not "do anything in the editor."
• The supported-client list is a snapshot. Client lists grow; MCP is a standard precisely so that no single list is load-bearing. Prefer the standard over the list.

The durable layer underneath

Spline V2 — as reported — is worth evaluating, and the MCP-in-the-editor move is the right bet for 3D tooling generally. The setup cost is roughly fifteen minutes, and the read-first-write-second loop it enables is genuinely how agents should touch creative documents.

But the part that does not change when Spline ships V3, or when the supported-agent list grows, or when MCP itself is eventually succeeded by whatever comes next, is the runtime your 3D scene ships inside. The asset is the volatile half. The component that hosts the canvas — the one that looks and behaves the same on web, iOS, and Android through a single API — is the durable half. That layering question (one component API across platforms, one agent-readable repository structure, one design system your agents can actually consume) is upstream of any single editor integration, and it is what determines whether AI-generated scenes survive contact with your production app — the same single-component thinking that keeps web and native from diverging, and the one-codebase discipline that keeps three platforms from becoming three codebases.

Spline gives you the scene. The part underneath the scene is what you keep — build it on OTF templates and it compounds no matter which agent draws the next island.

Sources

• Spline — official 3D design platform: spline.design
• Spline AI 3D generation: spline.design/ai
• Model Context Protocol — open standard for connecting AI applications to external systems: modelcontextprotocol.io