Connecting over MCP
AR Clip exposes an MCP server, so a tool that speaks the Model Context Protocol can work on your project directly — reading the scene, adding objects, wiring events, writing patches.
The endpoint
https://<your-server>/api/mcp/v1
Authentication is a bearer token:
Authorization: Bearer <your-api-token>
Create the token in your account settings, under API & MCP.
It can change your projects. Keep it out of anything you share, and revoke it if it leaks.
Scopes
A token carries only what you give it:
| Scope | Allows |
|---|---|
editor:read | reading projects, scenes and resources |
editor:write | creating and changing them |
editor:ai | the generation tools |
editor:publish | publishing |
Give a read-only token when you only want analysis. A model that cannot write cannot break anything, and a great deal of useful work — auditing a scene, explaining why something does not fire, planning changes — needs nothing more.
What connects
Anything implementing MCP over streamable HTTP. In practice: Claude Desktop, Claude Code, Cursor, and a growing number of editors. Each has its own place to declare a server — you give it the URL above and your token.
Working alongside the editor
Changes an assistant makes appear live in your editor, the same way a colleague's would, and they land in the collaboration history like any other edit.
So the productive shape is: keep the editor open on one screen, ask for changes, and watch them happen. You see immediately when something is not what you meant, instead of discovering it afterwards.
A session remembers which project and space you are working on, so you do not have to repeat it in every request.
What the tools cover
Grouped by what you would ask for:
| Area | The assistant can |
|---|---|
| Scene | list, create, move, parent, duplicate and delete objects |
| Components | read and set any component on any object |
| Events | list triggers and steps, add and edit events |
| Patches | read, write and validate node graphs, and preview the code they compile to |
| Animation | author timeline presets |
| Physics | set bodies, colliders and starting velocities |
| Resources | browse the project tree, create folders, import and generate assets |
| Interface | read and write UI cards |
| Publishing | publish, with the right scope |
Four more that are easy to miss, because they reach out of the server:
| Also | What it does |
|---|---|
| Screenshots | capture the viewport, so an assistant can look at what it built |
| Measurement | an object's real bounding size in metres — how it checks scale |
| Scene export | take a scene out as data |
| Blender bridge | talk to a running Blender: list objects, push a scene to it, pull one back |
An assistant can see its own work, which helps — but a still frame says nothing about whether scripts run, whether physics settles, or whether a marker tracks. Those need a preview on a real device.
list_component_schemas, list_event_types, list_patch_nodes and the describe_*_api tools
answer from the live engine, so an assistant can look up exactly what exists rather than
guessing from training data. If a model is inventing component names, tell it to call those
first.
Ready-made tasks
The server also offers a few prompts an MCP client shows as commands:
| Prompt | Does |
|---|---|
build-scene | build a scene from a description |
add-interactivity | wire up taps, triggers and steps |
animate | put together a timeline |
audit-scene | look for problems |
prepare-publish | check the things worth checking before publishing |
Reading without changing
The server publishes its own reference as resources a client can read:
was://project/info was://scene/current was://scene/selection
was://scripting/api was://patch/api was://events/api
was://physics/api was://timeline/api was://resources/api
was://ui/api
These are generated from the engine, so they never describe a version of the platform that no longer exists.
Next: The assistant's skills