An MCP server that lets an LLM inspect and interact with a live BabylonJS scene over WebSocket, providing scene data, screenshots, WebGL capture, JavaScript evaluation, and optional Gemini vision analysis.
Check connection state and available tool categories with babylonjs_connection_status.
Inspect the scene with babylonjs_scene_inspect: summary, full scene graph, or specific categories like meshes, materials, cameras, lights, animations, textures, physics, post-processing, performance, scene tree, and WebGL errors; supports name glob filters and detail targets.
Run arbitrary JavaScript against the scene with babylonjs_scene_evaluate, receiving (scene, engine, BABYLON) and returning JSON-serialized results.
Capture screenshots with babylonjs_screenshot: multiple preset views, custom camera, configurable size/format, returning saved file paths.
Capture WebGL frame data with babylonjs_spector_capture: draw calls, shader source, WebGL state, and texture bindings at summary, shaders, or full detail.
Ask Gemini vision questions about the rendered scene with babylonjs_scene_analyze (only registered when GEMINI_API_KEY is set).
Current-implementation caveat: the browser-side client is still a stub, so only babylonjs_connection_status returns real data today; all browser-dependent tools currently report "No BabylonJS scene connected" until the browser client lands.
Provides WebGL introspection of a running BabylonJS scene via Spector.js frame captures, exposing draw calls, shader source, WebGL state, and texture bindings.
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., "@@graphty/babylonjs-inspector-mcp Take a screenshot of the current scene and check if the lighting looks correct."
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.
An MCP (Model Context Protocol) server that lets an LLM inspect a running BabylonJS 3D scene.
Status: early development (0.x). The MCP server, the tool surface, the WebSocket protocol and the HTTP server are implemented. The browser-side client that actually talks to your BabylonJS scene is still a stub, so today the tools connect and validate but return "no scene connected" until that lands. Read Implementation status for the exact breakdown before you install this.
When an LLM writes BabylonJS code -- shaders, geometry, materials, lighting, animations, post-processing -- it has no way to check the result. It cannot:
See what the scene looks like, from any angle
Tell whether two objects are actually where it intended them to be
Read back shader compilation results or WebGL state
Confirm that a material or light produces the effect it was asked for
Debug a rendering artifact it cannot observe
The LLM writes code, the human looks at the screen, and the human becomes the LLM's eyes.
Related MCP server: Web Developer MCP Server
An MCP server that gives the LLM three kinds of access to a live scene:
Scene data -- structured JSON from BabylonJS: scene graph, meshes, materials, cameras, lights, animations, textures, physics, post-processing, performance counters.
WebGL introspection -- Spector.js frame captures: draw calls, shader source, WebGL state, texture bindings.
VLM scene understanding -- Gemini vision analysis of screenshots, depth maps and multi-view renders, combined with scene metadata (bring your own API key).
Plus a scene_evaluate escape hatch that runs arbitrary JavaScript against the scene, in the
spirit of Playwright's browser_evaluate.
The server is a Node.js process started by your MCP host. It speaks MCP over stdio to the host and WebSocket to your browser. It does not embed a browser; your app connects to it.
+---------------------------+
| MCP client | Claude Code, Claude Desktop, or any MCP host
+---------------------------+
^
| stdio (JSON-RPC) -- MCP tool calls and results
v
+---------------------------+
| babylonjs-inspector-mcp | Node.js process spawned by the MCP host
| | - registers the MCP tools
| | - BrowserBridge: correlates requests by UUID
| | - HTTP + WebSocket server on port 9070
+---------------------------+
^
| WebSocket (ws://localhost:9070) -- commands and responses
v
+---------------------------+
| Browser | your Vite dev server, or any page
| inspector client | - discovers the BabylonJS engine
| + your BabylonJS scene | - runs commands against the live scene
+---------------------------+A tool call travels the whole chain: the host calls babylonjs_scene_inspect, the server
dispatches it to the BrowserBridge, the bridge sends a WebSocket command tagged with a UUID,
the browser client executes it against the scene, and the response comes back up the chain.
Only one browser connection is tracked at a time. Every operation has a timeout tier:
Operation | Timeout |
Scene query / inspect | 5s |
Screenshot capture | 15s |
Spector.js frame capture | 30s |
Scene evaluate | 30s |
Multi-view capture | 45s |
Scene export | 60s |
Node.js >= 20
A BabylonJS application you can run locally
Optionally, a Gemini API key for the VLM analysis tool
npx -y babylonjs-inspector-mcp # run on demand
npm install -g babylonjs-inspector-mcp # binary on your PATH
npm install --save-dev babylonjs-inspector-mcp # Vite plugin / browser clientTo work from a checkout instead:
git clone https://github.com/apowers313/babylonjs-inspector-mcp.git
cd babylonjs-inspector-mcp
npm install
npm run buildThat produces dist/, which bin/babylonjs-inspector-mcp.js needs in order to run.
Add the server to your MCP settings, pointing at your local build. For Claude Code:
claude mcp add babylonjs-inspector -- node /path/to/babylonjs-inspector-mcp/bin/babylonjs-inspector-mcp.jsOr configure it by hand -- this is the JSON block for
claude_desktop_config.json, .mcp.json, or your host's equivalent:
{
"mcpServers": {
"babylonjs-inspector": {
"command": "node",
"args": ["/path/to/babylonjs-inspector-mcp/bin/babylonjs-inspector-mcp.js"],
"env": {
"BABYLONJS_INSPECTOR_PORT": "9070",
"GEMINI_API_KEY": "your-key-here"
}
}
}
}After the package is published, "command": "npx" with
"args": ["-y", "babylonjs-inspector-mcp"] replaces those two lines, and a global
install lets you use "command": "babylonjs-inspector-mcp" with no args. Use npx -y so
that npx's install prompt can never end up on the stdio channel the MCP protocol is using.
GEMINI_API_KEY is optional. When it is absent, the babylonjs_scene_analyze tool is not
registered at all, so it never shows up in the LLM's tool list. When it is present, the tool
appears. Everything else works without it.
The server needs your BabylonJS page to connect back to it over WebSocket. There are two supported ways to make that happen.
Add the plugin to your app's vite.config.ts. It only applies in dev mode (apply: "serve"),
so production builds are untouched, and it needs no changes to your application code.
import { defineConfig } from "vite";
import { babylonjsInspector } from "babylonjs-inspector-mcp/vite";
export default defineConfig({
plugins: [
babylonjsInspector({
port: 9070, // must match BABYLONJS_INSPECTOR_PORT; default 9070
autoConnect: true, // connect on page load; default true
}),
],
});The plugin appends a <script type="module"> tag to your HTML that imports the inspector
client from http://localhost:<port>/inspector-client.js, which the MCP server serves, and
assigns the instance to window.__babylonjsInspector.
If you are not on Vite, or you want explicit control over when the inspector attaches:
import { InspectorClient } from "babylonjs-inspector-mcp/client";
const inspector = new InspectorClient({
port: 9070, // default 9070
autoDiscover: true, // find the BabylonJS engine automatically; default true
scene: myScene, // optional: pass the scene explicitly instead
});Both paths are wired up but not yet functional -- see below.
Six tools are registered. Five are always present; babylonjs_scene_analyze is registered
only when GEMINI_API_KEY is set.
Tool | Returns | Needs a live browser connection |
| Connection state, engine type, canvas size, and which tool categories are currently usable | No |
| Scene data for one of 15 categories, from a counts-only summary to a full scene graph | Yes |
| The JSON-serialized return value of a JavaScript function run against the scene | Yes |
| A map of view name to saved image file path | Yes, and the engine must be able to render |
| Spector.js WebGL frame data: draw calls, shader source, GL state | Yes, plus WebGL and Spector.js in the page |
| A Gemini vision answer to a question about the rendered scene | Yes, rendering capable, plus |
Every browser-dependent tool degrades to a plain JSON { "error": "..." } message rather than
throwing, so the LLM gets a readable reason instead of a protocol failure.
No parameters. Returns connected, engineType, canRender, hasSpector, canvasSize, and
an availableTools object reporting which of sceneInspect, sceneEvaluate, screenshot,
spectorCapture and sceneAnalyze are usable right now. Every entry is false while no
browser is attached, because every one of those tools answers "No BabylonJS scene connected"
in that state. Call this first when a tool reports that nothing is connected.
Parameter | Type | Default | Description |
| enum |
| What to inspect |
| string | -- | Name or ID of a specific mesh/material/light/texture, for the |
| string | -- | Glob pattern matched against names, e.g. |
category accepts: summary, full, meshes, mesh_detail, materials,
material_detail, cameras, lights, animations, textures, physics,
post_processing, performance, scene_tree, webgl_errors.
summary and full return an overview of the whole scene; every other category drills into
one aspect. This is deliberately one parameterized tool rather than fifteen separate ones, to
keep the host's tool list short and the LLM's choice simple.
Parameter | Type | Default | Description |
| string | required | A JavaScript function body receiving |
Example argument:
(scene) => scene.meshes.map((m) => ({ name: m.name, pos: m.position.asArray() }))The return value is serialized to JSON. This is a development tool with no sandbox -- the code runs with full access to the page.
Parameter | Type | Default | Description |
| array of enum |
| Which views to capture |
| object | -- |
|
| number |
| Image width in pixels |
| number |
| Image height in pixels |
|
|
| Image format |
views accepts: current, front, top, side, isometric, depth, wireframe,
annotated. customCamera.projection is perspective or orthographic.
Images are written to disk and the tool returns file paths, not base64, so a multi-view capture does not flood the context window.
Parameter | Type | Default | Description |
|
|
| How much of the capture to return |
| boolean |
| Skip per-draw-call thumbnails for a faster capture |
summary returns counts and timings, shaders adds deduplicated shader source, full adds
per-draw-call WebGL state.
Registered only when GEMINI_API_KEY is set.
Parameter | Type | Default | Description |
| string | required | A specific question about the rendered scene |
| array of enum |
| Which renders to send to the model |
| boolean |
| Send structured scene data alongside the images |
|
|
| 512, 1024 or 2048 pixels |
views accepts: current, front, top, side, isometric, depth, annotated.
Good questions are concrete: "Are the shadows rendering correctly?", "Is the sphere positioned above the plane?", "Does the PBR material look metallic?"
All configuration is by environment variable, read once at startup.
Variable | Default | Description |
|
| Port for the HTTP + WebSocket server. Must be 1-65535 or startup fails with an explicit error. |
|
| Interface the server binds to. Loopback by default so the bridge is not reachable from other machines. Must be non-empty. |
| (none) | Comma-separated list of extra browser origins allowed to open a WebSocket. Loopback origins are always allowed. |
| (none) | Gemini API key. When unset, |
|
| Directory for screenshot output. Read with a default applied, but not validated and not yet consumed by any code path. |
|
| One of |
An invalid BABYLONJS_INSPECTOR_PORT, BABYLONJS_INSPECTOR_HOST or
BABYLONJS_INSPECTOR_LOG_LEVEL throws at startup rather than silently falling back to the
default.
The inspector exists to run code you asked for inside your own page, which means anything
that can reach the bridge can run babylonjs_scene_evaluate against your scene and feed the
answer to your LLM. Two defaults keep that surface small:
Loopback only. The HTTP + WebSocket server binds 127.0.0.1. Nothing else on your
network can reach it unless you set BABYLONJS_INSPECTOR_HOST yourself.
Origin-checked WebSocket upgrades. WebSockets are exempt from CORS, so the server
checks the Origin header on the upgrade itself. Origins on localhost, 127.0.0.1 or
[::1] (any port, any scheme) are accepted; every other origin is rejected with a 403
unless you list it in BABYLONJS_INSPECTOR_ALLOWED_ORIGINS. Requests that send no Origin
at all -- curl, a native client -- are accepted, because they can only arrive over the
bound interface.
The HTTP routes echo Access-Control-Allow-Origin only for an origin that passes the same
check; there is no wildcard CORS. If a second browser connects, the previously attached
socket is closed rather than silently displaced.
Alongside the WebSocket upgrade handler, the server exposes:
Endpoint | Purpose |
| Returns |
| Serves the browser client bundle, with CORS headers echoed back to any origin that passes the WebSocket origin check, so a local dev server can load it. Currently a stub. |
The package is built in phases. This is what actually runs today, verified against the source rather than the design document.
Working:
MCP server over stdio, with all six tools registered and their input schemas validated by zod
Conditional registration of babylonjs_scene_analyze based on GEMINI_API_KEY
HTTP + WebSocket server, /health endpoint, WebSocket upgrade handling, clean shutdown on
SIGINT and SIGTERM
The WebSocket wire protocol: command/response/event/ping/pong message types, strict parsing that rejects malformed messages, UUID request correlation, per-operation timeout tiers, and rejection of all pending requests when the socket closes
Configuration loading and validation from the environment
Graceful, readable error responses from every tool when the precondition it needs is missing
Not yet working:
The browser client is a stub. InspectorClient stores its options and does nothing else;
it does not open a WebSocket, discover a BabylonJS engine, or register command handlers.
GET /inspector-client.js serves a placeholder comment, not a bundle. The Vite plugin
injects a script that imports InspectorClient from that URL, so the injection wiring is in
place but the import has nothing to resolve.
Consequently every browser-dependent tool -- scene_inspect, scene_evaluate, screenshot,
spector_capture, scene_analyze -- returns "No BabylonJS scene connected" in practice.
babylonjs_connection_status is the only tool that returns real data today.
Spector.js is not integrated. There is no browser-side capture code, so hasSpector is
never set true.
Gemini analysis is not implemented. GeminiClient.analyzeScene rejects, and the
babylonjs_scene_analyze handler returns an explicit "not yet implemented" message even
with a valid API key and a connected browser.
Screenshots, depth maps, wireframe and annotated views have no capture implementation.
NullEngine (in-process, headless) runtime is designed for by the BabylonJSRuntime
interface but has no implementation; BrowserBridge is the only runtime.
BABYLONJS_INSPECTOR_SCREENSHOT_DIR and BABYLONJS_INSPECTOR_LOG_LEVEL are read but
unused. BABYLONJS_INSPECTOR_SCREENSHOT_DIR is not validated either -- any string, empty
included, is accepted.
Nothing is published to npm yet, so every npx and npm install route 404s. Build from
a checkout.
In short: the server half of the system is real, the browser half is scaffolding. Install this if you want to follow along or contribute; it is not yet useful for debugging a scene.
npm install # install dependencies
npm run build # compile TypeScript to dist/
npm run build:watch # compile in watch mode
npm test # run tests in watch mode
npm run test:run # run tests once
npm run coverage # run tests with a coverage report
npm run lint # eslint plus a type check
npm run lint:fix # auto-fix what eslint can
npm run typecheck # tsc --noEmit only
npm run clean # remove dist/ and coverage/Coverage thresholds are 80% lines, 80% functions, 80% statements and 75% branches, and they
are enforced: npm run coverage exits non-zero below any of them, and CI gates the release
on that job. The suite currently sits around 96%.
See CONTRIBUTING.md.
MIT -- see LICENSE.
Check the current connection state of the BabylonJS inspector. Returns whether a browser is connected, the engine type, rendering capabilities, and which tool categories are available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It transparently describes a read-only status operation and lists what will be returned: browser connection state, engine type, rendering capabilities, and available tool categories. It could explicitly state that it has no side effects, but for a status probe this is reasonably clear.
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 a single front-loaded sentence with no filler. It opens with the action, names the target, and compactly lists the return areas, making every phrase useful.
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?
For a zero-parameter status probe with no output schema, the description is nearly complete: it states the action and the high-level return contents. It could name the specific tool categories available, but that is an enhancement rather than a necessary fix.
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 tool has zero parameters and the input schema is empty, so the schema already covers everything needed. With no parameters to document, the description does not need to compensate for any parameter gaps.
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 a specific verb, 'Check', and a specific resource, 'current connection state of the BabylonJS inspector'. It also enumerates the returned contents, which clearly distinguishes it from the sibling action-oriented tools like babylonjs_scene_inspect and babylonjs_screenshot.
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 intended use is implied: check connection state before using inspector tools. However, the description does not explicitly say when to use it versus alternatives or name any exclusions, so the agent must infer the usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a JavaScript function against the BabylonJS scene. The function receives (scene, engine, BABYLON) as arguments. Return values are serialized to JSON. Use this for custom queries or operations not covered by other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| function | Yes | JavaScript function body. The function receives (scene, engine, BABYLON) as arguments. Example: '(scene) => scene.meshes.map(m => ({name: m.name, pos: m.position.asArray()}))' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that arbitrary JavaScript is executed against the scene and that return values are JSON-serialized, which is important. However, it does not mention potential side effects, mutation of the scene, error behavior, security implications, or asynchronous execution, all of which are significant for a code-evaluation tool.
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 tight sentences with no wasted words. It front-loads the action, then covers arguments, return behavior, and intended use. Every sentence earns its place and the structure helps an agent quickly parse the tool's purpose.
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?
The description covers the essentials for a basic call: the function body, input arguments, and JSON return. However, for a tool that executes arbitrary JavaScript, important context is missing—such as whether scene changes persist, what happens on exceptions, and any timeout or safety constraints. Given no output schema and no annotations, this is a noticeable gap.
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%, and the schema already documents the 'function' parameter with a detailed example. The tool description repeats the function signature (scene, engine, BABYLON) without adding new information about parameter format or constraints. This meets the baseline for full schema coverage but provides no extra semantic value.
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 opens with a specific verb and resource: 'Execute a JavaScript function against the BabylonJS scene.' It clearly states what the tool does, names the arguments passed to the function, and explains the return serialization. It also distinguishes itself from sibling inspection/capture tools by positioning itself for 'custom queries or operations not covered by other 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?
The description gives an explicit usage condition: 'Use this for custom queries or operations not covered by other tools.' This tells an agent when this escape-hatch tool is appropriate, though it does not name the sibling alternatives or explicitly say when not to use it. That slight lack of specificity keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the BabylonJS scene. Use 'summary' for an overview, 'full' for complete scene graph, or drill into specific categories: meshes, mesh_detail, materials, material_detail, cameras, lights, animations, textures, physics, post_processing, performance, scene_tree, webgl_errors. Use 'target' for specific items and 'filter' for glob-based name filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Glob pattern to filter results by name (e.g., 'wall*', '*metal*') | |
| target | No | Name or ID of a specific mesh/material/light/texture to inspect in detail | |
| category | No | What to inspect. 'summary' for overview, 'full' for complete scene graph. Other categories drill into specific scene aspects. | summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Inspect' implies a read-only operation, and the category list clarifies what will be examined, but it does not explicitly promise no side effects, warn about the cost of 'full', or describe the output shape. This is adequate but not rich.
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?
Three sentences, each earning its place: an action statement, a category menu, and parameter usage. It is compact, front-loaded, and avoids repeating schema metadata unnecessarily.
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?
For a read-only inspection tool with no required parameters, the description covers the main invocation choices and provides enough context to select summary, full, or a drill-down category. It leaves minor gaps: no output format, no explicit combination rules for target/filter with categories, and no caveat about potentially expensive operations like the full scene graph.
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%, so the schema already documents category, target, and filter. The description restates the intended use of target and filter and adds conceptual framing, but it does not provide material new semantic information 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 opening sentence 'Inspect the BabylonJS scene' names a specific action and resource, and the category list makes the object of inspection concrete. It does not explicitly contrast with sibling tools like babylonjs_scene_evaluate or babylonjs_screenshot, but the verb and categories make the tool's role clear.
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?
It provides explicit guidance for choosing a category: 'summary' for overview, 'full' for complete scene graph, and named categories for drilling into specific aspects. It also instructs when to use target and filter. It does not state when this tool should be preferred over sibling tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture one or more screenshots of the BabylonJS scene. Supports multiple preset camera angles, depth maps, and custom camera positions. Screenshots are saved to the tmp/ directory and file paths are returned. Only available when a browser with rendering is connected.
| Name | Required | Description | Default |
|---|---|---|---|
| views | No | ||
| width | No | ||
| format | No | png | |
| height | No | ||
| customCamera | No | Custom camera position for a screenshot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the burden of behavioral disclosure. It clearly states that screenshots are saved to tmp/, that file paths are returned, and that a rendering browser is required. It does not cover failure modes, file naming, cleanup, or error cases, so it stops short of a 5.
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?
Three substantive sentences with no filler. The core action is front-loaded, followed by capabilities, output behavior, and a precondition. Every sentence earns its place.
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?
For a screenshot tool with no required parameters and a nested optional customCamera object, the description covers purpose, output location, returned values, and a critical prerequisite. It is slightly light on the exact shape of returned paths and how multiple views map to outputs, but an agent still has enough to select and invoke it correctly.
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 only 20%, with only customCamera described. The description partially compensates by explaining that multiple views, preset angles, depth maps, and custom camera positions are supported, but it does not add meaningful semantics for width, height, format, or the individual view enum values beyond what the schema already exposes.
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 a clear action and resource: 'Capture one or more screenshots of the BabylonJS scene.' It also names concrete capabilities (preset angles, depth maps, custom camera positions) that distinguish it from scene inspection or connection tools, though it does not explicitly contrast it with a sibling.
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?
It provides an explicit precondition and negative condition: 'Only available when a browser with rendering is connected.' This helps the agent avoid calling it at the wrong time. It implies use whenever a visual snapshot is needed, but it does not name alternative tools or when to prefer them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a WebGL frame using Spector.js for low-level rendering inspection. Returns draw call count, shader source code, WebGL state, texture bindings, and performance data. Only available when a browser with WebGL is connected.
| Name | Required | Description | Default |
|---|---|---|---|
| detailLevel | No | 'summary' for stats, 'shaders' for shader source code, 'full' for everything | summary |
| quickCapture | No | Skip per-draw-call thumbnails for faster capture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does disclose what the tool returns and its availability precondition, which is useful. However, it does not mention potential side effects, performance impact, whether capture pauses rendering, or how the data is returned. Partial transparency only.
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 compact sentences that front-load the main action and rationale, then list outputs and a key precondition. Every sentence earns its place with no filler or redundancy.
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?
This tool has no output schema, so the description correctly enumerates the returned data categories (draw call count, shader source, WebGL state, texture bindings, performance data) and the runtime requirement. It could additionally explain how the capture affects the scene or how to choose between this and scene_inspect/screenshot, but the essential invocation context is present.
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%: both detailLevel and quickCapture have descriptive text and detailLevel has an enum with meanings. The description itself adds no parameter-level information, so a baseline 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?
The description names a specific verb ('Capture'), resource ('a WebGL frame'), and technique ('using Spector.js'), and clarifies the purpose as 'low-level rendering inspection'. This distinguishes it from sibling tools like babylonjs_screenshot or babylonjs_scene_inspect, especially by enumerating rendering-specific outputs.
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 gives clear context by stating the tool is for low-level rendering inspection and only available when a browser with WebGL is connected. It does not explicitly enumerate sibling alternatives or when-not-to-use conditions, so it falls short of a 5, but the intended usage is clearly communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0babylonjs_connection_statusbabylonjs_scene_evaluatebabylonjs_scene_inspectbabylonjs_screenshotbabylonjs_spector_captureEach tool has a distinct primary purpose: status, inspection, evaluation, screenshots, and WebGL capture. scene_inspect and scene_evaluate have some potential overlap since both query the scene, but the descriptions clearly separate structured inspection from custom JavaScript execution.
All tools share the babylonjs_ prefix, and most follow a scene/domain + action pattern, such as scene_inspect and scene_evaluate. However, babylonjs_screenshot and babylonjs_connection_status break the verb-noun pattern slightly, making the naming mostly but not fully consistent.
Five tools is a well-scoped set for an inspector-focused MCP server. Each tool covers a major capability area without unnecessary redundancy, and the count feels appropriate for the server's purpose.
The tool surface covers connection status, scene inspection, custom evaluation, screenshots, and low-level WebGL capture, which covers the core inspection workflow. Direct mutation tools are absent, but babylonjs_scene_evaluate provides a flexible escape hatch, so major workflows are not blocked.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Generate, edit, and deploy immersive 3D/WebGL web projects from any MCP assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/apowers313/babylonjs-inspector-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
