Skip to main content
Glama
zbrkic

godot-mcp

by zbrkic
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Server Quality Checklist

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

  • Latest release: v1.0.3

  • Disambiguation4/5

    The tools are mostly distinct in purpose, covering different aspects like testing, scene inspection, resource management, and editor interactions. There is slight potential confusion between `inspect_scene_tree` and `find_nodes`, but they serve different goals (hierarchy vs. search). Overall, an agent can reliably select the right tool based on descriptions.

    Naming Consistency5/5

    All tool names follow a consistent verb_noun pattern in snake_case, such as `run_tests`, `get_project_settings`, `validate_script`, and `list_resources`. The verbs are action-oriented and the nouns clearly indicate the target resource. This makes the toolset predictable and easy to navigate.

    Tool Count3/5

    With 20 tools, this exceeds the typical 3-15 range, leaning toward the heavier side. However, each tool addresses a specific need in Godot development (testing, export, scene analysis, resource handling, editor access), so the count is justifiable albeit on the upper end. It feels slightly bloated but not excessive.

    Completeness4/5

    The toolset covers a broad range of Godot workflows, including project configuration, validation, running, formatting, scene/node introspection, resource management, and editor state. Missing features like creating or editing scenes/scripts are not core for an MCP that primarily aids analysis and execution. Minor gaps exist (e.g., no explicit node deletion), but agents can work around them.

  • Average 2.2/5 across 20 of 20 tools scored. Lowest: 1.1/5.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • No commit activity data available
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI is passing

  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state what the tool returns, whether it has side effects, what errors may occur, or any other behavioral nuance. The description is silent on all non-obvious aspects.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is extremely short (two words), but this is under-specification rather than conciseness. It lacks any meaningful structure or front-loaded information. While it is efficient, it omits all necessary detail, so it cannot be praised for conciseness.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a tool with a single parameter and no output schema, the description should at least explain what a dependency is and what the tool returns. It does neither. The definition is completely inadequate for an agent to understand or use the tool correctly.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 0%, so the description must compensate for the bare 'resource_path' string parameter. It does not. No explanation of what the parameter represents, expected format, or constraints is given. The description adds zero semantic value beyond the schema.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose1/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description 'Gets resource deps' essentially restates the tool name 'get_resource_dependencies', offering no additional specificity. It fails to clarify what a 'resource dependency' is or how this differs from sibling tools like get_resource_info or list_resources. This is a tautology.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided about when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or when to prefer get_resource_info or list_resources instead. The agent is left entirely without direction.

    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 present, the description carries the full burden of behavioral disclosure. It only states that it 'Gets node signals' without revealing whether it is read-only, what side effects occur, what data is returned, or any error conditions. This is insufficient for an agent to understand the tool's behavior.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    While the description is very short, this is under-specification rather than concise effectiveness. It omits essential details, making it unhelpful. A concise description should still be informative within its brevity.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    With two required parameters, no output schema, no annotations, and a two-word description, the tool is severely incomplete. An agent cannot reliably invoke this tool without additional knowledge about node signals and connections. The description fails to provide essential context.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does 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 does not explain the purpose or format of 'scene_path' or 'node_path', nor how they relate to the output. The agent receives no additional meaning beyond the raw parameter names.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose2/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description 'Gets node signals' is vague and does not clearly state what the tool accomplishes. The tool name suggests 'node connections' but the description mentions 'signals', which may be a different concept in the Godot engine, creating ambiguity. It fails to distinguish itself from siblings like 'get_node_properties' or 'find_nodes'.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided for when to use this tool versus alternatives. The description lacks any context about scenarios, prerequisites, or why an agent might prefer this over sibling tools such as 'inspect_scene_tree' or 'get_node_properties'.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are present, so the description carries the full burden. It only states a read operation without disclosing side effects, error behavior, output format, or performance implications. The agent has no idea what it will receive on success or failure.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is extremely short, but this is under-specification rather than efficient conciseness. It front-loads nothing of value because the single sentence adds no information beyond the tool name.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    With two required parameters, no output schema, and no annotations, the description provides no context about return values, parameter formats, or error cases. An agent cannot reliably call this tool or interpret its results.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema coverage is 0%, and the description makes no mention of scene_path or node_path semantics. The agent is left to infer from parameter names alone, with no explanation of formats, required context, or relationships between the parameters.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose2/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description 'Gets node properties' essentially restates the tool name without adding specificity. It doesn't distinguish this tool from siblings like inspect_scene_tree or find_nodes, nor does it clarify what 'properties' means or what scope of node data is returned.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or why this tool might be preferred over inspect_scene_tree or get_node_connections.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'Gets detailed info' with no explanation of what data is returned, any side effects (none expected), or operational characteristics. This is insufficient for an agent to understand the tool's behavior.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is extremely short (one sentence), which is concise, but it is under-specified to the point of being unhelpful. It lacks any structure that could convey required information, making the conciseness counterproductive.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a tool with one parameter, no output schema, and no annotations, the description still fails to provide essential context. It doesn't explain what 'detailed info' means, what the returned data looks like, or how to interpret results. This is inadequate for an agent to decide whether and when to invoke it.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 0% and the single parameter 'resource_path' has no description in the schema. The tool description adds no additional meaning, leaving the agent with no understanding of what constitutes a valid resource_path value (e.g., format, scope, or examples).

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose2/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states a generic verb ('Gets') and a generic resource ('detailed info about a resource'). It is not a tautology, but it is vague and does not specify what 'detailed info' includes or how it differs from sibling tools like list_resources or get_resource_dependencies. An agent cannot tell what this tool uniquely offers.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    There is no guidance on when to use this tool versus alternatives. No mention of context, prerequisites, or exclusions. With many similar sibling tools (list_resources, get_resource_dependencies, inspect_scene_tree), the lack of usage guidance is a critical gap.

    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 provided, the description must carry the full behavioral disclosure. It gives no information about side effects, read-only nature, return values, error behavior, or any operational traits. The word 'checks' implies a non-mutating query, but this is not explicitly stated. There is no contradiction, but the omission is total, leaving the agent completely uninformed.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is short (one sentence), so it is not verbose, but this is under-specification rather than concise efficiency. It lacks essential structure and front-loading of key details. Every sentence must earn its place, but here there is only a vague phrase that provides almost no value.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a tool with two parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what results the agent should expect, how to interpret the check, or what actions might follow. The tool is part of a large sibling set, and without context it cannot be used correctly. Even a minimal operational note would improve this.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not. The schema only names class_name and method_name, and the description adds nothing about what these mean, their formats, or relationships. The agent cannot infer valid values or usage from the description alone.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose2/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description 'Checks Godot API' states a verb ('checks') and a broad resource ('Godot API'), but it is too vague to convey a specific action. It does not say what aspect of the API is checked (e.g., class existence, method signature, compatibility). It fails to differentiate from siblings like validate_scene or validate_script, which also imply checking. This is borderline tautological and offers little actionable meaning.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    There is no guidance on when to use this tool versus alternatives. No mention of scenarios where verify_api is preferred over get_help or validate_script. The description gives no context about prerequisites, limitations, or exclusions. An agent would have no basis for choosing 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 provided, the description carries the full burden of behavioral disclosure. It only says 'Validates .gd' – no mention of whether it is read-only, returns a result, throws errors, or has side effects. An agent has no idea what happens when called or what a successful/failed validation looks like.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is extremely short (two words), which some might call concise, but it is under-specified rather than appropriately sized. It lacks any structure or front-loaded critical information. Every word must work hard, and here they do not – they only restate the tool's name.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a validation tool with one parameter, no output schema, and no annotations, the description is far from complete. It does not explain what validation checks, what the return value is, whether it modifies anything, or how errors are reported. An agent given only this description would be guessing at nearly every aspect of invocation.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The schema has one parameter script_path with no description (schema coverage 0%). The description adds zero meaning about what script_path should contain (e.g., a file system path, relative path, content string). The name suggests 'path' but no detail is given to help an agent construct a correct invocation.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose3/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states a verb ('Validates') and a resource ('.gd' files), which gives a basic sense of purpose. However, it is vague about what validation entails (syntax? semantics? linting?) and could be confused with validate_scene, which also validates something. It barely exceeds a tautology because 'validate_script' already implies validating a script.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    There is no guidance on when to use this tool vs. alternatives like validate_scene, format_gdscript, or run_tests. No mention of prerequisites, typical use cases, or conditions that would lead an agent to choose this over siblings. The description provides zero routing information.

    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 provided, the description carries full responsibility for behavioral disclosure. It simply states 'Exports project' without explaining side effects (e.g., file writes, overwrites), whether it requires a scene to be open, or what happens to existing outputs. This is minimal behavioral information, just enough to know it performs an export action.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is extremely short, but this reflects under-specification rather than concise efficiency. It only restates the tool's action and offers no structured information about inputs, outputs, or usage context. Every word is redundant with the tool name.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool has two required but undocumented parameters, no output schema, and no annotations, the description is wholly inadequate for an agent to invoke it correctly. There is no mention of preset formats, output paths, or any constraints. The description leaves the agent guessing at every step.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 0%, and the description adds nothing about the two required parameters ('preset' and 'output'). An agent has no idea what values to pass or what these parameters control. The description completely fails to compensate for the schema's lack of documentation.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose2/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description 'Exports project' essentially restates the tool name (export_project) with no additional qualifiers. It fails to specify what kind of export, what output format, or how it differs from siblings like list_export_presets or get_project_settings. This is a tautology rather than a clear purpose statement.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., an open project), no mention of when not to use it, and no reference to related tools like list_export_presets that might be needed upstream. The sole description gives the agent no contextual cues for selection.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries the full burden of behavioral disclosure. It merely says 'Finds nodes in scene' and reveals nothing about side effects, permissions, return format, pagination, error behavior, or whether it is a read-only operation. The agent is left completely uninformed about how the tool behaves beyond the bare verb.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single short sentence, but it is under-specified rather than appropriately concise. It omits critical information and does not front-load any useful distinctions. This is similar to the 'Process' calibration example where brevity is actually a deficiency.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a tool with three parameters, no output schema, and no annotations, the description is grossly inadequate. It fails to provide any context about the purpose, parameters, return values, or edge cases. An agent cannot confidently invoke this tool correctly based on the provided information.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 0%, so the description must explain the meaning and usage of the three parameters (scene_path, type_filter, name_pattern). It does not mention any of them. The agent cannot know what values to pass, how filters work, or the format of scene_path. The description adds zero semantic value beyond the raw schema.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose3/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states a clear verb ('Finds') and resource ('nodes in scene'), which prevents it from being a pure tautology. However, it is vague: it doesn't specify what kind of nodes, what 'find' means (search by criteria, traversal, etc.), or how it differs from sibling tools like inspect_scene_tree or get_node_properties. The purpose is clear enough to understand the basic action but lacks specificity to distinguish it.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    There is no guidance on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or differences from sibling tools such as inspect_scene_tree or get_node_properties. An agent has no information to decide whether this is the right tool for a given task.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    Annotations are absent, so the description carries the full burden of behavioral disclosure. The phrase 'Parses project.godot' implies a read operation but doesn't disclose side effects, error behavior, permission requirements, or return format. The agent cannot infer whether this returns a structured object, logs output, or just validates the file.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness3/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is extremely concise—one short phrase—and it is front-loaded with the verb. However, it under-specifies the tool: it lacks structure, organization, or any elaboration. While it wastes no words, it also fails to convey necessary information, making it more under-specified than appropriately concise.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool has a parameter, no annotations, no output schema, and a minimal description, it is woefully incomplete. An agent cannot determine the meaning of 'prefix', what the tool returns, or how it should be invoked correctly. For a tool with even one parameter, this level of omission is unacceptable.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The input schema has one 'prefix' parameter with no description, and schema description coverage is 0%. The tool description never mentions 'prefix' or provides any hint about its purpose. The agent has no way to know how to use this parameter, making the tool effectively incomplete.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states a specific verb ('Parses') and resource ('project.godot'), making the tool's purpose clear and distinct from siblings like run_tests or export_project, none of which reference project.godot. However, it doesn't clarify what the parse result is or how it's returned, leaving some ambiguity about the actual output.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided on when to use this tool versus alternatives. The description simply states the action without any context about expected use cases, prerequisites, or conditions under which another tool would be more appropriate. With 20 sibling tools, this omission is significant.

    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. The description only states 'Returns node hierarchy' without indicating whether this is a read-only operation, how the hierarchy is structured (e.g., full tree or immediate children), or any potential side effects. It is too terse to convey meaningful behavioral traits beyond the obvious.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is extremely concise—only three words—but this brevity is under-specification rather than effective conciseness. It lacks the structure needed to convey essential information, such as parameter specifics or usage context. While every word earns its place, it omits crucial details, making it insufficiently informative.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the complexity of the tool's environment (many sibling tools, no output schema, undocumented parameter), the description is incomplete. An agent needs to know what scene_path refers to, what the hierarchy includes (e.g., nodes only or properties as well), and how it differs from related tools. The current description leaves these gaps unaddressed, making it barely adequate for correct invocation.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The input schema has a single parameter, scene_path, with no description and 0% schema coverage. The description does not mention scene_path at all, so it adds no meaning about what the parameter expects or how it is used. With zero coverage, the description must compensate, and it fails to do so.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states a clear verb ('Returns') and a specific resource ('node hierarchy'), which immediately conveys the tool's core function. However, it does not differentiate this from sibling tools like find_nodes or get_node_properties, so an agent may struggle to know which one to pick for a given task.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, common use cases, or exclusions. An agent would have to infer usage from the name and description alone, which is inadequate given the large set of similar 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 full burden for behavioral disclosure. It only mentions 'Lists', implying a read operation, but doesn't describe return format, filtering behavior, or any side effects. This is insufficient for a tool with no annotation support.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness2/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single phrase, which is concise, but it is under-specified rather than efficiently structured. It offers almost no useful information beyond the tool name, so every word is present but fails to add value.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given that the tool has an optional parameter and no output schema, the description should at least explain the filter's purpose and the nature of the returned resources. It does neither, leaving key aspects undocumented.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The single parameter type_filter has no schema description (coverage 0%), and the description does not mention it at all. The agent has no guidance on what values to provide or how filtering works, making the parameter effectively opaque.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states the verb 'Lists' and the resource 'project resources', providing a clear basic purpose. However, it does not differentiate from siblings like get_resource_info or get_resources_dependencies, which also deal with resources, so the scope is not fully clarified.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided on when to use this tool versus alternatives. With many resource-related siblings (get_resource_info, get_resource_dependencies, etc.), the description gives no context for selecting this tool.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions 'headlessly', which is a mode of operation, but does not explain side effects, whether the scene is modified, required environment, or expected outcomes. This is minimal disclosure and leaves the agent guessing about the tool's side effects and safety.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single, concise sentence with no filler words. It is front-loaded with the core action and subject. While it is under-specified, it is not verbose or redundant, so it earns credit for conciseness. The lack of detail is a completeness issue, not a conciseness issue.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's complexity (two parameters, no output schema, no annotations), the description is severely incomplete. It does not explain what 'runs' means in terms of output or side effects, how to handle timeouts, what success looks like, or any error scenarios. An agent has almost no information to make a correct invocation, so completeness is minimal.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The input schema has 0% description coverage, and the tool description does not mention either parameter (scene_path or timeout_ms). The agent receives no explanation of what these parameters mean or how to format them. The description fails to compensate for the schema's lack of detail, making this dimension critically weak.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states a specific action ('Runs') on a specific resource ('scene') with a method ('headlessly'). It distinguishes from sibling tools like validate_scene and inspect_scene_tree, which have clearly different purposes. However, it lacks any further elaboration, so it does not fully reach the highest tier.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description provides no guidance on when to use this tool versus alternatives, no context about the intended workflow, and no exclusions. An agent is left to infer its place among the many sibling tools. This is a significant gap for a tool that could be choosen over others.

    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 provided, the description carries the full burden of behavioral disclosure. It only says 'Validates .tscn' without detailing what validation checks (syntax, resources, references), what the tool returns (success/failure, error messages), or any side effects. This is insufficient for an agent to understand the tool's behavior beyond the bare action.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness3/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is extremely concise (four words), which is efficient, but it is under-specified to the point of lacking essential details. While it is front-loaded with the verb and resource, the brevity does not serve the agent's needs; it is more under-specification than appropriate conciseness.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a tool with one parameter, no output schema, and no annotations, the description is expected to provide a complete picture of the tool's purpose, parameters, and behavior. It fails to do so—it gives no information about expected inputs, validation outcomes, or how to interpret results, making it inadequate for reliable invocation.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The input schema has zero description coverage, and the description does not mention the scene_path parameter at all. The agent must guess that scene_path refers to the file path of the .tscn file, but no additional meaning or format guidance is provided, leaving the parameter semantics completely undisclosed.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states a clear verb ('validates') and a specific resource ('.tscn'), which identifies it as a validation operation for Godot scene files. This distinguishes it from sibling tools like validate_script (script validation) and run_scene (execution), though it doesn't explicitly mention those alternatives.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided on when to use validate_scene versus alternatives like validate_script or inspect_scene_tree. The description does not explain the context for validation, such as pre-export checks or debugging, leaving the agent to infer usage from the tool name alone.

    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 disclosing behavior. 'Formats' implies an action but does not state whether the file is modified in place, whether it returns formatted text, or what side effects occur. This is a significant gap for a tool that likely mutates a file.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness3/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is extremely concise (two words), which is front-loaded and free of fluff. However, it is under-specified for an actionable tool definition, so the conciseness comes at the expense of necessary detail.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    The tool is simple with one parameter, but the absence of any behavioral or return information, combined with no annotations and no output schema, leaves an agent unable to predict the outcome. It does not explain whether the file is rewritten or whether the result is returned.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters2/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The schema has zero description coverage for the only parameter, script_path, and the description adds nothing beyond the parameter name. The name suggests a file path, but there is no explanation of expected format, relative/absolute path, or constraints, which the description should compensate for.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description 'Formats GDScript' clearly states the verb (format) and resource (GDScript). It is distinct enough from siblings like validate_script and run_tests, but it does not explicitly differentiate itself or mention what formatting entails.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    There is no guidance on when to use this tool versus alternatives such as validate_script. No mention of prerequisites, typical workflows, or situations where this tool would be inappropriate. The usage context is entirely absent.

    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 only states the basic action without disclosing the return format, whether it is a read-only operation implicitly, or any side effects. The description is too sparse to inform an agent about expected outcomes or constraints.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single sentence with no redundant words. It is front-loaded with the verb and noun. While extremely brief, it is concise and does not waste any space. The structure is appropriate for the minimal information it provides.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's simplicity (1 parameter, no output schema), the description is incomplete. It lacks any details about the expected search term format, the nature of the returned documentation, or how to interpret results. An agent would not have enough information to use the tool correctly without additional assumptions.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The schema describes a single parameter 'search_term' with no description, and the schema description coverage is 0%. The tool description does not explain what should be placed in 'search_term' or how it is used. The description adds no semantic value beyond the raw type 'string', so an agent cannot infer appropriate input.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the verb 'gets' and the resource 'Godot documentation', making the tool's purpose unambiguous. None of the sibling tools relate to documentation, so it is naturally distinct. However, it does not elaborate on what kind of documentation or how results are returned, leaving some ambiguity.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    There is no guidance on when to use this tool versus alternatives. While no sibling tool appears to serve the same purpose, the description does not explicitly say 'use this when you need to look up Godot documentation'. An agent is left to infer usage from the name and minimal description.

    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 only states the operation and directionality, but does not mention potential side effects (though likely read-only), error behavior for invalid inputs, or return format. This is minimal and leaves room for agent confusion about edge cases.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single concise sentence with no redundancy. It front-loads the verb 'Resolves' and communicates the core function efficiently. It is appropriately sized for the tool's simple complexity, though it could benefit from a bit more detail without jeopardizing brevity.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's simplicity (one parameter, no output schema, no annotations), the description is mostly complete for a basic understanding. However, it lacks information about return values (what exactly is returned), error handling, and possible limitations. For a conversion tool, knowing the response format is important, so the description is somewhat incomplete.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters3/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The schema has no descriptions (0% coverage), so the description must compensate. It does add meaning by explaining that the parameter 'path_or_uid' can be either a UID or a path and the tool returns the opposite. However, it does not specify formats, validation rules, or how the tool determines which type is passed. This is sufficient for a single-string parameter but lacks depth.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states a specific action (resolves) and the bidirectional relationship (UID to path or vice versa). It distinguishes itself from sibling tools, none of which explicitly handle this conversion. However, it lacks specificity about what constitutes a UID or path (e.g., file paths, resource paths), which slightly reduces clarity.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided on when to use this tool versus alternatives. The description does not mention any sibling tools or conditions for selection. The use case is only implied (when you need to convert between UID and path), but there is no explicit 'use this when' or 'not for that' guidance.

    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. 'Returns export presets' is essentially a paraphrase of the tool name and reveals nothing about the nature of the return value, ordering, or any side effects. Minimal behavioral context is provided.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single clear sentence that is appropriately short for a parameterless getter. It is front-loaded with the action and resource, with no verbosity. It could benefit from a touch more context but remains efficient.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a zero-parameter, no-output-schema tool, the description is almost sufficient. However, it does not explain what export presets are or how they might be used, which could be relevant for an agent deciding whether to call this tool. Given the lack of annotations and schema detail, a bit more context would make it more complete.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters4/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    There are zero parameters, so no parameter documentation is needed. The schema already covers everything (100% coverage with no properties). The description adds no parameter meaning but none is required, so a baseline of 4 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states a clear verb ('Returns') and a specific resource ('export presets'). While it doesn't explicitly differentiate from sibling tools like export_project, the name itself makes the purpose unambiguous. It lacks explicit sibling differentiation, so a 4 is appropriate.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, common use cases, or what distinguishes it from export_project or get_project_settings. The agent is left to infer usage context.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'executes tests', but does not mention potential side effects, whether it blocks, returns output, or how failures are reported. For a tool that runs arbitrary scripts, this lacks critical behavioral detail and could lead the agent to expect different outcomes than what actually occurs.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single, concise sentence that states the core purpose immediately. There is no redundancy or filler; it efficiently conveys the essential information.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's simplicity (one optional parameter, no output schema), the description is minimally adequate. However, it omits any mention of return values, test result reporting, or whether it requires a specific environment. For a tool that executes arbitrary code, this missing context could be significant, but given the low complexity, a score of 3 is reasonable. The agent might need additional info to call it correctly in a broader workflow.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters3/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The schema covers the single parameter test_script with a clear description and example, so the schema alone is sufficient. The main description does not add any additional meaning about the parameter—it simply mentions 'custom runner' without elaborating on the parameter's format or constraints. Since schema coverage is 100%, the baseline 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the verb 'Executes' and the resource 'tests', and it specifies the two execution modes: GUT or a custom runner. It is distinct from sibling tools like validate_script or run_scene, which focus on validation or running scenes. However, it does not elaborate on what 'tests' means in this context or how it differs from other test-related tools, so it stops short of a perfect 5.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., a project must be open), nor does it suggest when to use GUT versus a custom runner. The description simply states the action without any contextual advice, leaving the agent to infer usage.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • 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 only states that it lists open scenes and requires an open editor, but does not describe the return format, error conditions, or side effects (presumably read-only). The prerequisite is a precondition, not a behavior. This is minimal at best.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single, compact sentence that front-loads the action and includes the one critical condition. No filler, no repetition. It earns a 5 for efficiency.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    The tool is simple (no params, no output schema), so the description is nearly sufficient. However, it does not reveal what the scene list looks like (names, paths, objects) or how errors are reported. Given the absence of annotations, a bit more detail on the return value would help an agent use it correctly.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters4/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The tool has zero parameters, and the schema is fully covered (100% coverage vacuously). Per the rubric, 0 params earns a baseline of 4. The description does not need to add parameter semantics, and it does not.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    States a specific verb ('Lists'), resource ('open scenes'), and context ('in editor'). The purpose is clear and unambiguous, though it does not explicitly distinguish itself from sibling tools like run_scene or inspect_scene_tree. A brief contrast would push it to 5.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    Provides a prerequisite ('requires open editor') but gives no guidance on when to choose this tool over alternatives. No mention of exclusions, complementary tools, or typical use cases. The agent is left to infer when this is the right call.

    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 carry the full behavioral burden. It only says 'Gets' and 'requires open editor', implying a read operation, but fails to disclose error behavior (e.g., what happens with no editor open) or the format of the returned selection. This is a significant gap for an unannotated tool.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single, efficient sentence that front-loads the action and includes a key prerequisite. Every word earns its place; no fluff or redundancy.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    For a simple parameterless getter, the description covers the basic purpose but lacks details about return value structure and error handling. Since there's no output schema, the agent must infer behavior. This is slightly under-specified but acceptable for the tool's simplicity.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters4/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The tool has zero parameters and an empty schema. With no parameters, there's nothing for the description to add beyond the schema; the baseline of 4 applies as no compensation is needed.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states a specific verb 'Gets' and resource 'current editor selection'. While it doesn't explicitly differentiate from siblings, the name is self-explanatory and the action is clear. It's unambiguous about what it retrieves.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines3/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description notes a prerequisite ('requires open editor'), giving some usage context. However, it provides no guidance on when to prefer this tool over alternatives like get_open_scenes or find_nodes, nor any exclusions. The condition is useful but incomplete.

    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

godot-mcp MCP server

Copy to your README.md:

Score Badge

godot-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/zbrkic/godot-mcp'

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