Loading ToolBench
MCP server giving AI agents Godot's own view of a GDScript project: navigation, diagnostics, engine API, and scene verification
GodotLens demonstrates strong definition quality with 25 well-named, consistently described tools targeting a specialized domain (GDScript/Godot development). All tools have explicit input schemas with type definitions and descriptions. Tool names follow verb_noun pattern (gdscript_*, godot_*, scene_*, project_*, debug_*), making intent clear. Descriptions are substantial (100-250 chars typical), explain WHEN to use each tool, and include important constraints (e.g., zero-based line numbers, need to call gdscript_sync_file after edits). Risk classifications (READ_ONLY, WRITE, REVERSIBLE) are documented. However, several gaps prevent higher scores: (1) output schemas are not documented in the visible source, only input schemas are shown; (2) error handling descriptions are minimal, tools state what they return but not how to recover from failures; (3) some parameters lack format constraints (e.g., 'file' path accepts 'Absolute or relative' but no pattern/examples); (4) no batch parameter variants for tools called in loops (e.g., gdscript_sync_files exists but gdscript_completion, gdscript_hover could benefit from batch operations); (5) composition details are sparse, unclear which tools chain naturally or what IDs/references downstream tools need.
Remove all breakpoints from a file. Returns: success status. Use to clear debugging markers.
Set breakpoints in a file. Returns: list of verified breakpoint locations. Use to pause the game at specific lines.
Start the Godot game and attach the debugger. Returns: confirmation and output from the game. Use to run the project and watch its output.
Get console output and errors from the running game. Returns: list of print() output, errors, and lifecycle events. Use to see what the game logged.
Stop the running game. Returns: confirmation. Use to stop a game that is running.
Get code completion suggestions at a position. Returns: list of completion candidates with type and documentation. IMPORTANT: Uses ZERO-BASED coordinates. Use to understand what can be typed at a position.
Navigate to the definition of a symbol at a given position. Returns: file path and line number where the symbol is defined. IMPORTANT: Uses ZERO-BASED coordinates (editor line 1 = pass line 0). Use when you need to find where a function, variable, or class is defined.
Output schemas not documented in visible source code. Only input schemas are shown; return types and field names for each tool are not specified.
Error handling and recovery guidance minimal. Tool descriptions state 'Returns: X' but lack guidance on handling failures, which tools to call if a lookup fails, or what to do when the Godot editor is disconnected.
No batch parameter variant for tools frequently called in loops. gdscript_hover, gdscript_completion, gdscript_signature_help lack array variants even though agents would naturally call them on multiple file positions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Get compile errors, warnings, and diagnostics for a file. Returns: list of problems with severity, message, and location. Use to understand what is broken in a file.
Search for files by name. Returns: list of matching .gd files. Use when you know part of a filename but not the full path.
Get type information and documentation for a symbol at a given position. Returns: type signature, documentation string, or description of the symbol. IMPORTANT: Uses ZERO-BASED coordinates. Use to understand what type a variable is, or what a function returns.
List all .gd files in the project. Returns: all script files. Use to explore the project structure.
Find all references to a symbol across the entire project. Returns: list of locations (file, line, character) where the symbol is used. IMPORTANT: Uses ZERO-BASED coordinates. Essential for impact analysis before refactoring: 'What code uses this symbol?'
Rename a symbol everywhere it is used in the project. Returns: file edits required to complete the rename. IMPORTANT: Uses ZERO-BASED coordinates. Does NOT apply the changes automatically — returns the edits so you can review and apply them.
Get function signature and parameter information at a call site. Returns: function name, parameters with types, and return type. IMPORTANT: Uses ZERO-BASED coordinates. Use when you need to know what parameters a function accepts.
Check connection status to the Godot LSP server. Returns: connection status, host, and port. Use this to verify Godot editor is running before using other tools. If disconnected, start Godot editor with your project open.
List all symbols (classes, functions, variables, signals, enums) in a file. Returns: symbol tree with name, kind, and line number for each symbol. Use to understand the structure of a file before making changes. WORKFLOW: gdscript_symbols to explore, then gdscript_hover or gdscript_definition for details.
Notify Godot that a .gd file has been edited and re-parse it. Returns: success status. IMPORTANT: Godot's LSP does not watch the filesystem. Always call this after editing a file and before expecting correct diagnostics or references. Use before calling gdscript_diagnostics, gdscript_references, or gdscript_definition on a file you just changed.
Notify Godot that multiple .gd files have been edited. Returns: success status. IMPORTANT: Godot's LSP does not watch the filesystem. Call this after bulk edits and before expecting correct diagnostics. Faster than calling gdscript_sync_file repeatedly.
Search Godot's built-in API documentation. Returns: signature, description, and doc URL for a class, method, signal, or property. Use to understand what is available in the Godot engine without leaving the editor.
Get full documentation for a Godot class: all methods, properties, signals, constants, and enums. Returns: structured class information including inheritance. Use to learn the complete API of a class.
Check if a class inherits from another. Returns: true/false and the full inheritance chain. Use to understand class relationships.
List all autoload (singleton) names defined in the project. Returns: autoload names and their associated scripts. Use to know what singletons are available.
List all input action names defined in the project. Returns: action names and their key bindings. Use to know what input actions are available for Input.is_action_pressed().
Get Godot's internal view of a scene: node tree, script attachments, and signal connections after inheritance is resolved. Returns: scene structure as Godot sees it at runtime. Use to understand inherited scenes and verify node setup.
Verify a scene's node connections are valid. Returns: list of problems (missing nodes, missing handlers, target has no script). Use before deploying scenes to catch signal connection errors that compile but fail at runtime.
File path parameter format not fully specified. Descriptions state 'Absolute or relative path to the .gd file' but lack examples, regex patterns, or clarification on path separators (/ vs \\).
Query parameter for godot_api and gdscript_find lacks format constraints. 'query' is free-form string; unclear if it is case-sensitive, supports regex, or has length limits.
Tool composition and chaining not explicitly documented. Unclear which tools naturally sequence (e.g., gdscript_find → gdscript_symbols → gdscript_hover), or what IDs/references each tool returns for downstream use.
State synchronization burden on LLM. Descriptions require agents to understand that Godot LSP does not watch the filesystem, forcing manual gdscript_sync_file calls. This is correct and well-documented, but places planning burden on the LLM.