Skip to main content
Glama
Erodenn

Godot MCP Runtime

by Erodenn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

validate

Read-only

Checks GDScript syntax and scene integrity using headless Godot, returning parse errors and structural problems early to prevent runtime failures.

Instructions

Validate GDScript syntax or scene integrity using headless Godot. Use before attach_script or run_script to catch parse errors early. Give exactly one of scriptPath, source, or scenePath, or a targets array validated in one Godot process. Returns { valid, errors } for one target, { results: [{ target, valid, errors }] } for a batch. An errors entry is { line?, message } for a parse error, or { check, problem?, message } for a checks[] finding. checks requires scenePath and instantiates the scene, running each attached script's _init(). Any parse error yields valid:false.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
checksNo[single, requires scenePath] Structural and signal-verification checks to run against the scene. Types: "structure" (validate node tree against a schema) and "signals" (verify signal connections and handler methods, optional nodePath scope). Merged into the errors array with a "check" discriminator.
sourceNo[single] Inline GDScript source code to validate. Written to a temporary file and validated against the project.
targetsNo[batch] Array of targets to validate in a single Godot process. Each item must have exactly one of: scriptPath, source, or scenePath.
scenePathNo[single] Path to a .tscn scene file relative to the project to validate (e.g. "scenes/main.tscn")
scriptPathNo[single] Path to a .gd file relative to the project to validate (e.g. "scripts/player.gd")
projectPathYesPath to the Godot project directory

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.8.0
    • addedInput schema / properties / checks
      Added value: +{
+  "description": "[single, requires scenePath] Structural and signal-verification checks to run against the scene. Types: \"structure\" (validate node tree against a schema) and \"signals\" (verify signal connections and handler methods, optional nodePath scope). Merged into the errors array with a \"check\" discriminator.",
+  "items": {
+    "properties": {
+      "nodePath": {
+        "description": "[signals] Optional node path to scope the check to a subtree (e.g. \"root/HUD\")",
+        "type": "string"
+      },
+      "schema": {
+        "description": "[structure] Recursive node schema: { type?: string, children?: Schema[], hasProperty?: string }. Checks the root node and subtree.",
+        "type": "object"
+      },
+      "type": {
+        "description": "The kind of check to run",
+        "enum": [
+          "structure",
+          "signals"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "type"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / targets / items / properties / checks
      Added value: +{
+  "description": "[requires scenePath] Structural / signal checks for this target, run in the same Godot process as the rest of the batch. Same shape as the top-level checks array.",
+  "items": {
+    "properties": {
+      "nodePath": {
+        "description": "[signals] Optional node path to scope the check to a subtree (e.g. \"root/HUD\")",
+        "type": "string"
+      },
+      "schema": {
+        "description": "[structure] Recursive node schema: { type?: string, children?: Schema[], hasProperty?: string }. Checks the root node and subtree.",
+        "type": "object"
+      },
+      "type": {
+        "description": "The kind of check to run",
+        "enum": [
+          "structure",
+          "signals"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "type"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / targets / items / properties / scenePath / description
      Previous value: -"Path to a .tscn file relative to the project"New value: +"Path to a .tscn scene file relative to the project"
  2. Addedv3.1.1
  3. Removedv3.0.0
  4. Addedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses exact return shapes for single and batch calls, the discriminated error entry format, and the non-obvious behavior that checks instantiate the scene and run each script's _init(). It also clarifies that any parse error yields valid:false. No contradiction with annotations.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, usage timing, input constraints, return formats, and special behavior are each covered once and in a logical order. It front-loads the core action before details.

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?

With no output schema and six parameters, the description fully compensates by specifying single vs. batch result shapes, error entry variants, and check execution behavior. The only implicit point is that check findings likely also set valid:false, but this is reasonably inferable from the stated error structure.

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?

All six parameters are already described in the schema, so baseline is 3. The description adds critical semantics the schema alone does not express: the mutually-exclusive one-of rule and the batch optimization of 'targets array validated in one Godot process.' This is meaningful but not a huge departure from the existing schema coverage.

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?

The description opens with a specific verb and resource: 'Validate GDScript syntax or scene integrity using headless Godot.' It clearly distinguishes the tool from siblings like run_script and check_project by naming their relationship ('Use before attach_script or run_script').

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: 'Use before attach_script or run_script to catch parse errors early.' It also states the key input constraint ('Give exactly one of scriptPath, source, or scenePath, or a targets array'), preventing invalid calls.

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