Provides tools for Godot Engine development, including running unit tests with GUT, checking for syntax errors, importing assets, running scenes, and exporting projects.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Godot MCP Server run all unit tests and report the results"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that provides tools for Godot Engine development.
godot_run_tests - Run GUT (Godot Unit Test) tests and get structured results
godot_check_errors - Check for parse/syntax errors without running the game
godot_import - Import/reimport assets
godot_run_scene - Run a specific scene
godot_export - Export project to a platform
Related MCP server: godotlens-mcp
cd mcp/godot-mcp
uv pip install -e .Or with pip:
pip install -e mcp/godot-mcpAdd to your Claude Code MCP configuration (~/.claude/mcp.json):
{
"mcpServers": {
"godot": {
"command": "uv",
"args": ["run", "--directory", "/path/to/mcp/godot-mcp", "godot-mcp"],
"env": {
"QT_QPA_PLATFORM": "xcb",
"__GLX_VENDOR_LIBRARY_NAME": "mesa"
}
}
}
}Or if installed globally:
{
"mcpServers": {
"godot": {
"command": "godot-mcp"
}
}
}Once configured, Claude Code can use these tools:
Use godot_run_tests to run the unit testsUse godot_check_errors to check for parse errorsUse godot_run_scene to run the gamePython 3.10+
Godot 4.x installed and in PATH
GUT (Godot Unit Test) addon for test functionality
MIT
Check a Godot project for parse errors and syntax issues without running the game.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | No | Path to the Godot project directory (containing project.godot). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only, non-destructive operation ('Check... without running the game'), which is appropriate for a static analysis tool. However, it doesn't mention potential side effects like file system access, performance characteristics, or error handling behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the tool's purpose, scope, and limitation. Every word earns its place, with no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and no annotations, the description provides good context about what the tool does and its non-execution nature. However, it doesn't describe what the output looks like (e.g., error list, success/failure status) or potential limitations, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'project_path' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline score of 3 for high schema coverage without providing additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Check') and resource ('Godot project'), specifying what it checks for ('parse errors and syntax issues') and what it doesn't do ('without running the game'). It distinguishes itself from siblings like godot_run_scene and godot_run_tests by emphasizing it's a static analysis tool rather than execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('Check a Godot project for parse errors and syntax issues') and implicitly distinguishes it from execution tools by stating 'without running the game.' However, it doesn't explicitly mention when NOT to use it or name specific alternatives among siblings for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a Godot project to a specific platform.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | No | Path to the Godot project directory. | |
| preset | Yes | Export preset name (as defined in export_presets.cfg). | |
| output_path | Yes | Output file path for the export. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the export action but fails to describe critical behaviors: whether this is a destructive operation (overwrites output files), requires specific permissions, has side effects on the project, or includes error handling. This leaves significant gaps for a tool that performs file system operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs export operations (potentially involving file system changes and platform-specific builds) with no annotations and no output schema, the description is insufficient. It lacks details on return values, error conditions, platform support, or dependencies like export preset configuration, leaving the agent with incomplete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all three parameters well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., format examples, constraints, or relationships between parameters), so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Export') and resource ('a Godot project') with the specific target ('to a specific platform'), making the purpose immediately understandable. It distinguishes from siblings like 'godot_import' (import vs export) and 'godot_run_scene' (run vs export), though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'godot_check_errors' or 'godot_run_tests', nor does it mention prerequisites such as having a configured export preset. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import/reimport assets in a Godot project. Useful after adding new files.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | No | Path to the Godot project directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'useful after adding new files,' which adds some context about timing, but lacks details on permissions needed, whether it's destructive (e.g., overwrites existing assets), rate limits, or what the import process entails (e.g., formats supported, error handling). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two concise sentences that directly state the purpose and usage context without unnecessary elaboration. Every sentence adds value, making it efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (importing assets, likely a mutation), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and usage timing but misses behavioral details like side effects or return values. For a tool with no structured safety or output information, it should provide more context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, providing a clear definition for 'project_path.' The description doesn't add any parameter-specific details beyond what the schema already covers, such as explaining how the path is used or format requirements. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Import/reimport assets in a Godot project,' specifying both the action (import/reimport) and resource (assets in Godot project). It distinguishes from siblings like godot_check_errors or godot_run_scene by focusing on asset management rather than error checking or execution. However, it doesn't explicitly differentiate from godot_export, which might also involve asset handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage with 'Useful after adding new files,' indicating when to use this tool. It implies an alternative workflow (not using it if no new files are added), but doesn't explicitly state when not to use it or name specific alternatives among siblings like godot_check_errors for validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a specific scene in the Godot project (non-headless, will open a window).
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | No | Path to the Godot project directory. | |
| scene | No | Scene path to run (e.g., 'res://src/GameLoop.tscn'). If not provided, runs main scene. | |
| timeout | No | Timeout in seconds. Default: 60 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the key behavioral trait that execution is 'non-headless, will open a window' - important runtime behavior. However, it doesn't mention what happens on timeout, whether the tool blocks until scene completion, error handling, or resource cleanup. For a tool that launches graphical applications, more behavioral context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes the critical behavioral detail about window opening. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate but minimal context. It covers the core purpose and key runtime behavior but doesn't address error conditions, return values, or integration considerations. Given the complexity of launching graphical applications, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Run a specific scene') and resource ('Godot project'), and distinguishes it from siblings by specifying it's 'non-headless, will open a window' - which differentiates it from test-running or headless execution tools. The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'non-headless, will open a window' which suggests this is for visual testing/demo purposes rather than automated testing. However, it doesn't explicitly state when to use this vs. alternatives like godot_run_tests or godot_export, nor does it provide any exclusion criteria or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run GUT (Godot Unit Test) tests for a Godot project. Returns test results including pass/fail counts and any failures.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | No | Path to the Godot project directory (containing project.godot). If not provided, searches upward from current directory. | |
| test_dir | No | Directory containing tests (relative to project). Default: 'res://test/unit' | res://test/unit |
| test_script | No | Specific test script to run (e.g., 'test_combatant.gd'). If not provided, runs all tests. | |
| timeout | No | Timeout in seconds. Default: 120 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns test results including pass/fail counts and failures, which adds some context beyond the input schema. However, it lacks details on execution behavior (e.g., whether it runs tests synchronously, potential side effects, or error handling), leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and efficiently adds return value information in the second. Both sentences earn their place by providing essential context without redundancy, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and return values but lacks details on behavioral aspects like execution flow or error conditions. Without an output schema, it should ideally explain return formats more thoroughly, but it provides a basic overview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing full documentation for all 4 parameters. The description does not add any additional meaning or semantics beyond what the schema already specifies, such as explaining parameter interactions or usage nuances. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Run GUT (Godot Unit Test) tests') and resource ('for a Godot project'), distinguishing it from sibling tools like godot_export or godot_run_scene. It precisely defines the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for testing Godot projects but does not explicitly state when to use this tool versus alternatives like godot_check_errors or godot_run_scene. There is no guidance on prerequisites, exclusions, or specific contexts, leaving usage inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
godot_check_errorsgodot_exportgodot_importgodot_run_scenegodot_run_testsEach tool has a clearly distinct purpose with no overlap: checking errors, exporting projects, importing assets, running scenes, and running tests. The descriptions specify unique actions (e.g., parse errors vs. export vs. import), making it easy for an agent to select the correct tool without confusion.
All tool names follow a consistent 'godot_verb_noun' pattern (e.g., godot_check_errors, godot_export, godot_import), using snake_case throughout. This predictability enhances readability and reduces cognitive load for agents when scanning the toolset.
With 5 tools, the count is well-scoped for a Godot project management server, covering key development tasks. It's slightly lean but reasonable, as each tool earns its place without feeling bloated or insufficient for common workflows like testing and deployment.
The toolset covers essential Godot project operations: error checking, exporting, importing, running scenes, and running tests. Minor gaps exist, such as no project creation or build management tools, but agents can work around these for core development tasks without significant failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
MCP Server for JFrog, providing tools for development and artifact management.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
Create, deploy, and operate MCP servers directly from your GitHub repositories.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/struktured-labs/godot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
