Open Godot MCP
Server Quality Checklist
Latest release: v0.1.10
- Disambiguation5/5
Each tool targets a distinct domain (editor, scene, node, script, etc.) with clear read/edit separations. Overlapping concepts like runtime state vs. profiler are clearly differentiated by purpose.
Naming Consistency5/5All tools follow a consistent 'godot_<domain>_<action>' or 'godot_<domain>' pattern using snake_case. No mixed conventions or unexpected variations.
Tool Count4/531 tools is above the typical 3-15 range, but given the broad scope of Godot engine functionality (editor, scene, scripting, networking, etc.), the count is reasonable and each tool serves a distinct purpose.
Completeness5/5The tool surface covers nearly all major aspects of Godot development: editor control, scene/node editing, scripting, project settings, input, filesystem, debugging, profiling, testing, animation, tilemap, assets, export, and more. No obvious gaps for a game engine MCP.
Average 2.9/5 across 31 of 31 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.jsonto 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
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions 'auto-allow' but does not explain side effects, required permissions, or what happens on execution. Actions are listed but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is poorly structured with confusing parentheses and question marks. It lacks clarity and fails to convey information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and minimal parameter documentation, the description is insufficient for an agent to reliably use this tool. It omits return values and usage examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only provides cryptic hints (e.g., 'inspect(node_path,properties?)'). It does not explain the 'action' or 'params' fields in any meaningful way.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description vaguely states 'Observe running game state' but uses cryptic abbreviations and question marks (e.g., 'digest(groups?)'). It fails to clearly define the tool's primary function or distinguish it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like godot_node_read or godot_log. The description lacks any context about appropriate use cases or prerequisites.
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 exist, and the description fails to disclose behavioral traits such as side effects, idempotency, or permissions required. The list of actions (e.g., 'set_setting', 'autoload_add') implies mutations but no details on consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, but it lacks structure—it dumps a list of actions without categorizing or prioritizing them. For a multi-action tool, better organization would help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 distinct actions and no output schema, the description is grossly incomplete. An agent cannot determine the parameters for each action, expected return values, or error conditions, making the tool nearly unusable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters ('action' and 'params') with 0% description coverage. The description only lists action names but does not explain what 'params' accepts or how to use it for each action, adding no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Project settings & autoloads' and lists actions, providing a general sense of the tool's scope. However, it remains vague and does not explain what the individual actions do or how they relate to project settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context or guidance is provided. The description does not indicate when to use this tool versus its siblings (e.g., 'godot_editor_read', 'godot_scene'), nor does it specify any preconditions 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?
No annotations are provided, so the description must disclose behavioral traits. It mentions actions like 'export' implying mutability, but does not explain side effects (e.g., file creation, overwrites, required state). The agent cannot assess safety or side effects from this description alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and uses a compact notation (e.g., 'export(preset,dest_path)'), which is efficient but may be ambiguous. It front-loads the purpose but lacks explanatory sentences. Every character earns its place, but readability suffers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and 2 parameters with no schema descriptions, the description provided is too minimal. It omits return value details, error handling, and any contextual information about the export process. A more complete description is necessary for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage. The description adds value by listing action values and hinting at parameters for the 'export' action (preset, dest_path) and 'add_preset' (name, platform, settings). However, the mapping to the actual 'params' object structure is not formalized, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is for 'Game export' and lists specific actions (presets, export, add_preset), giving a general purpose. However, it does not clearly distinguish from sibling tools like godot_asset, and the exact resource is vague ('game' is broad). It meets minimum clarity 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 Guidelines1/5Does 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 (e.g., godot_asset, godot_filesystem). The description does not mention prerequisites, typical use cases, or exclusions. The agent has no basis for deciding when to invoke this tool over others.
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 carries full responsibility for behavioral disclosure. It fails to mention side effects, safety (e.g., whether operations are destructive), or any behavioral traits beyond the list of actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which sacrifices informativeness. While concise, it lacks structure and fails to front-load important details for each action or parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions), no output schema, and no annotations, the description is severely incomplete. It does not explain return values, expected behavior per action, or how parameters interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no meaning to the parameters. 'action' and 'params' are not explained, leaving the agent guessing about valid values and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'InputMap management' and lists the supported actions (list, add, remove, bind, ensure, get), distinguishing it from sibling tools like godot_input which likely handle input events rather than the InputMap configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as godot_input or other editor tools. The description does not specify context, 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?
No annotations exist, so the description must convey behavioral traits. It mentions operations like delete and create but does not disclose whether they are destructive, require permissions, or have side effects. The agent lacks critical safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, fitting key information (actions, example path) in a single sentence. It is front-loaded with purpose. However, the brevity sacrifices necessary detail, which is a trade-off.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's multiple actions and the mysterious 'params' parameter, the description is grossly incomplete. It offers no output schema, no return value information, and no hints about parameter usage or action-specific behavior. An agent cannot reliably use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (action and params) with 0% schema description coverage. The description lists possible action values but does not explain the 'params' parameter, its structure, or how it interacts with each action. This is a major gap for tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it handles 'AnimationPlayer ops' and lists specific actions like list, get, create, etc., along with an example path. This sufficiently distinguishes it from sibling tools like godot_node_read or godot_scene, though it could be more precise about the resource being manipulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists actions but provides no guidance on when to use each action or how this tool compares to alternatives (e.g., godot_node_edit). There is no 'when to use' or 'when not to use' context, leaving the agent to guess based on action names.
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 present, so the description must fully disclose behavior. It only labels the tool as a 'compile/syntax check' without explaining side effects, error handling, or what each action does concretely (e.g., whether build modifies files).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but uses ambiguous punctuation and parentheses that reduce readability. It's concise but not well-structured or polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's two parameters and no output schema, the description fails to explain return values, error conditions, or required parameter formats. The agent lacks enough context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It mentions actions and hints at parameters ('project?', 'source?/path?') but does not clarify the 'params' field or specify valid values, leaving agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'C# compile/syntax check' and lists three actions (info, build, syntax), providing a clear verb and resource. However, the question marks and parentheses create ambiguity about parameters and exact behavior, reducing 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings like godot_script or godot_exec. There are no usage contexts, exclusions, or comparisons provided.
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, the description carries full burden. It enumerates actions that are clearly state-modifying (e.g., set_breakpoint, resume), but it does not disclose side effects, permissions, or safety implications. The term 'DAP debugger' gives some context but is insufficient for full 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the type of tool, but it omits essential details about parameter usage. It is concise but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, no output schema), the description lacks necessary context about return values, request formats, and action-specific parameters. The list of actions alone is insufficient for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema parameter coverage, the description only lists action names without explaining the 'params' parameter or how to structure requests per action. This severely limits the agent's ability to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'DAP debugger' and lists specific actions, making its purpose evident. However, it does not differentiate from sibling tools like godot_profiler, missing a chance to clarify its unique 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/5Does 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, nor are any prerequisites or scenarios described. The list of actions implies possible uses but lacks explicit 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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions allowed path prefixes ('res:// or absolute') but does not describe side effects (e.g., whether create overwrites, delete is permanent, read returns entire file, search is recursive), error conditions, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded with 'File ops' followed by an action list. It wastes no words, but could be considered too terse for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no output schema, and a filesystem tool with multiple actions, the description is incomplete. It fails to explain how to structure requests for each action (e.g., required fields in 'params', search patterns, read range) and does not cover return values or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists valid actions but does not explain the 'params' parameter structure or how to specify paths and additional options. The hint 'path=res:// or absolute' is vague and does not clarify the format of values within 'params'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'File ops' and lists specific actions (list, read, search, create, delete, rename), indicating a file manipulation tool. However, it does not distinguish this tool from sibling tools like godot_editor_read or godot_resource, and the exact scope of 'file ops' 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus other Godot tools (e.g., for scene manipulation or editor state). There are no when-not or alternatives 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?
No annotations are provided, so the description carries full burden. It lists actions like terminate and network_condition but does not disclose side effects, permissions, or safety. The behavioral impact is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose, no wasted words. However, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, no annotations, sparse schema), the description is incomplete. It doesn't explain what each action does or when to use them, despite having an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, and description lists actions with hints for launch_instance parameters but no detail on params object. Most actions lack parameter info, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description labels the tool as 'Multiplayer game testing' and lists actions, but lacks a specific verb+resource statement. It's somewhat clear but vague compared to siblings that have more focused names and descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 godot_game or godot_scene. No exclusions or context provided.
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 present, so the description carries full responsibility. It mentions 'gated' but does not explain what gating entails (e.g., permission requirements or locking). The effects of actions like freeze/unfreeze or the exact behavior of step/step_until are not described, leaving behavioral impact unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line, very concise, and front-loaded with the core concept. However, it uses abbreviations and compact notations (e.g., 'step(ms,inputs?)') that may hinder readability, and the term 'gated' is undefined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters, no output schema, no annotations), the description is incomplete. It fails to specify the structure of the 'params' object, return values, side effects, or usage examples. The tool's behavior regarding the 'gated' constraint and the exact semantics of each action remain ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It partially describes the 'action' parameter by listing possible values (freeze, unfreeze, step, step_until) and hints at sub-parameters for step (ms, inputs?) and step_until (condition, timeout_ms?, interval_ms?). However, the 'params' parameter is not explained, and the format for the action's sub-parameters is ambiguous due to question marks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Deterministic clock control (gated)' and lists actions (freeze, unfreeze, step, step_until), making the tool's purpose clear as controlling game time. It distinguishes from sibling tools which cover other Godot domains (editor, scene, node, etc.), but the term 'gated' is not explained, slightly reducing 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/5Does 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 when not to use it. The description only lists possible actions without any context on 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?
With no annotations, the description must disclose behavioral traits. It lists actions but does not explain what each does (e.g., 'attach, detach' are unclear), side effects, permissions, or limitations. The path constraint is mentioned but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence and a list. It front-loads the key action list. However, it could be more structured by grouping similar actions or providing brief explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, no output schema, no annotations), the description is far too minimal. It lacks details on each action's behavior, required parameters, return values, and error conditions. An agent cannot reliably use this tool without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It lists possible actions (read, create, edit, etc.) but does not describe the 'params' parameter at all. The action values are not formally defined, and no format or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'GDScript file ops' and lists specific actions, clearly indicating the tool is for GDScript file operations. It distinguishes from sibling tools like godot_scene or godot_node_read by focusing on script files. However, it doesn't explicitly state the tool operates on files under the res:// path, which is only mentioned in passing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description does not mention when not to use it or suggest sibling tools for different tasks. Usage is implied but not explicitly 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?
No annotations are provided, so the description must disclose all behavioral traits. It mentions 'gated' but does not explain permissions, side effects, or return behavior. The tool modifies game state (injection) but the description omits what happens with different actions or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loading the purpose and using a colon to list actions. However, it lacks structure like separate lines for parameters, which would improve readability. Overall, it is appropriately sized but could be better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter descriptions, the description is insufficient. It fails to explain return values, error cases, or parameter formatting. For a tool with only 2 params, the description should provide more complete context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no descriptions for parameters. The description only lists possible action values but does not clarify that 'action' expects one of these values or explain the 'params' parameter. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool injects input into a running game and lists possible actions. It distinguishes from sibling tools like 'godot_input_map' which handle input mapping. However, the term 'gated' is vague and not explained, slightly reducing 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, context, or exclusions. The list of actions implies usage scenarios but lacks explicit instruction for an AI agent.
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 declares 'Read-only' indicating non-destructive behavior, but provides no further behavioral disclosure such as error handling, action case sensitivity, or any side effects. With no annotations, the description carries full burden and 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence plus list) and front-loaded with the core purpose. However, it is overly brief, sacrificing clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and schema descriptions, the description should provide comprehensive context. It does not explain what each action does, how they differ, or what params are expected. The tool is incompletely described for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It lists actions and a path default, but does not explain the 'params' property, its structure, or how to use actions. This leaves significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is for 'Read-only resource inspection' and lists actions (inspect, list, find, info) and a path default (res://). This clearly indicates the tool's purpose, though it could be more specific about what constitutes a 'resource' compared to other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 siblings like godot_node_read or godot_filesystem. The description implies it is for resource inspection, but does not provide when-not or alternative recommendations.
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, so the description carries the full burden. It mentions actions but does not disclose behavioral traits like side effects, whether operations are destructive, permissions needed, or what happens on error. The hint about node_path format is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, uses front-loaded structure, and has no wasted words. However, it could be slightly more structured with clear separation of details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple actions, 2 parameters, no output schema, no annotations), the description is incomplete. It lacks details on parameter formats, return values, and edge cases. A tool with multiple operations needs more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description lists possible values for the 'action' parameter but does not explain the 'params' parameter structure or expected fields. For a tool with 2 parameters, the description only partially covers semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for 'TileMapLayer/GridMap cell ops' and lists specific actions (read_cells, set_cell, set_cells, clear), which defines the purpose with a specific verb and resource. It distinguishes itself from sibling tools like godot_scene or godot_node_read by focusing on cell 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/5Does 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 description does not mention prerequisites, context for usage, or scenarios where this tool is preferred. Sibling tools are not referenced.
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, the description provides minimal behavioral context. It lists actions and some parameters for generate_2d, but does not disclose side effects, authorization needs, or whether operations are destructive or read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the main purpose. It efficiently lists actions and parameters, though a more structured format could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has multiple actions and no output schema, yet the description does not explain return values, error handling, or behavior for each action. It is incomplete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), so the description attempts to add meaning by listing parameters for generate_2d: svg, filename, save_path, width?, height?. However, parameters for list, info, and import are not described, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Asset generation & management' and lists specific actions (generate_2d, list, info, import), making the tool's purpose evident. It distinguishes itself from sibling tools like godot_scene or godot_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not specify prerequisites, exclusions, or context for using generate_2d vs list/info/import.
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, so description carries full burden. It fails to disclose behavioral traits like whether play starts a new game session, if stop is destructive (clears state), or how status returns information. Only action names 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, two sentences with no wasted words. Front-loaded with 'Game lifecycle' immediately conveys domain. Could be improved by separating actions list with formatting, but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 2 parameters with 0% coverage, and many sibling tools, the description is too minimal. Missing details on return values (e.g., status output), error conditions, and when actions are valid. Leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaning by noting that 'play' accepts optional 'scene' and 'frozen' parameters. However, the generic 'params' parameter remains unexplained, and other actions' parameters are unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Game lifecycle' and lists specific actions (play, stop, pause, resume, status), indicating control over game execution. It distinguishes from sibling tools like godot_scene or godot_editor_edit by focusing on lifecycle management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 godot_scene or godot_runtime_state. The description only lists actions without context on prerequisites (e.g., game must be loaded) 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?
The description does not disclose behavioral traits such as whether actions are destructive (e.g., 'clear'), what side effects occur, or required permissions. With no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, using a compact format to list actions and parameters. Every part contributes meaning, though additional details could be added without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should provide richer context, such as return formats, error handling, or default behavior. It only gives action skeletons, leaving many usage aspects unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains optional parameters for 'get' and 'errors' actions (e.g., source, since_ms, max), but doesn't clarify how the 'params' property in the schema should be used or how to structure sub-parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as for log access and lists specific actions (get, errors, clear), giving a good sense of its purpose. However, it does not differentiate from sibling tools like godot_runtime_state or godot_health that may also deal with logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor are there any prerequisites or exclusions. The description simply lists actions, leaving it to the agent to infer appropriate usage.
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, so description must disclose behavior. It mentions 'auto-allow' and lists actions but does not state whether the tool is read-only, what side effects exist, or any required permissions. This leaves significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two sentences. It immediately states the tool's identity and lists actions upfront. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and only 2 parameters with low schema coverage, the description is too short. It does not explain return values, parameter formats, or how to use the actions. More detail is needed for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage. The description adds context by listing possible values for the 'action' parameter (diagnostics, complete, etc.) and implies a path parameter, but does not fully describe the structure of 'params'. It partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a GDScript LSP and lists specific actions (diagnostics, complete, definition, hover, symbols). This effectively communicates what the tool does and distinguishes it from sibling tools, though it could be more explicit about providing language server features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 godot_script or godot_docs. There is no mention of use cases, prerequisites, 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?
No annotations provided, so description carries full burden. It mentions path constraint but does not disclose error behavior, permissions, side effects, or response format. For a tool with multiple actions, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, one sentence. Contains key info but could be better structured for readability (e.g., list actions). Not wasted words, but slightly too terse for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and multiple actions with complex behavior, the description is incomplete. Missing return value description, error handling, and usage examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description adds that actions include specific verbs, but no details on the 'params' field or allowed values for 'action'. The schema itself lacks enumerations or types, so description must compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool handles scene file operations (.tscn) and lists specific actions (create, read, save, etc.), with path constraint. It is distinct from sibling tools that cover editor, node, script, or other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. While it lists actions, it does not explain prerequisites, alternatives, 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?
No annotations are provided, and the description does not disclose side effects, permissions, or whether actions like 'create' or 'run' modify state. The agent gets no insight into the tool's behavioral impact beyond the action names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with the core purpose stated upfront. However, the dense syntax compromises readability slightly. Every word earns its place, but clearer formatting would improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and ambiguous parameter descriptions, the tool is under-specified. The agent lacks information on return values, error handling, or how results are interpreted, making effective use difficult.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by listing actions and their parameters (e.g., 'run(suite?,test_name?,exclude?)'). This helps beyond the empty schema, though the notation is ambiguous (e.g., unclear if '?' indicates optionality or alternatives).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a built-in test framework and lists specific actions (list, run, results, create). It distinguishes from sibling tools which are other Godot-specific operations. However, the action syntax is cryptic with parentheses and question marks, reducing clarity slightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like godot_debugger or godot_log. It does not specify prerequisites or context for running tests, leaving the agent without decision support.
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, the description bears full burden. It mentions actions ('check, diagnostics') but does not describe what these do, side effects, or return values. It implies a read operation but is insufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. Front-loaded with purpose and action cues. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and only two parameters, the description omits what the tool returns (status, diagnostic data), how to interpret results, and how 'diagnostics' differs from 'check'. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage. The description adds that 'action' can be 'check' or 'diagnostics', but does not explain the 'params' field or provide syntax or constraints. It only partially compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Connection health. Actions: check, diagnostics. Call first to verify connectivity.' which conveys a purpose of checking connectivity, but it is vague and does not differentiate from sibling tools like godot_network or godot_csharp_check. It could be more specific about what 'connection health' 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Call first to verify connectivity' provides explicit context on when to use this tool—before other tools—but lacks guidance on when not to use it or alternative tools for different connectivity checks (e.g., godot_csharp_check for C#).
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 bears the full burden for behavioral transparency. It only states 'Read-only' and lists actions, without disclosing error behavior, side effects, or requirements. Minimal value added beyond the 'Read-only' label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the 'Read-only' purpose. However, the list of actions could be structured better (e.g., bulleted) for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 30+ siblings, 2 parameters with minimal schema, and no output schema, the description is too sparse. It fails to explain what each action does, how to use 'params', or what the return value looks like, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, but the description enumerates possible values for 'action' ('state,selection,open_scenes,viewport,performance'), adding meaning. However, no detail is given for the 'params' parameter, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is 'Read-only editor state' and lists actions, making the tool's purpose clear. It distinguishes from the sibling 'godot_editor_edit' implicitly as read-only, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading editor state via 'Read-only', but provides no guidance on when to use this tool over other sibling tools like 'godot_node_read' or 'godot_runtime_state', nor any conditions 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?
No annotations exist, so description must cover behavioral traits. It mentions 'Undo/Redo' which is helpful, but 'gated' is ambiguous. It does not disclose mutation side effects, permissions, or limitations of actions, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then action list. No fluff, but the action list could be more readable (e.g., bullet points). Slightly above average for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two poorly described parameters, the description is incomplete. It does not explain output, prerequisites, or specific action behaviors. For a multi-action tool, lacking detail reduces usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage; the description lists possible actions, adding meaning to the 'action' parameter. However, it fails to explain the 'params' parameter (type, structure, usage), so only partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edit editor nodes' as the verb+resource, and lists 13 specific actions, making the tool's purpose explicit and distinguishing it from sibling tools like godot_node_read or godot_editor_read which are read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., godot_editor_edit). The term 'gated' is mentioned but not explained, and there are no prerequisites or context for when each action is appropriate.
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 the full burden. It discloses 'auto-allow' and 'game must run' but does not explain the behavior of each action (e.g., what snapshot returns, whether series starts a measurement). This is insufficient for a profiling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core purpose. Every part adds value, but the terse format sacrifices clarity on details that could be expanded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a profiling tool with multiple actions and parameters, the description is incomplete. It does not specify return values (no output schema), error conditions, or detailed parameter formats. The context of 'game must run' is useful but not sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage). The description adds meaning by listing possible action values (snapshot, series, spikes) and hinting at params like duration_ms, metrics, threshold_ms. However, it does not specify types or structure (e.g., whether metrics is a list or string).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Performance profiling' and lists specific actions (snapshot, series, spikes), distinguishing it from sibling tools that focus on editing or reading scenes/nodes. However, it does not explicitly differentiate from other profiling tools if any exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'auto-allow, game must run' as prerequisites, implying when to use the tool (during gameplay). However, it lacks explicit guidance on when not to use it or alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 behavioral disclosure. It states 'Read' implying read-only, but does not disclose side effects, permissions, error handling, or response format. The list of actions hints at behavior but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loads the main purpose. It lists actions in a comma-separated format without unnecessary words. Slight lack of formatting (e.g., bullet list) but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should comprehensively cover actions and parameter expectations. It only lists actions and a path example, leaving undefined what each action returns or how 'params' should be structured. This is insufficient for a tool with 2 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters, so the description must compensate. It lists possible values for 'action' (inspect, tree, find, etc.) and gives an example 'node_path=/root/....' for the 'params' field. This adds meaning beyond the schema, but the 'params' object remains underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads editor scene tree nodes and lists specific actions (inspect, tree, find, etc.). This distinguishes it from sibling tools like 'godot_node_edit' which is for modifications. The verb 'Read' plus the resource 'editor scene tree nodes' provides a specific, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for reading node data via listed actions, but does not explicitly state when to use this tool versus alternatives such as 'godot_node_edit' or 'godot_scene'. No explicit when-not-to-use or contextual guidance is provided.
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 burden. It mentions 'gated' and 'No nesting' but does not disclose safety, destructive potential, error handling, or return behavior. This is insufficient for a tool that executes multiple 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, conveying the core purpose in one sentence plus an example. However, the phrase 'Batch-execute multiple tool calls in one round-trip (gated).' could be slightly clearer about what 'gated' means.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, covering return values. However, the description lacks details about execution order, error behavior, and batching limits. With no annotations, more context is needed for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description partially explains the 'action' parameter by specifying the expected format (execute(operations:[...])). However, the 'params' parameter is not explained, and details about the operations array are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for batch-executing multiple tool calls in one round-trip, and provides an example action format. It distinguishes itself from sibling tools as a meta-tool for combining calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for efficiency (round-trip), but lacks explicit guidance on when to use or not use, or alternatives. The word 'gated' hints at constraints but is vague.
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?
No annotations provided; description mentions gated access and Undo/Redo support, which adds behavioral context, but lacks details on side effects or 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded purpose and efficient listing of actions, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and low schema coverage; description covers actions but lacks return value info, error behavior, or detailed parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description lists valid action values, adding meaning beyond empty schema, but does not explain the optional 'params' object, leaving part of the parameter semantics unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes to the editor, lists specific actions, and distinguishes from sibling tool 'godot_editor_read' which presumably reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage via 'Undo/Redo' and 'gated', but no explicit when-to-use or when-not-to-use guidance, and no alternatives mentioned.
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?
No annotations provided; the description lists actions including destructive ones (terminate) but does not elaborate on side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the key verb 'Manage', though it could be slightly more structured with clearer separation of actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the multi-action nature and existence of an output schema, the description covers the basics but lacks details on return values or per-action behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by naming actions and indicating that launch_editor and adopt require a project_path parameter, compensating for the generic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Godot EDITOR instances and lists specific actions (launch_editor, list, switch, terminate, adopt), distinguishing it from sibling tools like godot_editor_read or godot_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through listed actions but does not explicitly state when to use this tool versus alternatives or provide usage conditions.
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?
Discloses version-matching and lists actions/params, but lacks details on error handling, response format (though output schema exists), and any potential side effects. No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus concise listing. Every piece adds value, no redundancy. Front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core usage and parameters. Output schema exists but description doesn't reference it; slight improvement possible. For a tool with two actions and minimal schema, description is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has generic 'action' and 'params' with no descriptions (0% coverage). Description compensates by defining allowed actions ('fetch', 'search') and expected parameters (class_name, method?, query). Adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool is for Godot official documentation, version-matched, with two specific actions (fetch and search). This distinguishes it from sibling tools like godot_node_read which read node properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly, the tool is for documentation lookups, but no explicit guidance on when to use it vs alternatives. Sibling tools are diverse, but no other doc tool exists, so usage is straightforward.
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?
The description discloses auto-rotation behavior (keeps last 50, deletes older than 24h) and cleanup action, which is valuable beyond the bare schema. However, it does not describe the return value or potential side effects (e.g., blocking).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and packs a lot of information into a single sentence, but it uses abbreviations and compact notation that may require careful parsing. It is efficient but slightly less readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal schema, the description covers all actions, their parameters, and cleanup behavior. However, it omits the output structure and does not clarify whether any parameters are required beyond action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by listing all actions and their optional parameters (e.g., game(max_width?,format?,quality?)). This provides semantic meaning that the input schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool is for taking screenshots and saving them to disk, with multiple action types (game, editor, region, burst, cleanup). It is distinct from all sibling tools, none of which handle screenshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit comparison to alternatives or when-not-to-use guidance is given. However, since this is the only screenshot tool among siblings, usage context is implied but not formally stated.
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?
No annotations are provided, so the description carries full burden. It reveals that the tool executes code (modifying game state) and is gated, but does not detail side effects, security implications, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence gives the core purpose, the second lists actions. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing arbitrary code) and the presence of an output schema, the description covers the main usage. It lacks details on error handling or return values, but the output schema can provide that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, yet the description fully explains the 'action' parameter by listing valid actions with their syntax and optional 'await?' flag. The 'params' parameter is described as free-form depending on action, compensating for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes GDScript in a running game, listing specific actions (eval, call, assert). It is distinct from siblings which are other Godot operations (e.g., godot_node_read, godot_editor_edit).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is 'gated' and disabled if '--no-eval' is set, providing a clear condition for non-usage. However, it does not explicitly compare to alternatives among siblings.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/masteryee-labs/Open-Godot-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server