The canvas3d-mcp server gives AI agents the ability to create, render, validate, interact with, and inspect 2D/3D art and games inside HTML <canvas> using a headless Chromium environment.
Render Scenes: Generate multi-angle screenshots (front, side, top, custom views, close-ups) or sequential animation frames of Three.js, WebGL, Canvas 2D, pixel art, and 2D illustration scenes from an HTML file.
Validate Scenes: Run structured diagnostics returning a JSON report with page/console errors, blank canvas detection, deep Three.js scene-graph checks (floating objects, missing lights, NaN transforms, out-of-frustum meshes, texture/UV issues, camera clipping), and pixel art checks (anti-aliasing, palette overflow) — each with severity level and a concrete fix suggestion.
Playtest Games: Execute automated playtest scripts simulating keyboard/mouse inputs, waits, screenshots, and game state reads (window.__state()) to verify gameplay mechanics like movement, jumping, collision, and scoring.
Inspect Scene Graph: Dump the full Three.js scene tree with world-space positions, bounding boxes, rotations, and material/geometry info for precise debugging and object placement.
Get Guidelines & Helper Libraries: Access curated guides and ready-to-use JavaScript libraries covering workflow, 3D modeling, procedural texturing, per-technology pitfalls, 2D art/UI, pixel art, and game development — including helpers like three-helpers.js, pixel-helpers.js, game2d.js, and game3d.js for procedural textures, character controllers, AABB collision, tilemaps, particles, and more.
Multi-file Project Support: Serve an entire project folder so HTML files can reference local assets and scripts.
Allows AI agents to create, render, validate, and interact with 3D scenes and games using the Three.js library, including multi-angle screenshots and playtesting.
Provides capabilities for AI agents to build and analyze raw WebGL content, including rendering, validation, and interaction with 3D graphics.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@canvas3d-mcp Create a 3D robot with Three.js and render from multiple angles"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP que dá a agentes de IA olhos e instrumentos para criar arte e jogos em <canvas> HTML: modelos 3D (Three.js, WebGL puro, Canvas 2D por software), ilustração 2D, UI de jogos, pixel art e jogos 2D/3D jogáveis (com playtest automatizado). Suporta projetos multi-arquivo (a pasta do HTML de entrada é servida inteira).
A IA escreve um arquivo HTML auto-contido; o servidor renderiza em Chromium headless e devolve:
render_scene — screenshots multi-ângulo (front/side/top/three-quarter ou ângulos custom, close-up via distance_factor < 1) ou frames sequenciais de animação (animation_frames + frame_interval_ms). A IA passa a ver o que criou e itera.
validate_scene — relatório JSON estruturado: erros de página/console, canvas em branco, e (com Three.js registrado) checks profundos do grafo de cena: objetos flutuando, sem luzes, fora do frustum, transform NaN, texturas sem UV, clipping de câmera etc. Para pixel art (window.__pix): ANTI_ALIASING (pixels borrados/fora da grade) e PALETTE_OVERFLOW. Cada issue vem com severidade e sugestão de correção.
interact_scene — playtest: executa um roteiro de inputs (teclas seguradas, cliques, esperas) intercalado com screenshots e leituras de window.__state(), para a IA verificar que o gameplay funciona (player anda? pula? pontua?). Inclui estimativa de FPS.
inspect_scene — dump da árvore de cena Three.js com bounding boxes em coordenadas de mundo, para raciocinar sobre posicionamento exato.
get_guidelines — guias (workflow, ofício 3D geral, texturização, armadilhas por tecnologia, ilustração 2D + UI de jogos, pixel art).
Bibliotecas de helpers servidas em /__helpers/ para o HTML da IA:
Lib | Para | Destaques |
| Three.js |
|
| Canvas 2D | mini-engine 3D por software ( |
| WebGL puro |
|
| todas |
|
| ilustração 2D / UI |
|
| pixel art |
|
| jogos 2D |
|
| jogos 3D |
|
npm install
npx playwright install chromiumRelated MCP server: 3d-eyes
# escopo do projeto atual:
claude mcp add canvas3d -- npx tsx "C:\Users\use\Desktop\ESTUDO\3d canvas improve\src\index.ts"
# ou disponível em todos os projetos:
claude mcp add --scope user canvas3d -- npx tsx "$PWD\src\index.ts"
# para confirmar
claude mcp listDepois peça, por exemplo: "usando as tools do canvas3d, crie um robô 3D em Three.js — leia get_guidelines('workflow') primeiro e itere com render/validate até ficar bom".
get_guidelines("workflow") → convenções e snippets
escreve o HTML (com helpers, registrando window.__scene ou window.__setView)
render_scene → olha todos os ângulos
validate_scene → corrige errors, depois warnings
repete até imagem + relatório ficarem bons
npm test # vitest: unit + integração (Playwright real)
npm run typecheck # tsc --noEmit
npx tsx scripts/smoke-render.ts examples/good-threejs-robot.html # render direto, salva JPGs
npx tsx scripts/smoke-mcp.ts # smoke da camada MCP via stdioEstrutura: src/ (servidor MCP + pipeline Playwright + análise), src/probe/injected/ (scripts injetados na página), helpers/ (libs servidas ao HTML), guidelines/ (guias), examples/ (cenas boas + defects/ que disparam cada validador), tests/.
WebGL headless funciona sem flags (SwiftShader). Override: CANVAS3D_BROWSER_ARGS.
O primeiro contexto WebGL criado logo após o launch do browser é perdido (corrida de init do processo GPU). Mitigado por warmup no launch + reload automático da página quando o snapshot detecta contexto perdido.
Canvas WebGL "render-once" pode capturar em branco (buffer descartado após present). O probe força preserveDrawingBuffer: true e o servidor chama window.__redraw antes de capturar.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | workflow = the write→render→validate loop and server conventions (START HERE); general = 3D modeling craft; texturing = procedural textures/UVs; threejs/canvas2d/webgl = per-tech 3D pitfalls; art2d = flat 2D illustration + game UI/HUD; pixelart = pixel-art craft, palettes and animation; gamedev = 2D/3D games: game loop, input, collision, playtesting with interact_scene, multi-file structure; helpers = helper library source code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool returns guides and details what the 'workflow' topic includes, but does not mention any side effects, idempotency, or rate limits. For a read-only retrieval tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and structured with key guidance upfront. It is not overly verbose but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description provides a thorough overview of each topic's content. It is sufficient for understanding the tool's functionality without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage with descriptions for each enum value. The tool description adds context by highlighting that 'workflow' is the starting point and explaining what it covers, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool 'Returns curated guides for building good 3D canvas scenes.' It also specifies the 'workflow' topic as a starting point, clearly distinguishing it from sibling tools like interact_scene or render_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'Call topic 'workflow' BEFORE writing your first scene' and explains why (it covers the write→render→validate loop). Other topics are implied for different aspects, but no explicit exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the scene .html file (must register window.__scene) | |
| max_depth | No | Maximum tree depth to dump | |
| filter | No | Only include subtrees whose name/type contains this substring | |
| width | No | Viewport width in px | |
| height | No | Viewport height in px | |
| settle_frames | No | requestAnimationFrame frames to wait after load before capturing | |
| extra_wait_ms | No | Extra fixed wait after settling, for slow async scenes | |
| timeout_ms | No | Hard cap for the whole operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It discloses the type of data returned and mentions parameters like settle_frames hinting at async behavior, but does not explicitly state that the tool is read-only or describe performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste. The first states the action and output, the second gives usage context and a concrete example. Front-loads the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (1 required), no output schema, and no annotations, the description adequately explains the tool's purpose and hints at the output structure. Could mention the return format (e.g., JSON), but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with thorough parameter descriptions. The tool description does not add new semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state the tool returns a Three.js scene graph with specific world-space data. The example 'which Y puts the hat on the head' and mention of validate_scene distinguish its purpose from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly guides the agent to use this tool to reason about exact placement/sizes when fixing issues from validate_scene. It does not explicitly state when not to use, but the context with sibling tools is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the game's .html entry file | |
| script | Yes | Playtest script, executed in order. Take screenshots and read_state between actions to verify the gameplay actually works. | |
| format | No | jpeg | |
| width | No | Viewport width in px | |
| height | No | Viewport height in px | |
| settle_frames | No | requestAnimationFrame frames to wait after load before capturing | |
| extra_wait_ms | No | Extra fixed wait after settling, for slow async scenes | |
| timeout_ms | No | Hard cap for the whole operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the load-and-execute behavior, interleaved screenshots/state reads, and the requirement for window.__state. It lacks details on failure modes or error handling but covers core behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs, front-loaded with the main action. It is informative without being verbose, though some sentences could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested script array), the description covers the essential aspects. No output schema is provided, but the return of screenshots/state is implied. Missing details on error handling, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 88%, so most parameters are described. The description adds context: e.g., script should interleave actions with screenshots/state reads, and key names follow Playwright conventions. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it loads a game HTML and executes an input script with screenshots/state reads for verification. It distinguishes from sibling tools like render_scene by emphasizing dynamic interaction testing over static rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using it after building or changing game mechanics, implying it's for playtesting. It doesn't explicitly state when not to use, but context from sibling names and the description itself gives good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to a self-contained .html file that renders a 3D scene into a <canvas> | |
| views | No | Camera views to capture (requires window.__scene or window.__setView; see get_guidelines topic 'workflow'). Ignored for 2D scenes and when animation_frames > 1. | |
| animation_frames | No | Capture N sequential frames of an animated scene instead of multiple camera views | |
| frame_interval_ms | No | Delay between animation frame captures | |
| format | No | jpeg | |
| width | No | Viewport width in px | |
| height | No | Viewport height in px | |
| settle_frames | No | requestAnimationFrame frames to wait after load before capturing | |
| extra_wait_ms | No | Extra fixed wait after settling, for slow async scenes | |
| timeout_ms | No | Hard cap for the whole operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that rendering happens in a headless browser and returns screenshots. It mentions the need for specific global objects for multi-angle views. However, it does not fully disclose side effects (e.g., whether the file is modified), error handling, rate limits, or authentication needs, which would be expected with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 6 sentences, front-loaded with the main action and purpose. It uses emphasis ('ALWAYS') to highlight critical guidance. Every sentence adds value with no redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description is mostly complete. It covers workflow, prerequisites, and specific usage tips. However, it lacks details about the return format of screenshots (e.g., base64, file paths) and does not address error conditions, which reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (90%), so baseline is 3. The description adds value by explaining the multi-angle mechanism and hinting at distance_factor usage for close-ups. However, it does not compensate for the undocumented format parameter (no description in schema). Overall, it adds moderate context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders an HTML file with a 3D canvas and returns screenshots from multiple angles. It uses specific verbs ('renders', 'returns') and the resource (3D scene HTML). It distinguishes from siblings like get_guidelines (guidance), inspect_scene (inspect), interact_scene (interact), and validate_scene (validate) by focusing on rendering and image capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use: 'ALWAYS call this after writing or editing scene HTML'. It mentions prerequisites for multi-angle views (window.__scene or window.__setView) and suggests calling get_guidelines topic 'workflow' for further guidance. It does not provide explicit when-not-to-use scenarios but gives clear context for when it's applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to a self-contained .html file that renders a 3D scene into a <canvas> | |
| include_screenshot | No | Also return the current-frame screenshot | |
| width | No | Viewport width in px | |
| height | No | Viewport height in px | |
| settle_frames | No | requestAnimationFrame frames to wait after load before capturing | |
| extra_wait_ms | No | Extra fixed wait after settling, for slow async scenes | |
| timeout_ms | No | Hard cap for the whole operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully details the tool's behavior: loads scene HTML, reports page/console errors, performs deep scene-graph checks (floating objects, missing lights, etc.), each with severity and fix suggestion. No hidden side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured paragraph front-loading the main purpose and then detailing checks and usage. Efficiently conveys a lot of information without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 7 parameters, the description is comprehensive: covers what the tool does, the types of checks, and usage context. It provides enough information for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for the overall tool but does not significantly elaborate on individual parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly defines the tool's purpose: running structured diagnostics on a 3D canvas scene and returning a JSON report. Distinguishes from siblings like 'interact_scene' or 'render_scene' by focusing on validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Call this after render_scene whenever something looks wrong, and at least once before declaring the scene done.' Also provides ordering advice: 'Fix errors first, then warnings.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate images, GIFs, and PDFs from HTML, URLs, or templates — from your AI agent.
Generate, edit, and deploy immersive 3D/WebGL web projects from any MCP assistant.
On-brand creative studio for AI agents: images, video, audio, and 3D.
AI visual generation agent: multi-pipeline rendering, prompt crafting, and image composition.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/eduardosm123/mcp-3d-llm'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
