Skip to main content
Glama
Sign In
Godot-MCP

Godot-MCP

by IvanMurzak
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Script / Validate

script-validate
Read-onlyIdempotent

Validates GDScript files and returns structured parse/compile diagnostics for one res:// script or the whole project, so agents can detect errors instead of assuming the game runs.

Instructions

Validate GDScript ('.gd') files and return STRUCTURED parse/compile diagnostics — the on-demand 'is the project error-free?' query. Closes the gap where the agent gets NO feedback on GDScript parse errors and assumes the game runs fine. Inputs:

  • 'scriptPath' (optional): a single res:// '.gd' path to validate. Omit to scan every '.gd' under res:// (capped at FullScanFileCap). Result (ScriptDiagnosticsResult): 'ok' (true when no errors), 'diagnostics' [{ path, line, message, severity }], counts, a 'truncated' flag (true when a full scan hit the file cap, so 'ok' is NOT a whole-project all-clear), and a 'fidelity' note:

  • Godot 4.5+: 'Precise' — exact line + message captured via the engine Logger hook.

  • Godot < 4.5: 'Coarse' — per-file pass/fail with the engine error code (no line/message text). GDScript warnings (unused variables, shadowed names, … as enabled in Project Settings → Debug → GDScript) come back with severity Warning on Godot 4.5+ for scripts without errors (res://addons/ skipped like the editor does); they do not make 'ok' false. C# ('.cs') files are NOT validated here (Godot has no in-editor C# compiler to reach cheaply); their compile errors surface through the project build. Pair with the RQL 'console' source (rql-query 'console | where logType == "Error"'), which on Godot 4.5+ also captures engine GDScript parse errors passively.

Input Schema

NameRequiredDescriptionDefault
scriptPathNoOptional single res:// '.gd' script path to validate, e.g. 'res://scripts/player.gd'. Omit (null/empty) to scan every '.gd' file under res://.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.35.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds substantial behavior: full-scan file capping with a 'truncated' flag that invalidates a whole-project all-clear, version-dependent fidelity (Precise vs Coarse diagnostics on Godot <4.5), warning severity that does not flip 'ok', and res://addons/ skipping. These are exactly the caveats an agent could otherwise misread as success signals.

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?

Front-loaded with the verb and result shape, then cleanly sectioned into Inputs and Result. It is long and occasionally editorial ('Closes the gap where the agent gets NO feedback', the GOOD-word caps), but nearly every clause carries operational information.

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?

There is no output schema, and the description compensates by enumerating the result fields (ok, diagnostics shape, counts, truncated, fidelity) and their semantics. Version-gated behavior, warning handling, and the C# gap are all covered — nothing an agent needs to interpret a clean or truncated 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% and its own description already explains omit-to-scan-all, so the baseline is 3. The description adds real context beyond the schema: the omission path is bounded by FullScanFileCap, and that cap interacts with the 'truncated' result flag, which the schema does not mention.

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 ('Validate GDScript .gd files') plus the exact return shape (structured parse/compile diagnostics). It explicitly excludes C# ('.cs') files, which separates it from the sibling script-build, and the framing as the 'is the project error-free?' query distinguishes it from script-execute and script-read.

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?

Gives explicit when-to-use ('on-demand is the project error-free check') and when-not-to (C# files, which surface through the project build). It also names a complementary path — pairing with rql-query on the 'console' source — so the agent knows how to cover what this tool misses.

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