Click on "Deploy 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 Analyze my main scene for performance issues"
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.
AI-Powered Development Assistant for Godot Game Engine
Transform your Godot development with intelligent AI assistance
Working with Godot can be challenging when you need to:
❌ Analyze complex project structures and scene hierarchies
❌ Debug cryptic error messages and performance issues
❌ Generate boilerplate code following Godot best practices
❌ Understand legacy codebases or inherited projects
❌ Optimize game performance without deep engine knowledge
Related MCP server: Godot MCP
Godot MCP Server bridges the gap between AI assistants and your Godot projects, providing:
✅ Intelligent Project Analysis: Deep understanding of your game architecture
✅ Smart Error Diagnosis: AI-powered debugging with actionable suggestions
✅ Code Generation: Templates and patterns following Godot conventions
✅ Performance Insights: Automated optimization recommendations
✅ Architecture Guidance: Best practices for scalable game development
No installation required! Run directly:
npx kooix-godot-mcp --project /path/to/your/godot/projectAdd to your Claude Desktop config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json
{
"mcpServers": {
"godot-mcp": {
"command": "npx",
"args": ["kooix-godot-mcp", "--project", "/path/to/your/godot/project"]
}
}
}Note: Replace /path/to/your/godot/project with the actual path to your Godot project directory.
npm install -g kooix-godot-mcpThen use in Claude Desktop config:
{
"mcpServers": {
"godot-mcp": {
"command": "godot-mcp",
"args": ["--project", "/path/to/your/godot/project"]
}
}
}npm install -g @telagod/kooix-godot-mcpgit clone https://github.com/telagod/kooix-godot-mcp.git
cd kooix-godot-mcp
npm install && npm run build
npm install -g .Project Configuration: Extract settings, autoloads, and metadata
Scene Architecture: Analyze node hierarchies and scene relationships
Script Analysis: Parse GDScript for methods, properties, and signals
Design Patterns: Identify architectural patterns and suggest improvements
Smart Templates: Generate classes following Godot conventions
🎯 Player Controllers with input handling
🏗️ Manager Singletons for game systems
🖼️ UI Components (Menus, Dialogs, HUD)
🎮 Game Objects with lifecycle management
Multiplayer Templates: Ready-to-use networking code
REST API Integration: HTTP client implementations
State Synchronization: Patterns for networked games
Performance Profiling: Identify bottlenecks in your code
Memory Management: Object pooling and resource optimization
Best Practices: Automated code quality suggestions
Performance Metrics: Real-time analysis of game systems
Error Analysis: Intelligent parsing of Godot logs
Crash Diagnostics: Root cause analysis for game crashes
Performance Issues: Memory leaks and frame rate problems
Code Quality: Static analysis and improvement suggestions
📚 Learn Godot best practices through generated examples
🔍 Understand existing project structures
🎓 Get explanations for complex game development concepts
🚀 Accelerate development with smart code generation
🔧 Debug complex issues with AI-powered analysis
📈 Optimize performance with detailed recommendations
🏗️ Architect scalable game systems
📋 Analyze and document legacy codebases
🔄 Maintain consistent coding standards
🤝 Onboard new team members faster
📊 Generate project health reports
Tool | Description | Use Case |
| Extract project configuration and metadata | Understanding project structure |
| Analyze scene files and hierarchies | Scene management and organization |
| Deep analysis of specific scene files | Debugging scene-related issues |
| Inventory all GDScript files | Code organization and refactoring |
| Parse script structure and patterns | Code quality and optimization |
| Create common script patterns | Rapid development and consistency |
| High-level architectural analysis | System design and planning |
| Create UI component templates | Interface development |
| Performance analysis and suggestions | Game optimization |
| Networking code templates | Multiplayer development |
| Error log analysis and solutions | Troubleshooting and debugging |
| Real-time debugging session | Interactive problem solving |
| Parse and interpret log files | Post-mortem analysis |
| Performance profiling and metrics | Optimization planning |
| Overall project quality assessment | Maintenance and planning |
extends CharacterBody2D
class_name PlayerController
@export var speed: float = 300.0
@export var health: int = 100
signal health_changed(new_health: int)
signal player_died
var _input_vector: Vector2
var _is_alive: bool = true
func _ready() -> void:
initialize_player()
func _process(delta: float) -> void:
if _is_alive:
handle_input()
update_movement(delta)
# ... complete implementation generatedextends Control
class_name GameHUD
@export var health_bar: ProgressBar
@export var score_label: Label
@export var timer_label: Label
func update_health(health: int) -> void:
if health_bar:
health_bar.value = health
# ... complete HUD system with animationsWe welcome contributions! Please see our Contributing Guide for details.
git clone https://github.com/telagod/kooix-godot-mcp.git
cd kooix-godot-mcp
npm install
npm run devMIT License - see LICENSE file for details.
Made with ❤️ for the Godot Community
Supercharge your game development with AI assistance
Analyze crash information and provide debugging guidance
| Name | Required | Description | Default |
|---|---|---|---|
| crashInfo | Yes | Crash dump or error information |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic function. It does not mention side effects, read-only nature, permission requirements, or output format. Since no annotations are provided, the description carries the full burden, which it fails to meet.
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, direct sentence that conveys the core purpose without extraneous words. It is appropriately concise for a simple tool, though it could include additional context without becoming verbose.
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 lack of an output schema, the description should explain the expected output or guidance format. It also does not clarify how this tool differs from similar siblings like 'analyze_error_log'. The description is insufficient for the tool's complexity and 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 input schema already provides a description for the single parameter 'crashInfo' with 100% coverage. The tool description adds no additional meaning beyond what the schema states, so a baseline score of 3 is appropriate.
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 action ('analyze') and resource ('crash information'), indicating it provides debugging guidance. However, it does not explicitly distinguish from the sibling tool 'analyze_error_log', which may have overlapping functionality.
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?
No guidance is provided on when to use this tool versus alternatives like 'analyze_error_log' or 'diagnose_project'. There is no mention of prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze Godot error logs and provide suggestions for fixes
| Name | Required | Description | Default |
|---|---|---|---|
| logContent | No | Error log content to analyze (optional - will try to find log file) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral cues. It implies a read-only analysis by stating 'provide suggestions for fixes', but it does not explicitly confirm non-destructive behavior, nor does it disclose if the tool modifies any state or requires specific permissions. The schema parameter note about 'will try to find log file' hints at file system interaction, but this is not clarified in the description.
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 sentence, which is concise but lacks structure. It does not front-load key details such as the input type or output format. While every word is necessary, the brevity results in under-specification rather than efficiency.
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 simple interface (one optional parameter, no output schema), the description is too sparse. It fails to explain what 'suggestions for fixes' look like, how the log content is used, or whether there are any limits. The agent would need to infer significant details to use the tool correctly.
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% for the single parameter 'logContent', which is already described as optional and will attempt to find a log file. The tool description adds no new semantic information beyond this, so it meets the baseline but does not enhance understanding.
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 it analyzes Godot error logs and provides suggestions for fixes. It uses a specific verb-resource combination that distinguishes it from siblings like analyze_crash_dump (crash dumps) and analyze_script (scripts). However, it could be more explicit about its unique role versus similar tools like diagnose_project or suggest_fix.
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?
No guidance is provided on when to use this tool versus alternatives, such as suggest_fix or diagnose_project. The description lacks instructions on prerequisites, input expectations, or exclusions, leaving the agent without context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze the overall game architecture including managers, scenes, and design patterns
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It does not state whether the tool is read-only, has side effects, or requires a specific project state. The description only mentions the scope of analysis without any safety or behavioral information.
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 immediately conveys the tool's purpose. It is appropriately sized with no wasted words, and the key information is front-loaded.
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?
There is no output schema, so the description should explain what the tool returns. It only describes the input scope (what it analyzes) but not the output format or structure. For a tool with no parameters, this is a significant gap that leaves the agent without expected return information.
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?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds value by specifying what is included in the analysis (managers, scenes, design patterns), which compensates for the lack of parameters. This provides meaningful context beyond the empty schema.
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 it analyzes game architecture, including managers, scenes, and design patterns. It uses a specific verb and resource, and the mention of 'managers, scenes, and design patterns' distinguishes it from sibling tools like analyze_scene or analyze_script, which are more narrow in scope.
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 its siblings (e.g., analyze_scene, analyze_script) or any contextual prerequisites. An agent would not know if this tool is appropriate for a given query without additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a specific scene file and return its structure
| Name | Required | Description | Default |
|---|---|---|---|
| scenePath | Yes | Relative path to the scene file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool returns structure, implying a read-only operation, but does not confirm idempotency, side effects, or performance implications. Minimal but not misleading.
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, front-loaded sentence. It contains no wasted words, but could be slightly more informative without losing conciseness.
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 that there is no output schema, the description should at least hint at what kind of structure is returned (e.g., list of objects, hierarchical). It also lacks any guidance on prerequisites or related tools. Incomplete for a tool with moderate complexity.
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% (one parameter with description). The tool description adds no additional meaning beyond the schema's 'Relative path to the scene file'. With full coverage, baseline 3 is appropriate.
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 action ('Analyze') and the target resource ('scene file'), and specifies the outcome ('return its structure'). This distinguishes it from siblings like list_scenes (which lists scenes) and analyze_script (which analyzes scripts).
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?
No guidance on when to use this tool versus alternatives. Does not mention situations where it is preferred over list_scenes or analyze_script, nor any preconditions or compatibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a GDScript file and return its structure
| Name | Required | Description | Default |
|---|---|---|---|
| scriptPath | Yes | Relative path to the script file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors beyond the name. It states it returns structure but does not specify read-only status, side effects, permissions, or what exactly 'structure' entails (e.g., AST, class hierarchy).
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 concise sentence with no redundant words. However, it could be more informative without being wordy.
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 no output schema, the description should explain what 'structure' means (e.g., list of classes, functions, AST). The tool has multiple sibling analysis tools, so specificity is needed to disambiguate. The current description is too vague for an AI agent to know what to expect.
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% for the single parameter. The description adds value by clarifying that it is a GDScript file (schema says 'script file'), narrowing the type. However, no additional formatting or validation details are given.
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 'Analyze' and the resource 'GDScript file' with the outcome 'return its structure'. It is distinct from sibling tools like analyze_crash_dump or analyze_scene, which target different resources.
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?
No guidance on when to use this tool versus similar siblings like analyze_game_architecture or analyze_scene. There is no mention of prerequisites, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform comprehensive project health diagnosis
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides no behavioral details (e.g., side effects, permissions, output format). A health diagnosis is likely read-only, but this is not stated.
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?
Single sentence, concise and front-loaded. However, it could be slightly more informative without losing conciseness.
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 no output schema or annotations, the description fails to explain what 'comprehensive health diagnosis' entails or what results are returned.
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 has no parameters, so coverage is 100%; the description adds no param-specific value but is not required to.
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?
Description 'Perform comprehensive project health diagnosis' gives a clear verb and resource, but does not distinguish it from sibling analysis tools like analyze_crash_dump or analyze_error_log.
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?
No guidance on when to use this tool vs. other analysis tools or get_project_info; the description lacks context-dependent recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate networking system templates for multiplayer games
| Name | Required | Description | Default |
|---|---|---|---|
| networkType | Yes | Type of networking system to generate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only says 'Generate networking system templates', without explaining what generating entails (e.g., file creation, project modification, network requirements). This leaves significant behavioral aspects unclear.
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 concise sentence, but it is too brief to adequately cover the tool's purpose and behavior. It sacrifices completeness for brevity.
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 simplicity (1 parameter, no output schema), the description is minimally adequate. However, it does not explain what the generated templates contain or how they affect the project, leaving room for improvement.
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 coverage is 100% with the parameter 'networkType' described as 'Type of networking system to generate' in the schema. The description adds no further detail about the enum values or their implications, so it meets the baseline but adds no extra value.
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 'Generate' and the resource 'networking system templates', which distinguishes it from sibling generation tools like 'generate_script_template' and 'generate_ui_component'. However, it specifies 'for multiplayer games' which may not fully cover the 'rest_api' option in the enum, causing slight ambiguity.
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?
No guidance is provided on when to use this tool vs alternatives, nor any prerequisites or exclusions. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a GDScript template for common patterns
| Name | Required | Description | Default |
|---|---|---|---|
| templateType | Yes | Type of script template to generate | |
| className | Yes | Name of the class | |
| extendsClass | No | Base class to extend from | Node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description is a single sentence with no behavioral details. It does not disclose effects (e.g., whether it creates files), output format, or any prerequisites. For a tool with no annotations, the description fails to compensate.
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?
Extremely concise at one sentence, front-loaded with the core action. However, it may be too minimal given the need for more detail in other dimensions.
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?
With three parameters, no output schema, and no annotations, the description is too sparse. It does not explain what 'common patterns' are, how the output is delivered, or how to use the generated template effectively.
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?
Input schema covers 100% of parameters with descriptions. The description adds context that the templates are for 'common patterns,' which slightly enriches the enum list but does not provide additional semantics beyond the schema.
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 it generates a GDScript template for common patterns. While it distinguishes from siblings like generate_network_system by specifying GDScript, it does not explicitly differentiate its scope from other pattern-specific tools.
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?
No guidance on when to use this tool versus alternatives. Siblings include generate_network_system and generate_ui_component, but the description offers no comparative context or scenarios for when generate_script_template is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate UI component templates for common game elements
| Name | Required | Description | Default |
|---|---|---|---|
| componentType | Yes | Type of UI component to generate | |
| componentName | Yes | Name of the UI component | |
| options | No | Additional options for component generation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Generate templates' without indicating whether this creates files, requires permissions, or has side effects. The mutation behavior is implied but not detailed.
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, front-loaded sentence that conveys the core purpose efficiently. It loses a point for not being slightly more detailed to aid selection.
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 no output schema and only a brief description, the tool lacks explanation of what templates are generated, format, or what options are available. For a generation tool with 3 parameters, more context is needed.
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 baseline is 3. The description adds no additional meaning beyond the schema; it simply repeats 'UI component templates' which is already captured. Parameters are well-described in the schema.
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 'Generate' and the resource 'UI component templates', with scope 'for common game elements'. It distinguishes from sibling tools like 'generate_network_system' and 'generate_script_template' which target different domains.
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?
No explicit guidance on when to use this tool versus alternatives. While it implies use for UI component creation, there is no mention of prerequisites, context, or exclusions. Sibling tools exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about an active debug session
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Debug session ID to query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral details such as error handling, authentication requirements, or side effects.
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 sentence, very concise. However, it is too minimal and lacks necessary detail, so it does not earn a 5.
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?
With no output schema and no description of return values, the description is incomplete. The tool's output structure is left unspecified.
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 coverage is 100% with a description for sessionId. The tool description adds no additional meaning beyond the schema, so baseline 3 applies.
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 'Get information about an active debug session', using a specific verb and resource. It distinguishes from sibling tools like start_debug_session and stop_debug_session.
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?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites or context for invoking this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Godot project information including configuration, autoloads, and metadata
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Get'), which is appropriate, but lacks detail on whether the tool has any side effects or prerequisites. Given the simplicity, it is acceptable but not fully transparent.
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 sentence that is concise and front-loaded with the verb 'Get' and the resource 'Godot project information'. No unnecessary words.
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 zero parameters and no output schema, the description is minimal but adequate for a simple query tool. However, it could mention the expected output format or structure to be more helpful. The context signals indicate no nested objects or enums, so the complexity is low.
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?
No parameters exist, so the baseline is 4. The description correctly indicates no arguments are needed, and the schema coverage is 100%.
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?
Clearly states it retrieves Godot project information, specifying types like configuration, autoloads, and metadata. However, it does not differentiate from sibling tools like analyze_game_architecture or diagnose_project, which could have overlapping purposes.
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?
No guidance on when to use this tool versus alternatives. Sibling tools have similar names and purposes, but the description provides no context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all scenes in the Godot project
| Name | Required | Description | Default |
|---|---|---|---|
| includeDetails | No | Include detailed scene structure information |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'List all scenes' implying a read operation, but lacks details on performance, pagination, or any side effects. Minimal 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?
Single, front-loaded sentence with no wasted words. Efficiently conveys the core functionality.
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 simplicity (one optional param, no output schema), the description is minimally adequate but omits what the list contains (e.g., names, paths) or any return format, leaving gaps for an agent.
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 coverage is 100% with one parameter (includeDetails) already well-described. The description adds no additional meaning beyond the schema, meeting the baseline of 3.
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 action (List), resource (all scenes), and scope (in the Godot project). It distinguishes itself from siblings like analyze_scene or list_scripts.
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?
No explicit guidance on when to use or when not to use this tool. While the purpose is clear, there are no mentions of context, prerequisites, or alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all GDScript files in the project
| Name | Required | Description | Default |
|---|---|---|---|
| includeAnalysis | No | Include script analysis (methods, properties, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits such as read-only nature, performance implications, or scope of listing (e.g., all directories recursively).
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?
Description is a single sentence with no wasted words. It is appropriately sized for the tool's simplicity.
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 simple tool with one optional parameter and no output schema, the description is adequate. It could mention whether listing is recursive or limited to root, but still covers the core functionality.
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 coverage is 100% for the single boolean parameter. Description adds no extra meaning beyond the schema's description of includeAnalysis. Baseline 3 is appropriate.
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?
Description clearly states the action 'List' and the resource 'all GDScript files', providing a specific verb and resource. It differentiates from sibling tools like 'list_scenes' which lists scenes, not scripts.
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?
No guidance on when to use this tool versus alternatives like 'analyze_script' or 'list_scenes'. The description lacks context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze project for performance issues and provide optimization recommendations
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only analysis by stating 'analyze... provide recommendations', but does not explicitly confirm no side effects or disclose any behavioral traits beyond the name.
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 sentence with zero wasted words. It is direct and front-loaded, effectively communicating the tool's purpose without redundancy.
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 low complexity (no parameters, no output schema, no annotations), the description is minimally viable. It covers the basic purpose but lacks details about return values, execution impact, or integration with sibling tools.
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 tool has no parameters, and the empty schema is fully covered. According to the rubric, 0 parameters earns a baseline of 4, and the description appropriately adds no further meaning since there are no parameters to document.
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 specifies the verb 'analyze' and resource 'project for performance issues', and it distinguishes from sibling tools like analyze_crash_dump and analyze_error_log by focusing on performance optimization.
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 suggest_fix or other analyze tools. It lacks explicit context, prerequisites, or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a debug session to monitor errors and warnings
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | No | Optional custom session ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fails to disclose behavioral implications such as whether starting a session collects data, impacts performance, or requires specific permissions. The term 'monitor' is vague.
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 with no wasted words. It could be slightly more informative but remains efficient.
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 simple tool with no required parameters and no output schema, the description is minimally adequate. However, it lacks behavioral context that would help an agent understand the tool's full scope.
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 one optional parameter. The description adds no additional meaning beyond the schema's minimal 'Optional custom session ID'. Baseline 3 is appropriate.
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 'start', the resource 'debug session', and the purpose 'to monitor errors and warnings'. It effectively distinguishes from sibling tools like 'stop_debug_session' and 'get_debug_session'.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when it might be inappropriate to start a session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop an active debug session and get results
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Debug session ID to stop |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'stop' and 'get results' but fails to disclose side effects (e.g., session destruction), required permissions, or what the results entail. Minimal behavioral insight for a mutation tool.
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?
Single sentence with 8 words, front-loaded with action and result. No superfluous information, highly efficient.
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?
Adequate for a simple tool with one parameter and no output schema. However, it lacks context on prerequisites (e.g., session must be active), error conditions, and specific result details. Sibling tools suggest additional context could be helpful.
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?
Input schema has 100% coverage with a clear parameter description. The tool description does not add additional meaning beyond the schema, which is acceptable. Baseline score of 3 is appropriate.
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?
Description clearly states the action 'Stop' and resource 'debug session' with the added result 'get results'. It effectively distinguishes from siblings like start_debug_session and get_debug_session.
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?
Implies usage when there is an active debug session to stop, but does not explicitly state when to use it versus alternatives like start_debug_session or get_debug_session. No exclusions or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific fix suggestions for error messages
| Name | Required | Description | Default |
|---|---|---|---|
| errorMessage | Yes | The error message to analyze | |
| context | No | Additional context about the error (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully convey behavioral traits. It fails to mention anything about the nature of suggestions, whether it modifies anything, or any side effects. This is a critical 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 a single, brief sentence, which is concise and front-loaded. However, it may be under-specified for the agent's needs, but conciseness itself is not penalized heavily.
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 no output schema and no annotations, the description should cover what the tool returns. It does not, leaving the agent without information on the format or details of fix suggestions. Incomplete for a tool with 2 parameters.
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 coverage is 100% with clear descriptions for both parameters. The tool description adds no extra meaning beyond what the schema already provides. Baseline 3 applies as it does not detract but adds no value.
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: 'Get specific fix suggestions for error messages'. It uses a specific verb ('get') and resource ('fix suggestions for error messages'), and distinguishes from siblings like analyze_error_log and analyze_crash_dump which are analysis-only.
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?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or context for ideal use.
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.
v1.1.17analyze_crash_dumpanalyze_error_loganalyze_game_architectureanalyze_sceneanalyze_scriptdiagnose_projectgenerate_network_systemgenerate_script_templategenerate_ui_componentget_debug_sessionget_project_infolist_sceneslist_scriptsoptimize_game_performancestart_debug_sessionstop_debug_sessionsuggest_fixScored across 17 tools
Each tool has a clearly distinct purpose: analyze tools target different aspects (crash, error, architecture, scene, script), generation tools cover different templates, debug session tools are distinct lifecycle functions, and list tools target different resources. No significant overlap.
All tool names follow a consistent verb_noun snake_case pattern (e.g., analyze_crash_dump, generate_script_template), making them predictable and easy to understand.
With 17 tools, the set is well-scoped for a Godot development assistant, covering analysis, generation, debugging, and project information without being overwhelming.
The tool set covers analysis, generation, and debugging comprehensively, but lacks creation/modification tools for scenes and scripts, and there is no tool to apply suggested fixes or modify project configuration, leaving minor gaps.
Discover AI tools for game development — 100+ tools indexed by engine, task, and pricing.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
AI colleagues that keep your standards, your project and their reasoning between sessions
AI game assets for agents: consistent sprites, 2D animations, tiles, maps, music and engine exports.
