canvas3d-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| render_sceneA | Renders an HTML file containing a 3D scene (Three.js, raw WebGL or Canvas 2D) in a headless browser and returns screenshots from multiple camera angles, so you can SEE what you built. ALWAYS call this after writing or editing scene HTML, look hard at every angle, fix problems and render again. Multi-angle needs window.__scene (Three.js) or window.__setView (other tech) — call get_guidelines topic 'workflow' first if unsure. Use distance_factor < 1 in a custom view for close-ups of textures/details. |
| validate_sceneA | Loads the scene HTML and returns a JSON report: page/console errors, blank-canvas and detail analysis of the rendered pixels, and — when window.__scene is registered (Three.js) — deep scene-graph checks: floating objects, missing lights, out-of-frustum meshes, NaN transforms, missing UVs/normals, camera clipping, texture problems. Each issue has a severity and a concrete fix suggestion. Fix errors first, then warnings. Call this after render_scene whenever something looks wrong, and at least once before declaring the scene done. |
| interact_sceneA | Loads a game HTML file and executes a script of inputs (key presses/holds, clicks, waits) interleaved with screenshots and state reads, so you can VERIFY the gameplay you wrote actually works: does the player move, jump, collide, score? Games should expose window.__state = () => ({...}) for read_state assertions. Always playtest after building or changing game mechanics — a game that renders is not a game that plays. |
| inspect_sceneA | Returns the scene tree (names, types, positions, rotations, world bounding boxes, geometry and material info) for a scene that registers window.__scene. Use it to reason about EXACT placement and sizes when fixing issues reported by validate_scene (e.g. which Y puts the hat on the head). Three.js only. |
| get_guidelinesA | Returns curated guides for building good 3D canvas scenes. Call topic 'workflow' BEFORE writing your first scene — it explains the write→render→validate loop, the helper libraries served at /__helpers/, and the conventions (window.__scene / __setView / __ready) that unlock multi-angle screenshots and deep validation. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| guidelines-workflow | |
| guidelines-general | |
| guidelines-texturing | |
| guidelines-threejs | |
| guidelines-canvas2d | |
| guidelines-webgl | |
| guidelines-art2d | |
| guidelines-pixelart | |
| guidelines-gamedev | |
| guidelines-helpers | |
| helpers-three-helpers.js | |
| helpers-canvas3d.js | |
| helpers-webgl-helpers.js | |
| helpers-texture-helpers.js | |
| helpers-draw2d.js | |
| helpers-pixel-helpers.js | |
| helpers-game2d.js | |
| helpers-game3d.js |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: get_guidelines provides workflow guidance, inspect_scene explores the scene tree, interact_scene tests game interactions, render_scene produces screenshots, and validate_scene checks for errors. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (get_guidelines, inspect_scene, interact_scene, render_scene, validate_scene) with clear, descriptive verbs that reflect their actions.
5 tools is well-scoped for a 3D canvas helper server: it covers guidance, inspection, interaction, rendering, and validation without being too few or excessive for the domain.
The tools cover the core workflow of building, rendering, inspecting, validating, and testing scenes. Minor gaps like scene editing or asset import tools exist but are outside the server's stated focus, so completeness is high.