3dCMS Knowledge Base
Open the editor
Drive from Claude (MCP)

Tools & quick phrases

What the MCP server lets Claude do (list, read, create, edit, and publish your scenes), and the phrases that trigger each tool.

Open in the interactive manual →

The interactive version has full-text search, a table of contents, and light/dark themes.


Once connected, Claude gains a small set of tools for working with your scenes:

ToolDoes
list_scenesList your saved scenes.
get_sceneRead a compact summary of one scene (nodes, transforms, materials).
create_sceneMake a new empty scene.
apply_opsApply a batch of edits: the same add/move/recolor/group operations as the in-editor Assistant, including placing point & spot lights, hanging cables (sagging power lines, ropes, festoon strings) between two points, laying a shadow pool under a heavy object so it reads as resting on the ground, steering particles with a force field, the scatter op for set-dressing, and the make_page and make_diagram composites below. It can also write keyframe animation onto an object: arbitrary position, rotation, and scale keys, well past what the editor's preset menu offers. One batch = one Undo.
get_scene_screenshotRender the scene server-side (real headless WebGL) and hand Claude an actual image of it, its "eyes" (see below).
publish_scenePublish to a public, shareable URL. Two steps on purpose: see below.
generate_3d / generate_materialGenerate assets (paid, and only when a fal key is set). Local server only: they need your own fal.ai key, which the hosted connector has no way to carry.

The first six are the core tools, and they're what the hosted connector offers.

Every result includes an editorUrl: open it while signed in to see and keep editing the scene in 3dCMS.

Quick phrases

Say……and Claude
"list my scenes"runs list_scenes
"make a scene called X with…"creates it and builds it
"in <scene>, add / move / recolor…"reads the scene, then edits it
"publish <scene>"gives you a public 3D link

Publishing asks first

publish_scene won't publish on its first call. Ask Claude to publish and it gets back a summary of what would happen (the scene, whether this is your first publish, whether it becomes your primary site) and has to call again with confirm: true before anything goes live. So you always get told before your work becomes public, in the same way the generation tools quote their price before spending credits.

The reason is that publishing isn't fully reversible: the URL is submitted to search engines the moment it goes live, so it can surface in results even after you take the page down. Taking it down is one click and undoable; an un-send isn't a thing. Re-publishing the same scene just updates the site it already has, and the URL stays put.

Whole pages in one step

When you ask for a page (a heading, a paragraph, and a few navigation links), Claude uses the make_page composite op, which builds the entire page surface (hero heading, body paragraph, and clickable "sign" links) in a single operation instead of assembling it from a dozen primitives. It's faster and lays pages out consistently, so a multi-page site comes together in a handful of ops. You don't invoke it by name: just ask, e.g. "add a Contact page with a heading, a short intro, and a link back home."

For a scene with several rooms, Claude also binds each room's lights and props to their page (data.zonePageId, plus data.zoneRadius for something that has to stay visible from the corridor). A bound room switches off while the visitor is elsewhere, and (the part that's invisible until it bites) each room gets its own budget of four shadow-casting lights instead of the first rooms spending all four. See scoping a room to its neighborhood.

Flowcharts & mind maps in one step

Ask for a diagram (a process, a pipeline, an org chart, a mind map) and Claude reaches for the make_diagram composite op. You supply the ideas and how they connect; it builds a labelled card for each one, a connector for each link, and works out the layout itself, so no box is placed by hand. Two shapes are available: layered (the default, rows stacking downward from whatever nothing points at, right for processes, pipelines, and org charts) and radial (one idea in the middle with rings of children around it, right for mind maps). Feedback loops and disconnected ideas are drawn, not rejected.

Every card is tap-to-travel, which is the thing a 3D diagram does that a flat image can't: publish the scene and the link is the diagram. A visitor taps a box and flies over to read it up close. Try: "make a mind map of my product launch with five branches" or "draw the review → fix → build → review loop as a flowchart."

Claude can see what it builds

Building a 3D scene blind is hard. With get_scene_screenshot, Claude renders your scene server-side with real WebGL and gets back an actual image, then judges it like an art director (floating objects? unreadable text? an empty horizon? bad spacing?) and fixes what's off with another apply_ops. It caps itself at a couple of look-and-fix rounds per request so it doesn't loop forever. The upshot: scenes come out looking intentional, not just structurally correct. (Heavy scenes can take a couple of minutes to render the first time; repeat shots are cached.)

Server-side renders come out of a daily budget, because each one occupies a real render slot on the server for ten seconds or so: 10 a day on the free plan, rising to 100, 300, and 1,000 on the paid tiers. Run out and the tool answers with a plain "budget used up, resets tomorrow (UTC)" instead of failing oddly. Claude can carry on building; it just can't look again until then. The publish-time social card is captured in your own browser and never touches this budget.

Live scene lint

Every apply_ops result can carry advisory warnings: a lightweight scene lint that flags common mistakes like content with no real ground or backdrop under it (a "floor" left standing on edge counts as no floor), "orphan" web blocks floating off a page, text that's too small to read, stacked duplicates, an overcrowded page, a lamp fixture parked in its own beam (named with both clearances in metres), a backdrop colour the current lighting mode will never show, or an image hot-linked from another website (it renders for the signed-in author and shows as empty for every visitor). The edits still apply; the warnings just tell Claude what to tidy up in its next batch. The same lint runs behind the in-editor Assistant, so guidance is identical wherever you build.

The hot-linked-image half of that lint also runs at publish time, on both publish paths, so it reaches an author who pasted a URL into Properties by hand and never went near a tool call. A successful publish_scene can therefore come back with a warning naming the nodes, joined onto any scene-weight warning rather than replacing it. One thing it deliberately never warns about: an image slot a template personalizes, whose address is a placeholder the clone replaces wholesale, so the advice would be about a mechanism rather than a mistake.

Big scenes? Build in batches. For large scenes, Claude works in batches of ~40–50 objects across several apply_ops calls, checking the scene (and a screenshot) between them. Try: "In my Gallery scene, add a row of five 1-meter cubes 2 m apart, then group them."
Spotted something off, or want a topic covered? Email hello@3dcms.info.