Better Godot MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.21.0
Disambiguation5/5
Each tool targets a distinct domain (animation, audio, input, physics, etc.) with unique actions. There is no overlap or ambiguity between tools.
Naming Consistency5/5
All tool names use lowercase with underscores (e.g., input_map, tilemap), following a consistent noun-based pattern. Actions within tools also follow a consistent verb style.
Tool Count5/5
17 tools cover a broad but well-scoped set of Godot development tasks. Each tool is justified and the count feels appropriate for the server's purpose.
Completeness5/5
The tool surface covers core Godot workflows including project, scenes, scripts, resources, animation, audio, physics, input, navigation, tilemaps, UI, shaders, signals, and editor control. No obvious gaps for typical game development.
Average 3.5/5 across 17 of 17 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 50 of 54 community issues answered or closed in the last 6 months
- 205 commits in the last 12 weeks
- Last stable release on August 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint false, destructiveHint false) but do not contradict the description. However, the description adds no behavioral details such as side effects of actions, required permissions, or state changes. For a tool managing audio buses and streams, crucial transparency is missing, placing the burden on the description 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main concept, but it is too concise to convey necessary information, instead deferring to an external help tool. It sacrifices substantive content for brevity, making it merely adequate rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, multiple actions) and the lack of output schema details, the description is highly incomplete. It fails to explain how parameters relate to actions or what the tool's effects are, and the suggestion to use the help tool acknowledges this gap.
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 description coverage is 100%, meaning the schema already documents all parameters. The description adds no additional meaning beyond listing action names, which the schema's enum also provides. Since baseline is 3 for high coverage, the description's negligible extra value results in a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as handling audio bus and stream management and lists four actions, which gives a general sense of purpose but lacks specificity for each action. It does not differentiate among siblings, but siblings are distinct domains like animation or editor, so the main gap is the lack of detail on what exactly the tool does beyond the broad category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or the help tool. The description merely lists actions without explaining which action to choose for which scenario, and explicitly tells users to rely on an external help tool for full docs, indicating the description is insufficient for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context such as side effects, permissions, or whether actions modify state. With no compensation from the description, the agent lacks understanding of potential impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this brevity sacrifices clarity. It front-loads 'Physics config' and lists actions, which is somewhat structured, but the utility of the description is limited. Every sentence is used, but the content is insufficient for an agent to use the tool effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (10) and the presence of an output schema, the description is severely lacking. It does not explain the behavior of each action, parameter dependencies, or expected outputs. The tool is complex, but the description provides almost no contextual completeness.
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%, with each parameter having a brief description. The description adds no additional meaning beyond listing action names; it does not explain which parameters apply to which actions. The schema already provides basic context, so the description offers minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Physics config' and lists four actions, giving a general sense of the tool's purpose. However, it is vague and does not clearly specify what each action does or how the tool is used. The phrase 'Use help tool for full docs' suggests incompleteness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. The description does not mention any prerequisites, context, or scenarios where physics should be chosen over sibling tools like animation or navigation. The instruction to use the help tool indicates the description is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive, but the description adds no behavioral context beyond the list of actions. It does not disclose side effects, required permissions, or state changes (e.g., whether animations are persisted to files or only in memory).
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?
The description is very concise, with two short sentences. It is front-loaded with the domain and a list of actions. However, it relies on an external tool for full documentation, which could be seen as a space-saving choice rather than a complete description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (as indicated by context signals) and 11 parameters, the description does not explain how actions relate to parameters, what each action returns, or how to chain operations. It is incomplete for an agent to use without referencing the help tool.
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?
The input schema covers all 11 parameters with descriptions (100% schema_description_coverage). The description itself adds no extra meaning to the parameters; it only lists action names. Baseline 3 is appropriate since the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Animation management' and lists five actions (create_player, add_animation, etc.), giving a general idea of the tool's purpose. However, it lacks a specific verb-resource pair and does not clearly differentiate from sibling tools like 'editor' or 'nodes', which could also involve animation-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description simply says 'Use help tool for full docs', shifting the responsibility of understanding usage to an external tool. There is no mention of when to use specific actions or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present but the description adds little behavioral insight. It does not disclose which actions are destructive (e.g., create_control) vs non-destructive (list_controls), nor does it explain prerequisites or failure modes. The action list alone is insufficient.
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?
The description is concise at two sentences, front-loading the action list. However, the structure could be improved (e.g., bullet points for actions), and the reference to 'help' adds moderate utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 parameters and 4 actions, the description is minimal. It does not explain return values (output schema exists but is unused), prerequisites, or error handling. The tool is moderately complex, yet the description leaves significant gaps.
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 description coverage is 100%, so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already provides, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'UI Control nodes and themes' and lists four actions, giving a general sense of the tool's scope. However, it lacks a unified statement of purpose and does not differentiate from sibling tools like 'nodes' or 'scenes', making it adequate but not clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'nodes' or 'scenes'. The description merely suggests using the 'help' tool for full documentation, offering no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists actions but does not disclose behavioral traits beyond what is obvious (e.g., mutations). Annotations (readOnlyHint=false, destructiveHint=false) indicate it is not read-only and not necessarily destructive, but the description adds no additional context about side effects, permissions, or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with purpose. However, it ends with 'Use help tool for full docs', which indicates incompleteness and relies on external documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, a non-trivial output schema, and multiple actions, the description is too brief. It does not explain the output, parameter dependencies, or how actions relate, and defers to the help tool.
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 description coverage is 100%, so the schema already documents each parameter. The description lists the actions (already in the schema enum) but adds no new semantic meaning for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is for 'Navigation regions, agents, obstacles' and lists three specific actions (create_region, add_agent, add_obstacle). This clearly identifies the tool's purpose and distinguishes it from sibling tools like 'animation' or 'audio'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It briefly mentions actions but does not provide context such as prerequisites, recommended workflows, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal behavioral context beyond listing actions. Annotations are not contradicted, but the description doesn't disclose side effects, permissions, or limitations of actions like create/write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise but poorly structured. The action list is in inline code format, which is terse but not easily readable. It could be more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits return value info, error handling, and prerequisites. With 5 parameters and multiple actions, it is incomplete.
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 describes all parameters, so baseline is 3. The description adds no extra meaning; it only enumerates actions without linking to parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's for Godot shader management and lists specific actions. However, it doesn't differentiate from sibling tools like 'scenes' or 'scripts', but the purpose is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It defers to the help tool ('Use help tool for full docs'), indicating the description itself is insufficient for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and nondestructive behavior, but the description adds no behavioral context beyond listing actions. No disclosure of side effects, permissions, or mutation scope. For a management tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, with one sentence and a list. While concise, it sacrifices completeness by deferring to the help tool. Front-loads purpose but lacks structured details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, a required action, and an output schema present, the description is inadequate. It relies on the help tool for full documentation and does not explain return values or action-specific behavior. Self-contained usage is not possible.
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 baseline is 3. The description maps actions to the action enum but does not explain parameter interplay or provide context beyond the schema descriptions. No added value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'TileSet and TileMap management' and lists five concrete actions, clearly indicating the tool's domain. However, it does not differentiate from sibling tools like 'scenes' or 'resources' that might overlap, missing a chance to clarify uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The only reference is 'Use help tool for full docs,' which defers responsibility rather than offering decision-making context. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists actions including delete (destructive) and others (read-only), which aligns with annotations (destructiveHint=true). However, it adds no additional behavioral context beyond what annotations already provide, such as side effects, authentication needs, or rate limits.
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?
The description is concise with a structured list of actions and parameters. It front-loads the main purpose and includes only necessary information. Minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers the core actions adequately. However, it lacks details on error conditions, prerequisites (e.g., valid project path), and does not elaborate on 'import_config' beyond 'view import settings'. It is functionally complete but could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by mapping each action to its required/optional parameters (e.g., 'list (-> type, project_path)'), which is not explicit in the schema. This helps the agent understand which parameters apply to which action, supplementing the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool manages resource files and lists four actions (list, info, delete, import_config). However, it does not explicitly distinguish itself from sibling tools like 'audio' or 'animation', which likely handle specific resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No mention of prerequisites or context. The description only lists actions but does not help the agent decide which tool to use for which scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and non-destructive. The description adds context like 'update setting' for set and 'find Godot binary path' for detect_godot, which is helpful but does not go beyond the existing annotation coverage significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one line for purpose, then a compact list of actions with parameter hints. No wasted words, well structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (unknown content) and 100% input schema coverage, the description covers all actions and their parameters. However, it could mention the output format or return values for actions like 'status' or 'check'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying the role of each action and required params (e.g., '(key, value): update setting'), which clarifies parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for 'Server configuration and environment' and lists specific actions (status, set, detect_godot, check). This distinguishes it from sibling tools, though the name 'config' is generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 its siblings (e.g., project, scripts). The description lists actions but does not provide criteria for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the annotations (readOnlyHint, idempotentHint, not destructive) and adds no further behavioral context. It confirms that the tool retrieves documentation, but does not elaborate on aspects like response format or limits. Given that annotations already cover the safety profile, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that efficiently convey purpose and usage guidance. There is no redundant or unnecessary text, making it well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple help tool with one enum parameter, the description adequately covers the purpose and usage context. It does not specify the return format, but that is often implied for documentation tools. Overall, it is complete enough given the tool's simplicity and supporting annotations.
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?
The schema already provides a complete description of the parameter with an enum and description 'Tool to get documentation for'. The tool description adds no additional meaning to the parameter, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides full documentation for a given tool, with a specific verb ('documentation') and resource ('tool'). It hints at a distinction from compressed descriptions, but could be more explicit about what 'full documentation' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use when compressed descriptions are insufficient,' providing clear guidance on when to use this tool. While it does not list alternatives, the context implies that sibling tools have compressed descriptions, making this guideline effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses mutating actions (run, stop, export, settings_set) and non-mutating ones (info, version, logs, settings_get). Annotations show readOnlyHint=false and destructiveHint=false, but the description adds context about process management (launching/stopping games, reading logs). It could be more explicit about side effects, such as that 'run' starts a game and 'stop' kills it.
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?
The description is concise and structured as a list of actions with parameter notes in parentheses. It front-loads the action list, making key information quickly scannable. However, the notation might be slightly cryptic for new users (e.g., '->' for required/optional), and the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 8 actions, output schema present), the description covers all actions and their parameter dependencies. It explains the purpose of each action and how parameters relate to it. The presence of an output schema reduces the need to describe return values. Minor gaps: no explanation of what 'project metadata' includes for info, or what happens if run is called with no scene_path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all parameters. The description adds value by grouping parameters per action and indicating which are required vs optional (e.g., 'key -> project_path' for settings_get). This contextualizes the schema beyond raw property definitions.
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 clearly states it handles 'Godot project operations' and enumerates 8 distinct actions (info, version, run, logs, stop, settings_get, settings_set, export) with specific purposes. Each action is described with a verb and resource, making it easy for an AI agent to understand what the tool offers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a compact guide on which parameters are required or optional for each action, and notes the default behavior for logs (most recently started PID). However, it does not explicitly tell when to use this tool over sibling tools like 'editor', 'nodes', or 'scripts', which may overlap in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true; description lists destructive actions (remove, set_property) but does not elaborate on consequences or irreversibility beyond what annotations imply.
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?
Description is well-structured with an action list and note on paths, but could be slightly more concise by avoiding repetition of parameter names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers actions and parameters adequately, but lacks description of return values (e.g., what 'list' returns) despite an output schema existing; still sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds value beyond schema by providing default values (type='Node', parent='.') and clarifies node path conventions, despite 100% schema coverage.
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?
Description clearly states it manages scene node operations with explicit actions (add, remove, rename, etc.), distinguishing it from sibling tools focusing on other domains like animation or audio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides structured format for actions with required/optional params and explains node path syntax, but does not explicitly state when to use this tool versus alternatives or specify exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. Description adds action details but no additional behavioral context (e.g., irreversible changes, permissions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line summary and a bulleted list. Front-loaded with no wasted words.
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?
Given complexity (8 params, 3 actions, output schema exists), description covers purpose and action signatures completely. Return values are covered by output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds value by grouping required vs optional parameters per action, aiding in understanding call structure.
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?
Description clearly states it manages signal connections with three specific actions: list, connect, disconnect. Verb+resource is precise and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 vs siblings or alternatives. Usage is implied by the actions but not contextualized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description mentions actions that modify input map (add, remove). However, the description does not elaborate on behavioral details such as side effects or permanence of changes beyond what the annotation implies. It adds little extra transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a compact format to convey action-parameter relationships and examples. Every sentence adds value, and the most important information (action list) is front-loaded. No wasted words.
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?
Given the complexity with multiple sub-actions and parameters, the description covers all aspects: listing actions, adding/removing actions, adding events with valid event types and examples. Since an output schema exists, return value documentation is handled elsewhere, making this description complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (baseline 3), but the description adds significant value by grouping parameters per action (e.g., 'add_action (action_name -> deadzone=0.5, project_path)'), showing dependencies and defaults, which is not apparent from the schema alone. This makes parameter usage clear and contextual.
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?
Description starts with 'Input action management' and then details specific actions (list, add_action, remove_action, add_event) with required and optional parameters, clearly stating what the tool does. It distinguishes between sub-operations and explains event types, providing a specific verb-resource mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description shows required vs optional parameters for each action, giving clear usage context. While it doesn't explicitly state when-not to use this tool or compare with siblings, the sibling tools are unrelated, and the sub-action listing effectively guides the agent on which action to perform.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description reinforces this by detailing destructive actions like 'replace entire file' and 'delete'. It adds context about template generation for create and parameter dependencies, providing behavioral clarity beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using bullet points and clear groupings. Every sentence serves a purpose—defining actions, parameters, and providing an example—without superfluous content.
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?
Given the tool's complexity (7 parameters, 6 actions), the description comprehensively covers all actions, their parameter requirements, and usage notes. An output schema exists, so return values need not be described. The description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, giving baseline 3. The description adds value by grouping parameters per action, indicating which are required/optional, and providing an example script path format. This enhances understanding of parameter usage beyond the schema's individual descriptions.
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 clearly states 'GDScript file CRUD' and enumerates specific actions (create, read, write, attach, list, delete) with parameter requirements. It distinguishes itself from sibling tools (e.g., animation, audio) by focusing exclusively on GDScript file manipulation, making the tool's scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides structured action listings with required and optional parameters, giving clear context for when to use each action. However, it does not explicitly state when not to use this tool or suggest alternatives among siblings, though the domain specificity makes the usage implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Matches annotations (destructiveHint: true) with delete action. Clarifies path format (no res://). Could add more on side effects (e.g., implications of set_main).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact format with actions listed, then path note. Front-loaded with purpose, no redundant sentences.
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?
Covers all 6 actions and key constraints for a complex tool. Output schema exists, so return values are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds default root_type and path conventions. Provides useful context beyond schema.
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?
Clearly states 'Scene file (.tscn) CRUD' and lists all actions with params. Differentiates from sibling 'nodes' tool, so agent knows this tool manages scene files, not node editing.
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?
Provides action-specific required and optional params in a structured format. Explicitly says to use nodes tool for editing nodes within scenes, guiding correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, and description aligns by stating actions are launch and status. Adds context like project_path being optional for each action, but does not elaborate on further behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, structured with bullet points, front-loaded with purpose. Every sentence is necessary and informative.
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?
Given low complexity and complete schema+output schema, description sufficiently covers usage, alternatives, and parameter relationships. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by showing parameter dependencies (required params -> optional) and mapping parameters to actions, enhancing usability beyond schema.
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?
Clearly states it controls the Godot editor with specific actions (launch, status). Differentiates from sibling 'project' by stating it should be used for running the game instead.
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?
Explicitly lists when to use each action and provides a clear alternative for running the game (project action=run), guiding agent away from misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![better-godot-mcp MCP server](https://glama.ai/mcp/servers/n24q02m/better-godot-mcp/badges/card.svg)](https://glama.ai/mcp/servers/n24q02m/better-godot-mcp)

Score Badge

Copy to your README.md:

[![better-godot-mcp MCP server](https://glama.ai/mcp/servers/n24q02m/better-godot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/n24q02m/better-godot-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/n24q02m/better-godot-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server