Skip to main content
Glama
Sign In
Godot-MCP

Godot-MCP

by IvanMurzak
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Screenshot / Isolated Node

screenshot-isolated
Read-onlyIdempotent

Render a single Node3D in isolation from a chosen camera angle, auto-framed to its bounding box, and return a PNG for inspection without mutating the edited scene.

Instructions

Render a target Node3D in ISOLATION (only the target is visible, in its own world) from a chosen camera angle, framed automatically to its bounding box, lit by a default directional light, and return the result as a PNG image for direct LLM inspection. Identify the target with 'nodeRef'. Choose the view with 'cameraView' (Front/Back/Left/Right/Top/Bottom). Pick a 'background' (SolidColor or Transparent) and, for SolidColor, a hex 'backgroundColor'. The target is rendered via a temporary off-screen copy, so the edited scene is never mutated. Output is a square 'resolution'x'resolution' PNG, capped to keep the response transportable. NOTE: rendering needs a real GPU — a Godot launched with '--headless' yields an empty image, surfaced here as a structured error rather than a blank PNG.

Argument types — give these arguments as RQL values (as in rql-mutate): {key: value, …}, [a, b], "text", 1.5, true, ref("Node3D#12") from a query result, godot.find("Name"); leave out keys you do not need: NodeRef — a node: ref("Node3D#12") from a query, godot.find("Name"), an instance id, or its path below the scene root as text ("Level/Player")

Input Schema

NameRequiredDescriptionDefault
nodeRefYesReference to the target Node3D to render in isolation (instanceId preferred, else path). RQL: NodeRef
paddingNoFraming multiplier around the object. 1.0 = tight fit, 1.5 = 50% extra space. Default: 1.2.
backgroundNoBackground mode for the render: SolidColor (default) or Transparent.
cameraViewNoCamera angle relative to the target's bounding box. Default: Front.
resolutionNoOutput image resolution in pixels (width = height). Default: 512.
fieldOfViewNoCamera vertical field of view in degrees. Default: 60.
farClipPlaneNoFar clip plane distance. Default: 4000.
nearClipPlaneNoNear clip plane distance. Default: 0.05.
backgroundColorNoHex background color (e.g. '#404040'). Used only when background is SolidColor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.35.1

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/non-destructive, but the description adds substantive behavior: rendering uses a temporary off-screen copy so the edited scene is never mutated, output is capped for transportability, and missing GPU support surfaces as a structured error rather than a blank PNG. Those are exactly the traits an agent cannot derive from the annotation flags.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core sentence is front-loaded and dense with useful facts, and the GPU caveat is correctly placed at the end. The trailing 'Argument types — give these arguments as RQL values' block is boilerplate that duplicates framework-wide conventions rather than this tool's specifics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no output schema, the description still covers the return value (square resolution x resolution PNG, capped), the non-mutation guarantee, and the failure mode. Nothing an agent needs to decide whether to call it or to interpret the result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining that nodeRef accepts ref() from a query, godot.find(), an instance id, or a scene-relative path, and that backgroundColor only applies when background is SolidColor. It stays silent on padding, fieldOfView, and the clip planes, leaving those entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Render a target Node3D in ISOLATION') plus scope constraints ('only the target is visible, in its own world') and the output form (PNG). The isolation scope is what separates it from screenshot-camera and screenshot-viewport without the agent needing to open either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear conditions of use — pick a node, pick a view, pick a background — and an explicit environment prerequisite (needs a real GPU; '--headless' fails). It never names screenshot-camera or screenshot-viewport, so the choice between the three screenshot tools remains an inference from the word 'isolation' rather than an explicit routing rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools