godot-mcp

by XOVIET-GAME

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v3.1.0
Disambiguation5/5
Each tool has a distinct domain prefix (e.g., animation, audio, camera) making them clearly distinguishable by name, despite identical descriptions.
Naming Consistency4/5
All operation tools follow a consistent <domain>_manage pattern, except for godot_catalog which breaks the pattern.
Tool Count3/5
19 tools is a reasonable number, but many of them are redundant wrappers that delegate to a single catalog tool, making the surface feel inflated.
Completeness2/5
The tool set lacks direct operations; all manage tools merely redirect to godot_catalog, which is a single point of entry, leaving the actual functionality hidden and incomplete for direct agent use.
Average 2.3/5 across 19 of 19 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but does not. It omits whether operations are mutating, require a running game, or are destructive. The enum values hint at actions like hold/release, but the description itself provides no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but under-specified. The two sentences are not efficiently informative; the first is vague, and the second offloads detail to another tool. Not well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (many enum operations, nested params, no output schema, no annotations), the description is severely incomplete. It lacks explanation of return values, error conditions, prerequisites, or how to construct the params object for each operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the schema descriptions are minimal ('Operation in the input branch', 'Parameters for the selected operation'). The tool description adds no extra meaning, leaving the agent to infer param usage from the enum values or by calling godot_catalog.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Godot input operations' is vague and essentially restates the tool name. It fails to specify what type of input management is performed (e.g., simulation, monitoring). Sibling tools like `input_manage` and `godot_catalog` are not differentiated.
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 vs. alternatives. The instruction to call `godot_catalog` for the operation tree is a pointer but does not clarify usage context or exclude other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and the description discloses no behavioral traits. Does not indicate whether operations are read-only, destructive, or require authentication.
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 with one sentence, but it sacrifices informativeness for brevity. It is not front-loaded with critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple operations, dynamic params, no output schema), the description is severely incomplete. It lacks usage context, behavior, and parameter details, forcing reliance on another tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds no meaning beyond the schema. The op parameter enum lists values but no explanation of each. The params object is free-form with no description, leaving the agent without guidance on its structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description only says 'Godot render_2d operations', which is a tautology with the name. Does not specify what the tool does beyond being a manager. The instruction to call godot_catalog for the operation tree suggests the actual purpose is unclear.
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 like render_3d_manage or other sibling tools. Only advises to call godot_catalog for details, which is indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed. The description does not mention side effects, permissions, or whether operations are read-only or destructive. With no annotations, the description carries the full burden but provides zero 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 (two sentences) and front-loaded, but it sacrifices substance for brevity. While concise, it omits critical information needed for correct tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's polymorphic nature (five sub-operations) and no output schema, the description is severely incomplete. It fails to explain any operation details, expected parameters, or return values, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds no extra meaning beyond the schema. The parameter descriptions are minimal and generic (e.g., 'Operation in the signal branch'), and the tool description does not clarify what parameters should be used for each operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Godot signal operations', which is a broad category without specifying the action or resource. It fails to distinguish from sibling tools like node_manage or scene_manage. The reference to godot_catalog implies it is a dispatcher but does not clarify its purpose.
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. The only hint is 'Call godot_catalog for the operation tree', which is indirect and does not provide clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It fails to mention any side effects, permissions, or safety aspects. The description is insufficient for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks necessary detail. It is under-specified rather than concise, similar to the calibration low example 'Process'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 15 possible operations and a generic params object, but the description provides no details about operations, parameters, or outputs. It defers entirely to godot_catalog, making it highly 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?
Both parameters are described in the input schema (100% coverage). The description adds no additional semantic value beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Godot node operations' is vague and does not specify the exact functionality. It does not distinguish from sibling tools like scene_manage or runtime_manage. The instruction to call godot_catalog undermines its own clarity.
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 instruction is to consult godot_catalog, which is a prerequisite but not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description offers no behavioral details: no mention of side effects, error handling, required permissions, or output format. The tool is effectively a black box beyond the schema.
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 (2 sentences) but this brevity sacrifices essential information. It is concise but not appropriately sized for the tool's complexity, lacking necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool dispatches 8 distinct physics operations with an open-ended params object, the description is severely incomplete. No information about operation semantics, required parameters per op, or return values is provided. The schema alone is insufficient.
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% (both op and params are described), so the baseline is 3. The description adds no additional meaning to the parameters, but the schema already enumerates valid op values and defines params as an object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Godot physics operations' which is vague and does not specify a concrete action. It reads as a category rather than a specific verb+resource, and fails to distinguish from sibling tools like animation_manage.
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?
The only guidance is to call godot_catalog for the operation tree, which implies the tool is a dispatcher. No explicit when-to-use, when-not-to-use, or alternatives are provided, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral insights. The tool likely performs mutations given the 'manage' suffix, but this is not stated. There is no disclosure of destructive actions, authentication needs, rate limits, or side effects. The description fails to add any transparency 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it lacks necessary detail. Every word is earned, but the content is insufficient for understanding the tool. It is not overly verbose, but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (16 operations in an enum, nested params object, no output schema), the description is severely incomplete. It does not explain any operation, parameter usage, or return values. The reference to godot_catalog is helpful but does not compensate for the lack of essential information.
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%, with each parameter having a basic description in the schema. The tool description adds no additional meaning beyond the schema, but per guidelines, baseline is 3 for high coverage. No extra context is provided, but the schema itself is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Godot render_3d operations' is essentially a tautology of the tool name and provides no specific verb or resource. It does not clarify what actions the tool performs, just that it deals with 3D rendering operations. It vaguely distinguishes from sibling tools like render_2d_manage by mentioning '3d', but lacks specificity.
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?
The description does not provide guidance on when to use this tool versus alternatives. The only additional clue is 'Call godot_catalog for the operation tree,' which implies a relationship but does not explain usage context or exclusions. There is no mention of prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description lacks any information about behavioral traits such as side effects, destructive actions, authorization requirements, or return behavior. This is a critical gap for a tool managing scene operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is too short (two sentences) to be useful. The first sentence is too generic, and the second redirects to another tool. It sacrifices completeness for brevity, making it ineffective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 enum operations, nested params) and the absence of annotations and output schema, the description is severely incomplete. It fails to explain any operation details, parameter usage, or expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema's parameter descriptions ('Operation in the scene branch' and 'Parameters for the selected operation').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Godot scene operations' is vague and does not specify what the tool does. It does not differentiate from sibling tools like node_manage or animation_manage.
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?
The description instructs to 'call godot_catalog for the operation tree' but provides no guidance on when to use this tool vs alternatives such as node_manage or animation_manage.
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?
No annotations are provided, and the description does not disclose behavioral traits such as side effects (e.g., file creation/deletion can be destructive), permissions needed, or any limitations. The agent must infer behavior from operation names, which is risky.
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 extremely concise (two sentences) but at the cost of clarity. Front-loading 'Godot filesystem operations' is clear but insufficient. The second sentence is a tangential reference, not essential for immediate tool use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool supports 10 distinct operations with free-form parameters and no output schema, the description is severely incomplete. It fails to explain operation-specific behavior, parameter requirements, or return values, making it nearly unusable without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described), but the description adds no extra meaning. The 'params' object is opaque with 'additionalProperties: true' and no guidance on structure per operation. The agent cannot determine required fields for each op without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Godot filesystem operations' which is vague. It does not specify which operations are available (enum does but description lacks detail). The reference to godot_catalog hints at a broader system but doesn't clarify this tool's distinct role.
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?
The instruction 'Call godot_catalog for the operation tree' implies prerequisite guidance, but there is no mention of when to use filesystem_manage versus other sibling tools like animation_manage or audio_manage. The agent is left without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., side effects, idempotency, permissions, rate limits). The description is entirely silent on what happens when the tool is used, leaving the agent with no 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 (two sentences), which is concise but not necessarily effective. The first sentence is overly generic, and the second is a redirect. It lacks structure; it does not front-load the most critical information. Acceptable minimalism but not optimally designed for agent use.
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 lack of annotations and output schema, the description should provide more context, such as what each operation does, return format, or side effects. The tool appears to be a dispatcher, but the description fails to explain how the 'params' object should be structured or what behavior to expect.
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 description does not add any meaning beyond the schema; it merely repeats the domain. However, the schema itself clearly defines the 'op' enum and 'params' object, so the description is not harmful, just not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Godot audio operations,' which is a vague domain label rather than a specific verb and resource. It does not clarify what the tool does (e.g., manage audio playback, buses, effects). The instruction to call godot_catalog for the operation tree provides a hint but does not define the tool's own purpose.
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?
The description lacks guidance on when to use audio_manage versus sibling tools. It only says to call godot_catalog for the operation tree, which is procedural but does not specify the conditions under which this tool should be invoked instead of alternatives like animation_manage or node_manage.
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?
No annotations are provided and the description does not disclose behavioral traits such as whether operations are read-only, destructive, or require specific permissions. The nature of the tool (dispatching based on 'op' parameter) is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It does not earn its place; a single sentence without substantive guidance is insufficient for tool selection.
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 4 enumerated operations and a generic 'params' object, the description is too minimal to enable correct usage. No output schema and no details on parameter structures or results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described adequately. The description adds no additional meaning beyond what is in the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Godot camera operations' is vague and lacks a specific verb+resource. It does not distinguish from sibling tools like animation_manage or scene_manage, and offloads explanation to godot_catalog.
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 when-to-use or when-not-to-use guidance. The reference to godot_catalog implies it provides context, but the description itself gives no situational advice or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no information about side effects, permissions, or safety. For a tool that likely modifies game state (e.g., playing animations), this 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal, consisting of a short sentence and a reference. It is concise but lacks substance, so it does not effectively earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context. It fails to explain expected returns, usage constraints, or behavior, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds no additional meaning to the parameters. The 'op' enum values and 'params' object are not explained beyond the schema, leaving ambiguity.
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 'Godot animation operations' which is broad and vague. It does not specify the exact actions (e.g., play, create) without relying on the enum. It distinguishes from sibling tools by focusing on animations, but the purpose is not sharp.
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 instruction 'Call godot_catalog for the operation tree' provides guidance on how to discover available operations. However, it does not specify when to use this tool vs alternatives or any 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?
No annotations provided, and the description does not disclose behavioral traits such as side effects, required permissions, or rate limits. The tool appears to invoke various runtime operations, but no details are given.
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 (one sentence) but lacks essential information. It is concise but under-specifies, making it barely adequate.
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 complexity of a tool with 14 sub-operations and a nested params object, the description is severely incomplete. No guidance is provided on parameter structures for each operation, making it hard for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameters (op enum and params object). The description adds no extra meaning beyond what the schema provides, earning a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Godot runtime operations' but lacks a specific verb or resource action. It redirects to godot_catalog, making the tool's purpose unclear.
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 vs siblings. The only hint is 'Call godot_catalog for the operation tree,' which implies it is a dispatcher but doesn't clarify usage context.
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?
No annotations are provided, and the description does not disclose behavioral traits such as mutability, side effects, or permissions. The op enum hints at sub-operations, but the description adds no behavioral context beyond what the schema already provides.
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 (two sentences) but under-specified. It does not front-load important information and contains a redirect instead of substantive content. Could be more effective if it provided a concrete purpose.
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 no output schema and a nested params object, the description is incomplete. It does not explain what the tool returns, how to construct 'params', or the behavior of each op value. Relies entirely on sibling tool and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any meaning beyond the schema's descriptions of 'op' and 'params'. It fails to elaborate on parameter usage, constraints, or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Godot system operations' is vague and does not specify what the tool actually does. It fails to distinguish this tool from siblings like 'core_manage' or 'scene_manage'. No verb or specific resource is indicated.
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?
The description implies using godot_catalog to discover available operations, but provides no explicit guidance on when to use this tool versus alternatives. No context or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It fails to mention side effects, permissions, rate limits, or what each operation does. This is a critical gap for a tool managing network operations.
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?
Two short sentences with no unnecessary words. The structure is clean, but the second sentence is essential for guidance. Could be slightly more concise by integrating the reference, but overall efficient.
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?
For a tool with 2 parameters (including a dynamic object), no output schema, and no annotations, the description is highly incomplete. It does not explain operation behaviors, required params per op, or return values. The reference to godot_catalog partially compensates but 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 coverage is 100% for both parameters. The description adds no additional meaning beyond the schema. Since baseline is 3 when coverage is high, this score reflects the lack of extra context for the dynamic 'params' object.
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?
Description states it handles 'Godot network operations', which is a broad verb+resource. It does not distinguish from sibling tools like 'audio_manage' or 'scene_manage' beyond the network domain. The enum in the schema provides some specificity, but the description itself is vague.
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?
The description advises calling 'godot_catalog for the operation tree', implying that catalog is needed for detailed operations. However, it offers no explicit guidance on when to use this tool versus siblings, no prerequisites, and no exclusion criteria.
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?
With no annotations present, the description bears full responsibility for behavioral disclosure. It omits any mention of side effects (e.g., whether operations are read-only or destructive), authentication needs, rate limits, or error behaviors. The schema's enum hints at possible actions, but the description itself adds no 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 extremely concise with two sentences, but the first sentence is overly generic and lacks substance. While brevity is positive, the content is insufficiently informative, making it less effective. The structure is simple but the trade-off between brevity and clarity is not well-balanced.
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 (2 parameters, enum of 7 operations, nested 'params' object) and the absence of an output schema, the description is severely lacking. It does not explain return values, error handling, or the structure of the 'params' object for each operation. Compared to the rich sibling tool set, this description leaves the agent underinformed.
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 both parameters are described in the schema: 'op' as an enum and 'params' as an object. The description adds no further meaning beyond the schema, which already defines the parameter purposes. A baseline score of 3 is appropriate since the schema carries the load without description enhancement.
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 'Godot core operations' is vague and does not specifically define what 'core' means in this context. It hints at functionality through the enum in the schema but lacks a clear verb-resource statement. The reference to godot_catalog adds some direction but does not clarify the tool's unique purpose among many sibling manage tools.
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?
The only guidance is 'Call godot_catalog for the operation tree,' which suggests where to find possible operations but does not explain when to use this tool versus alternatives like system_manage or runtime_manage. No conditions, prerequisites, or exclusions are provided, leaving the agent uncertain about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It merely states 'Godot ui operations' without any details on side effects, permissions, rate limits, or whether operations are destructive. This is insufficient for an AI agent to understand the tool's impact.
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 (two sentences) and front-loaded, but the content is minimal. While it is not verbose, it sacrifices completeness for brevity. Every sentence is necessary, but more detail would be beneficial.
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?
This is a dispatcher tool with 9 enum operations and a dynamic params object. Without an output schema, the description should provide more context about what each operation does or how to use params. The lack of behavioral details and parameter semantics makes it incomplete for the complexity.
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 both parameters having descriptions. The tool description adds no additional semantics about the parameters beyond what the schema already provides. The baseline of 3 is appropriate.
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 'Godot ui operations' which identifies the resource, but the verb is implicit. It distinguishes from siblings by the UI domain, but does not specify exactly what the tool does beyond that. The instruction to call godot_catalog for the operation tree provides context but the purpose remains vague.
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 gives a hint about workflow: 'Call godot_catalog for the operation tree' implies that this tool is for executing UI operations after looking them up. However, it lacks explicit guidance on when to use this tool versus alternatives, and no exclusion criteria are stated.
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?
With no annotations and no description of side effects, authentication needs, or error behavior, the tool's behavioral traits are completely opaque. Agents cannot know what happens when an operation is executed.
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 brief—two sentences that are front-loaded with the tool's purpose and key guidance. It is concise, though it sacrifices completeness for brevity.
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?
The tool has nested object parameters, no output schema, and a generic interface. The description completely fails to explain what operations are available, their inputs, or outputs, leaving agents without necessary context.
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% and parameter descriptions in the schema adequately define the fields (op enum, params object). The description adds no additional meaning, but given the baseline, a score of 3 is appropriate.
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 'Godot validation operations,' which identifies the domain but is vague. It lacks a specific verb-resource pairing and does not differentiate from sibling tools like audio_manage or core_manage, which follow the same pattern.
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?
The instruction to 'Call godot_catalog for the operation tree' provides some guidance, but it does not clarify when to use this tool versus others, nor does it explain prerequisites or conditions for invocation.
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?
No annotations are provided, so the description carries full responsibility. It does not disclose behavioral traits such as whether operations are destructive, require permissions, or have side effects. The 'params' field allows arbitrary additional properties, which is a notable behavior not mentioned.
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: two sentences front-loading the tool's domain and providing a critical cross-reference. Every sentence is purposeful, with no extraneous information.
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 tool's complexity (proxy for many operations via generic params), the description adequately directs to godot_catalog. However, it omits details about return values, side effects, and behavior across operations. The lack of an output schema compounds this gap, making the tool incomplete for an agent without additional context.
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%, with both 'op' (enum) and 'params' (generic object) described in the schema. The description adds no parameter-level detail, instead deferring to godot_catalog. This meets the baseline for high coverage but fails to enrich semantics beyond the schema.
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 'Godot project operations,' which identifies the domain but is vague. It does not list specific operations, leaving the purpose broad. The input schema enumerates operations, but the description relies on that rather than clarifying the tool's role relative to siblings like scene_manage or node_manage.
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 directs the agent to 'Call godot_catalog for the operation tree,' providing a cross-reference for detailed usage. However, it offers no guidance on when to choose project_manage over sibling tools or what prerequisites exist. The guidance is partial but useful.
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 does not disclose behavioral traits beyond 'browse.' No annotations are provided, so the description carries full burden. It lacks information about read-only nature, side effects, permissions, or output format. For a read-like tool, minimal behavioral disclosure is acceptable, but it barely meets the threshold.
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 a single, front-loaded sentence (11 words) with no superfluous content. Every word earns its place, clearly conveying purpose and usage context.
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 simplicity (one optional parameter, no output schema), the description adequately covers its purpose and usage guidance. It does not elaborate on the 'operation tree' concept, but the context is sufficiently complete for an exploration 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 coverage is 100% (the single enum parameter is described in the schema as 'Optional domain to inspect'). The description adds no additional meaning beyond this. Baseline 3 is appropriate since the tool is simple and the parameter is already well-documented.
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 the tool's purpose: 'Browse the Godot MCP operation tree before choosing a domain tool.' It uses a specific verb ('Browse') and resource ('operation tree'), and distinguishes itself from sibling domain-specific tools (e.g., core_manage, scene_manage) by positioning itself as a preliminary exploration step.
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 advises using this tool 'before choosing a domain tool,' providing clear context for when to invoke it. It implicitly suggests that after browsing, one should select a specific sibling tool, though it does not explicitly describe when not to use it or list alternatives.
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:

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

Score Badge

Copy to your README.md:

[![godot-mcp MCP server](https://glama.ai/mcp/servers/XOVIET-GAME/godot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/XOVIET-GAME/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/XOVIET-GAME/godot-mcp'

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