Spline

Run the editor's performance analysis (the same one behind the Performance panel) and get a JSON report: every metric (objects, polygons, materials, textures, lights, effects, booleans, clones, audio) with its value, a good/average/bad mark and the mark thresholds, plus the concrete offenders — the heaviest meshes with their polygon counts, high-subdivision meshes, nested Booleans, all lights (with shadow flags), layer-heavy materials, duplicated and unused assets — each with real object/asset ids and names to target with run_code. Call it BEFORE optimizing a scene (load the scene-optimization skill for the fix recipes) and AGAIN after your fixes to prove the metrics actually improved. Cheap and read-only.

Apply targeted edits to the existing HTML content by replacing exact strings — the same find-and-replace edit every coding agent uses. PREFER this over set_html_content for any change to a document that already exists: it avoids resending (and risking corrupting) the whole document. Pass ALL the edits you already know you need as ONE call — `edits` is an array applied in order, atomically (if any edit fails to match, nothing is applied and the error names the failing edit) — never a separate call per edit. Each edit's `old_str` must appear EXACTLY ONCE in the document as of the edits before it (match byte-for-byte, including whitespace and indentation); include enough surrounding context to make it unique. It is replaced with `new_str` (an empty `new_str` deletes the matched text; `replace_all: true` replaces every occurrence instead — e.g. renaming an id or class throughout). Call get_html_content first if you are unsure of the exact current text. Errors — without mutating — if there is no document yet (use set_html_content to create one).

Starts Spline’s AI 3D model generation and returns IMMEDIATELY with a `job_id` — it does NOT wait for the mesh. Typically 1–3 min, but that is a rough historical figure, not a measured ETA — it can run longer with no advance warning. If this model is the whole ask, do NOT proactively poll: tell the user it has started and stop, and only call `get_generation` again if they ask you to check. If you still need the result to finish a later step of THIS SAME request (e.g. placing/animating it), poll `get_generation` with the job_id roughly every 15s until status is "done" — the finished result, including the mesh and where it landed in the scene, arrives there. Either way, never call this again for the same request while a job is already running. Only call when the user EXPLICITLY asks for a generated 3D model; it costs the user credits, so don’t call it speculatively or in parallel. Same arguments as the in-app tool: prompt, or generation_id / asset_id.

Starts Spline’s AI image generation and returns IMMEDIATELY with a `job_id` — it does NOT wait for the image. Typically ~30–60s, but that is a rough historical figure, not a measured ETA — it can run longer with no advance warning. If this image is the whole ask, do NOT proactively poll: tell the user it has started and stop, and only call `get_generation` again if they ask you to check. If you still need the result to finish a later step of THIS SAME request (e.g. placing/framing it), poll `get_generation` with the job_id roughly every 15s until status is "done" — the finished result, including the image and where it landed in the scene, arrives there. Either way, never call this again for the same request while a job is already running. Only call when the user EXPLICITLY asks for AI generation; it costs the user credits, so craft one good prompt rather than retrying speculatively. Same arguments as the in-app tool: prompt, aspect_ratio, count, add_to_scene, for_3d.

Poll a generation job started by `generate_image` or `generate_3d_model` (over MCP those return a `job_id` immediately instead of waiting). Returns one of: status "running" (with elapsed time and any progress lines so far — do NOT re-start the generation; only call this again yourself if you still need the result for a later step of the SAME request, otherwise it is fine to tell the user it is in progress and stop until they ask you to check), status "error" (the job failed — e.g. out of credits or hit a generation limit; do NOT retry, tell the user), or status "done" (the full result — the generated image/model, already inserted into the scene at the build anchor and selected). A job only exists in the tab that started it; polling after switching files reports "unknown job".

Read the file's current HTML content document (the overlay set with set_html_content). Call it BEFORE editing existing HTML content so you modify the real source instead of guessing — then apply targeted changes with edit_html_content (find-and-replace) rather than rewriting the whole document with set_html_content.

Read the COMPLETE detail of specific objects by id: transform and geometry (type, plus live mesh vertex/triangle counts — raw vertex data reads through getGeometry in run_code), plus full interactivity — states (id, name, selected), events (id, type, per-type props like key/steps/target/variableId), each event's actions per container (id, type, url/variableId/object/runMode…) and Transition tweens (id, target state, duration, delay, easing, repeat, direction), and any variable bindings (property → variable id). Call this BEFORE editing existing interactivity so you have real ids to pass to updateEvent/updateAction/updateTween/remove*. Object ids come from get_scene_mcp or get_scene.

Read a compact digest of the current scene: one line per object (name, type/geometry, id, position, rotation in degrees, scale, content bounding-box size (excludes the object's own scale; for a group it is just the extent of its descendants, so a single far-flung child shifts the box without enlarging it), and flags for hidden / states / events / animations / cloner), with children indented under their parent — plus the selection, pages, variables, the shared material assets (name, layer types, usage count — full definitions via getMaterial in run_code), and the page background and sky. Over MCP the standard FIRST read is get_scene_mcp (this same digest plus the free build anchor); call this to RE-read the scene AFTER building or editing, to verify it actually matches the request (object counts, positions, sizes) — this is the source of truth; a screenshot is not, since objects can overlap or sit out of frame. In a big scene, runs of near-identical siblings come back folded into "+N more" lines carrying their exact count and coordinate spread; pass `expand` to list a parent's children one by one instead.

Read the current scene AND a free build anchor in one call — the standard first call after any user prompt, before you build. Returns the same compact digest as get_scene (one line per object — name, type/geometry, id, position, rotation in degrees, scale, content bounding-box size, flags — children indented under their parent, with the line format spelled out in the result; the current selection; pages; variables; material assets; background and sky) prefixed by a free world-space build anchor [x,y,z] to spawn a self-contained new build beside existing content, with that content footprint. Set only the axes you must pin and let x/z default to that anchor so independent builds do not overlap. In a big scene, runs of near-identical siblings come back folded into "+N more" lines; pass `expand` with a parent id to list that parent's children one by one. After you edit, RE-read with get_scene (or this) — the earlier digest is stale.

Load a focused guidance module into your context; the body is returned as the tool result and stays in context. **Before your first `run_code`, load the Spline 3D authoring contract in THREE parts: call this with "authoring-guide", then "authoring-guide-2", then "authoring-guide-3"** (each once) — together they cover how to work over MCP, the full DSL reference, the critical conventions, the scene quality bar, and the catalog of topic skills to load when a task needs depth (animation, interactivity, materials, organic/nature scenes).