Godotwright

Overview Schema Source Related Servers Discussions Admin

Ask Godot's GDScript language server

godot_code

Idempotent

Get engine-exact GDScript diagnostics, type hovers, definitions, and completions from Godot's language server, including analysis of unsaved code.

Instructions

Engine-exact answers from Godot 4.7's own GDScript language server (kept warm for 10 minutes; the first call takes a few seconds). op diagnostics: errors and warnings at the project's warning levels, as res://x.gd:12:5: warning [UNUSED_VARIABLE] ..., for file or every script. op hover: the type or signature at line/column (1-based; a tab is one column). op definition: where the name there is declared, as res://file:line, or that it is an engine symbol. op completion: what can follow there (members after a dot, node paths after $), up to limit. Pass code to analyse unsaved text as file without writing it. Needs Godot. Like opening the editor, Godot imports the project: it updates .godot/ and adds a missing .import file next to each asset and a missing .uid file next to each script. A new class_name, a changed project.godot or a new asset restarts the server. Without Godot use godot_review; to load scenes too use godot_check.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "op": "<op>"
    },
    "name": "godot_code"
  }
}

Input Schema

Name	Required	Description
`op`	Yes	diagnostics, hover, definition or completion
`code`	No	unsaved GDScript to analyse as `file` instead of the file on disk; nothing is written
`file`	No	the .gd file: res:// path or a path (diagnostics without it: every script)
`line`	No	1-based line (hover, definition, completion)
`path`	No	project folder, or a file or folder inside it (relative to the server's folder; default: the current project)
`limit`	No	completion: most items shown (default 40)
`column`	No	1-based column; a tab is one column (hover, definition, completion)

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.6.0Nov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false, idempotent, non-destructive; the description supplies the substance behind that — Godot imports the project, updating .godot/ and adding missing .import files next to assets and .uid files next to scripts, which explains why readOnlyHint is false. It also discloses cold-start latency, the 10-minute warm window, and the restart triggers (new class_name, changed project.godot, new asset). That is exactly the behavioral context annotations cannot carry.

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 value proposition and latency caveat, then structured op-by-op in a scannable order, and closed with sibling alternatives. Dense telegraphic style suits a reference; the only deduction is minor duplication of schema-stated details such as '1-based; a tab is one column'.

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 7-parameter, multi-op tool with no output schema, the description covers return shapes per op, prerequisites (Needs Godot), side effects on the project directory, latency behavior, and alternatives — everything an agent needs to call it correctly and interpret results.

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

Parameters3/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, and most of the description's parameter detail (1-based line/column, tab as one column, limit, diagnostics-without-file meaning, `code` writes nothing) restates the schema verbatim. It does add op-to-parameter mapping in prose, but that mapping is largely inferable from the schema's own parentheticals.

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 names the specific resource (Godot 4.7's own GDScript language server) and enumerates the four operations with concrete semantics for each: diagnostics returns `res://x.gd:12:5: warning [UNUSED_VARIABLE]`, hover returns a type/signature, definition returns a declaration site, completion returns what can follow a dot. It also explicitly distinguishes itself from sibling tools godot_review and godot_check.

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?

It gives explicit routing: 'Without Godot use godot_review; to load scenes too use godot_check', plus per-op guidance (diagnostics without `file` covers every script; `code` for unsaved text; completion after a dot or after $). The agent knows which op to pick and when to leave this tool entirely.

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