Godot Agent Loop

by beremaran

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation3/5
Most tools are clearly distinct by domain (editor vs running game vs inspect), but get_debug_output, game_get_errors, game_get_logs, and game_get_debug_output-type overlap in capturing output, creating ambiguity. game_scenario and game_wait_until have identical placeholder descriptions ('Property waits need reflection'), making them indistinguishable.
Naming Consistency2/5
The naming is mixed: most use verb_noun snake_case (get_godot_version, run_project), but several 'game_*', 'godot_*', and 'editor_*' prefixes follow different conventions, and 'verify_project' vs 'run_project_tests' use similar verb phrases for different actions. The game_* group is consistent internally but the prefixes across the server are arbitrary.
Tool Count4/5
20 tools is on the high end but defensible for the apparent scope of controlling a Godot editor session, running tests, and inspecting a live game. It's slightly heavy, likely bordering the 16-25 range, but each tool maps to a plausible action in the workflow.
Completeness4/5
The surface covers the full lifecycle well: editor control (session, transaction) is paired with run/stop project, and inspection tools (scene tree, UI, node info, screenshot) cover runtime diagnosis. Minor gaps exist—there's no explicit save/closing_session tool, and debug/log/error retrieval is spread awkwardly across get_debug_output, game_get_errors, and game_get_logs—but core workflows are covered.
Average 2.7/5 across 20 of 20 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 218 commits in the last 12 weeks
- Last stable release on August 4, 2026
- 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.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?
The description offers no behavioral details beyond annotations. It does not explain execution flow, side effects, or constraints. No contradiction with annotations, but transparency is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but cryptic, lacking clarity. Conciseness is not beneficial if it sacrifices understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex schema and lack of purpose explanation, the description is severely incomplete. Even with an output schema, the tool's function is unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema thoroughly describes each parameter. The description adds no value but does not detract. Baseline 3 is appropriate.
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 'Property waits need reflection;' is cryptic and does not state what the tool does. It fails to convey that this tool executes a game scenario defined by a sequence of steps.
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 on when to use this tool versus siblings like game_click or game_get_ui. The description provides no context for 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?
The annotations indicate destructiveHint: true, but the truncated description adds no behavioral context beyond that. It does not explain what gets destroyed or the nature of the compound operation.
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 incomplete sentence, which is under-specified rather than concise. It fails to convey essential information.
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 (7 parameters, 10 operation types) and the existence of an output schema, the description is woefully inadequate. It provides no context about operations, order, or return values.
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 description adds no parameter information. Although the schema has 100% coverage, many parameter descriptions are also truncated, so the schema itself is incomplete. The description does not compensate for this.
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 is truncated ('Apply one validated compound scene e…'), making its purpose vague. It does not clearly state what is being applied, nor does it distinguish from sibling tools like 'modify_scene_node' or 'create_scene'.
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 such as 'modify_scene_node' or 'create_scene'. The description lacks any context about 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?
Annotations already indicate destructiveHint=true but the description adds no behavioral context beyond 'run'. The truncated phrase 'capture ou' suggests output capture but is unclear. No mention of side effects like stopping previous instances or system state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short (one truncated sentence). While concise, it sacrifices crucial information. A good description should be front-loaded but complete; this is not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is severely incomplete given the tool's complexity (3 parameters, destructive, output schema). It fails to explain what capturing output means, how to interpret output, or any prerequisites. Compare to sibling tools, this is inadequate.
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?
Input schema has 100% description coverage, but descriptions are also truncated (e.g., scene: 'Optional:', timingMode: 'realtime follows display/VSync;'). The tool description does not add any additional meaning to the parameters; it is too short to explain them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with 'Run the Godot project', which is essentially the same as the tool name, but adds 'and capture ou…' which hints at output capture. However, it's incomplete and does not clearly distinguish from sibling tools like run_project_tests or game_* tools.
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 on when to use this tool versus alternatives such as run_project_tests or individual game interaction tools. The description is too short to include any 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?
Annotations are sparse (readOnlyHint=false, destructiveHint=false) but the description adds no behavioral context. It does not explain what happens when conditions are met or how the tool affects game state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks substantive information. It is concise only in length, not in conveying useful guidance.
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 complex input schema with oneOf for 6 condition types and 11 parameters, the description provides no context about when to use each condition, expected output, or relationship to sibling tools. It is wholly insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter descriptions cover all 11 parameters (100% coverage). The tool description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate.
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 'Property waits need reflection;' is cryptic and does not clearly state the tool's purpose. The title and schema indicate waiting for conditions, but the description fails to clarify that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings or which condition to choose. The description lacks any usage context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, readOnlyHint=false, but description only adds 'hidden' context, which is minimal. No details on side effects, permissions, or what tools are callable.
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?
Description is a single truncated sentence, lacking necessary information. Under-specification, not efficient 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?
Given the tool's complexity (open world, destructive, many siblings), the description fails to explain what hidden tools are, how to discover them, error behavior, or relationship to godot_catalog. Output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description provides no parameter details beyond what schema already offers. No added meaning for toolName or arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Execute one named hidden Godot tool' but is truncated, leaving vague scope. The verb 'execute' and resource 'named hidden Godot tool' are present but insufficient to distinguish from siblings like create_scene or run_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. The description does not mention conditions, prerequisites, or alternative tools.
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 contradiction with annotations: readOnlyHint=true, idempotentHint=true, destructiveHint=false align with a catalog/read tool. The schema itself describes action as 'Read-only catalog action', which reinforces the safe-read behavior. However, the description adds no behavioral context beyond what annotations already provide — no mention of result ranking, pagination, or how describe differs in output from search. With comprehensive annotations covering the safety profile, the description adds minimal value here.
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 truncated sentence), which could be concise — but it's incomplete rather than deliberately minimal. A truncated sentence that trails off ('the complete Godot…') is a structural defect, not concise prose. One would expect at least a full sentence articulating what the catalog contains and its two modes of operation.
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?
Despite the truncated description, the tool benefits from a 100% documented schema, 8 enum-filtered parameters, comprehensive annotations, and an output schema. The complexity of this tool (11 params, two action modes, 8 filters) is largely self-documented through the schema. However, the description could meaningfully enhance completeness by explaining the search-vs-describe distinction and how filters combine — a gap the schema alone partially fills but doesn't fully cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 11 parameters have descriptions in the schema itself (e.g., 'Optional required-state filter', 'Required for describe'). The description adds nothing beyond what the schema documents. Baseline 3 is appropriate since the schema does the heavy lifting, and the description doesn't need to duplicate it.
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 reads 'Search or inspect the complete Godot…' which is truncated and incomplete. The verb is present (Search/inspect) but the resource is truncated mid-sentence ('Godot…'), making the purpose only partially clear. The name 'godot_catalog' and title 'Godot Catalog' suggest a catalog/metadata tool, and the two actions (search/describe) are visible in the schema, but the description itself fails to fully convey the scope.
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 gives no guidance on when to use this tool versus alternatives. With 19 sibling tools ranging from run_project to game_screenshot, an agent cannot tell from the description alone when to consult the catalog versus using a specific operation tool. No when-to-use, when-not-to-use, or filtering strategy is given, despite 8 filter parameters (state, domain, effect, backend, mutation, privilege) that would clearly benefit from usage 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?
Annotations are all false (no hints), and the description does not disclose behavioral traits like whether tests are run locally, if files are modified, or if a project must be open. No additional context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single truncated sentence ending with an ellipsis, under-specified and not well-structured. It fails to concisely convey the tool's function despite the schema 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?
Given the complex oneOf schema, 7 parameters, and presence of output schema, the description is severely incomplete. It does not explain the distinction between discover and run, frameworks, or return values. The schema compensates partially but the narrative is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameter meanings. The description adds no extra semantic value beyond restating the action parameter. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Discover or run native, GUT, and GdU…' indicating test operations, but it is truncated and lacks specificity. Without sibling context, the purpose is vague; however, the title 'Run Project Tests' helps. Score 3 as it gives basic verb+resource but with 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?
No guidelines on when to use this tool versus siblings like run_project or verify_project. No context on prerequisites or scenarios. The description does not address alternatives or when not to use.
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 all false, so description must disclose behavior. The truncated description only mentions running assertions and capturing something, but does not clarify side effects, permissions, or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single truncated sentence, which is under-specification rather than conciseness. It fails to provide a complete, well-structured overview.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, assertions array) and existing output schema, the description is far too brief to inform an agent about the tool's full capabilities and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema; it does not elaborate on parameters like assertions or teardown.
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 fragment 'Run bounded assertions and capture e…' vaguely indicates running assertions on a project, but it is incomplete and uses jargon. Among sibling tools like run_project_tests or read_scene, this tool's specific role is not clearly distinguished.
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 verify_project versus siblings like run_project_tests or read_scene. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is known to be safe and idempotent. The description adds no behavioral details beyond its basic function, missing context about pagination, ordering, or whether errors are consumed after retrieval.
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 truncated sentence fragment ('Get new push_error/push_warning mess…'). It is not properly structured and appears cut off, which harms clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete and fails to clarify what 'new' means, how errors are ordered, or whether errors are persistent. The tool is simple, but the description lacks key context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter 'maxItems' is described in the schema as 'Maximum unread error lines returned.' The description adds no additional parameter information, so baseline score of 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 states 'Get new push_error/push_warning messages' which clearly indicates the tool retrieves error/warning messages. The name and title align, and it distinguishes from sibling 'game_get_logs' which likely gets general 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool vs alternatives, any 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?
Annotations show readOnlyHint=false, destructiveHint=false, idempotentHint=false, providing minimal behavioral signal. The description is truncated and adds no behavioral context about side effects (launching editors, creating sessions, disconnecting), timing implications, or what gets modified. For a session-management tool that can launch editor processes, this is a significant transparency gap.
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?
Intentionally truncated to a single fragment phrase. While short, this is under-specification rather than conciseness - the truncated content suggests the full description would be longer but valuable context is lost. The visible text provides only a partial action list and no 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?
Despite having an output schema, the tool is complex: it has a oneOf schema with action-dependent parameter constraints, multiple required params, and three distinct operational modes with different semantics. The description addresses none of this complexity - no guidance on when sessions would need to be disconnected, what status inspection returns, or how ensure differs from just launching a project (run_project sibling). A richer description is needed for a tool with this much branching logic.
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?
While schema_description_coverage is 100%, the descriptions are themselves truncated ('For ensure, launch an editor only af…', 'For action=ensure only:'). The schema does clarify that launchIfNeeded only applies to ensure and timeoutSeconds also applies only to ensure via the not{} constraints in the schema, but the description adds the conditional logic context that the schema's bare enum values don't convey. The description bridges some gaps left by truncation.
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 'Discover, attach, inspect, or discon…' indicates a multi-purpose session management tool but is truncated and doesn't specify the resource (editor session for Godot) directly. The title and parameter schema reveal it manages Godot editor sessions (ensure/status/disconnect), but the description alone is vague about what the tool does or the resource it operates on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or differentiation from siblings like editor_transaction or run_project. The schema's oneOf structure and action enum imply three distinct usage modes (ensure/status/disconnect), but the description itself doesn't clarify when to choose this over sibling tools or how actions map to scenarios.
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 annotations already declare readOnlyHint and idempotentHint as true, and destructiveHint as false, so the description adds no additional behavioral context. It does not disclose what the returned tree includes (e.g., all nodes, only visible nodes) or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one truncated sentence) but front-loads the key action. However, the truncation reduces clarity, and it could be more complete without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks context about the returned structure (e.g., whether it returns the entire hierarchy or just a subset). For a tool that retrieves a tree, more details would help the agent understand the output format and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the only parameter maxNodes, so the description does not need to add much. It provides no extra semantics beyond the schema, such as default behavior or how the limit affects results.
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 'Get scene tree structure of the runn…' which clearly identifies the tool's purpose as retrieving the hierarchy of the game scene. It is specific enough to distinguish from sibling tools like game_get_node_info which returns details of a single 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/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 such as game_get_ui or game_get_node_info. The description does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read), idempotentHint=true, and destructiveHint=false. The description adds minimal behavioral context beyond 'Capture a PNG preview', not elaborating on side effects or return details. The annotations carry the burden.
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 truncated mid-sentence ('with dimension…'), making it incomplete. While conciseness is valued, this is under-specification rather than efficient writing.
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 has one optional parameter, an output schema (not shown), and simple functionality, a brief description could be adequate. However, the truncation and lack of parameter explanation leave it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'retainArtifact', but the description does not mention this parameter at all. It adds no extra meaning beyond what the schema already provides. 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 begins with 'Capture a PNG preview' which clearly indicates the tool's action (capture) and output format (PNG), and it is distinct from sibling tools like game_click. However, the description is truncated with 'with dimension…', 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 such as game_get_ui (which also captures visual state). The description does not mention use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false but idempotentHint=false. The description doesn't contradict annotations. However, it adds no behavioral context beyond 'stops the running project' — it doesn't clarify whether stopping is reversible via run_project, whether debug output is preserved, or what happens with pending editor transactions. With sparse annotations, the description carries the burden but adds little.
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 brief — a single partial sentence. While conciseness is generally good, the truncation ('pro…') suggests incompleteness rather than intentional minimalism. A complete description could add meaningful context like effect on debug sessions or project state.
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 a simple state-changing operation with 0 parameters and an output schema. Given this low complexity, the description is mostly adequate. However, it's truncated mid-word, and with no annotation coverage for what 'stopping' destroys or affects (e.g., debug session state), a slightly more complete description would help the agent understand side effects.
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 0 parameters with schema description coverage at 100%, so there are no parameters requiring documentation. Per the rubric, 0 params earns a baseline score of 4, and with no params to describe, this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Stop the currently running Godot pro…" clearly indicates a verb (Stop) and resource (the running Godot project). It distinguishes from the sibling run_project. However, the description appears truncated (ends mid-word with 'pro…'), losing potentially important context about scope or effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose is implied by the name and truncated description, there's no stated context like 'use after run_project' or prerequisites (e.g., only works if a project is running), nor exclusions about 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns 'new print output' from the running game, implying it only fetches unread logs. However, it does not explain if logs are marked read after fetch, or behavior when no logs exist.
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 short but truncated ('runnin…'), which makes it incomplete. While concise, the truncation harms clarity and reduces its effectiveness.
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 simplicity of the tool (1 optional param, no required params, output schema present), the description covers the basic behavior but fails to differentiate from similar tools or provide usage context. Annotations cover safety. Overall adequate but not complete.
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?
One parameter 'maxItems' with schema description 'Maximum unread log lines returned.' is clear. The tool description adds 'new print output' which aligns but does not provide additional meaning beyond the schema. With 100% schema coverage, 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 'Get new print output from the runnin…' combined with the tool name and parameter 'maxItems' (unread log lines) clearly indicates a read operation for new/unread logs from a running game. However, the truncation of 'runnin…' slightly reduces clarity and completeness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'game_get_errors'. The description lacks context for selection among sibling tools, which is critical for an AI agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, giving the agent a clear safety profile. The description is truncated and adds little beyond 'get output and err…', not disclosing details like whether this resets state, whether it's a snapshot vs stream, or how it relates to the engine runtime. With annotations present, the bar is lower, and the additions are minimal but not contradictory.
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 truncated mid-sentence with an ellipsis ('err…'), which is a structural failure—it doesn't complete its thought. While brevity is present, the description is under-specified rather than concisely complete. A complete but short description would score higher.
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 has an output schema, zero parameters, and good annotations, so much is structured. However, the description is truncated and doesn't clarify what 'debug output' includes (stdout, stderr, engine messages?) or how it differs from siblings like game_get_errors and game_get_logs. For a simple tool with strong annotations, this is borderline adequate but the truncation creates a gap.
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, so no parameter meaning needs to be added. With 0 params, the baseline is 4 per the rubric. The description doesn't need to document parameter semantics since there are none.
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 'Get the current debug output and err…' which identifies the verb (get), resource (debug output), and partially the scope (errors). However, it is truncated with an ellipsis that cuts off mid-thought, and it doesn't distinguish from siblings like game_get_errors or game_get_logs, which could overlap in scope. The name and title reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus game_get_errors, game_get_logs, or other diagnostic siblings. No context about whether this is the preferred tool for general debugging output or when alternatives should be chosen. The description provides no when/when-not direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds minimal behavioral context beyond the action of 'batch-check', which is consistent with the annotations. It does not contradict them.
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 truncated single fragment, not a complete sentence. While it starts with the core action, the truncation makes it feel incomplete and lacking clarity. It is not concise in a meaningful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (one required), an output schema, and annotations covering safety, the description is too minimal. It does not explain the output, the behavior for the two scope options, or any prerequisites. More context is needed for effective use, especially because the text is truncated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters. The description mentions 'git-chan…' which aligns with the 'scope' parameter enum value 'changed', but does not add additional semantic value beyond what the schema already provides. 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 'Batch-check GDScript files (git-chan…' clearly indicates the verb 'batch-check' and the resource 'GDScript files'. The truncation obscures the full scope, but the inferred 'git-changed' from the schema makes the purpose fairly clear. However, it could be more explicit about batch vs. single validation.
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 does not explicitly state when to use this tool over alternatives. The existence of a sibling 'validate_script' hints at a batch vs. single differentiation, but the description provides no direct usage guidance or exclusion 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating read operation. The description adds no additional behavioral context beyond the file notation, such as whether it returns failures on invalid paths or how errors surface. With annotations covering the safety profile, this is adequate but not enriched.
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 short sentence with zero wasted words. It front-loads the core purpose. However, given the tool's flexibility (compact vs full modes, property filtering), a bit more guidance could be justified, making it efficient but slightly under-specified for its feature set.
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?
An output schema exists, so return values don't need explanation. With good annotations and 100% schema coverage, the description needn't do much heavy lifting. Still, for a tool that supports two detail modes and optional property filtering, the description offers minimal guidance on how these features interplay, leaving some gaps for the agent to reason through.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (nodePath, detail, propertyNames) are already documented. The description itself adds no parameter-level meaning beyond what the schema provides; it does not clarify how propertyNames interacts with detail modes or give format examples. Baseline 3 is appropriate when schema carries the documentation load.
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 'Get compact or full node info' clearly states a verb ('Get') and a resource ('node info'), and it mentions the compact/full detail modes. It distinguishes reasonably from siblings like game_get_ui, game_get_scene_tree, and game_get_errors by focusing on node information specifically, though it doesn't explicitly differentiate itself from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (querying node info) but provides no explicit when-to-use guidance or exclusions. It doesn't mention when to prefer compact vs full detail, or how it differs from related siblings like game_get_scene_tree or game_get_ui. The brief phrase 'compact or full' hints at a usage choice but doesn't elaborate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide read-only and idempotent hints. Description adds 'visible' and 'bounded' context, but does not detail more nuanced behaviors. No contradiction with annotations.
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?
Single sentence, short and direct. Could be improved by completing the truncated fragment, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations and output schema (likely describing return format), the description covers core function. Could mention pagination or limits more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds little beyond 'bounded' and 'visible'—both implicitly covered by schema (maxElements and rootPath description hints at subtree).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get' and resource 'bounded list of visible UI elements', which distinguishes from sibling tools like game_get_scene_tree and game_get_node_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as game_get_scene_tree or game_get_node_info. Misses opportunity to clarify use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds no further behavioral details beyond the obvious 'Retrieve metadata'.
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?
Very short and to the point, but truncated (ends with '…'). No unnecessary words; however, the truncation reduces completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and annotations covering safety, the description is adequate but could mention what specific metadata is returned, especially given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes projectPath as 'Godot project path'. Description does not add any extra meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses clear verb 'Retrieve' and resource 'metadata about a Godot project'. It distinguishes well from sibling tools like get_godot_version or game_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_godot_version or verify_project. No exclusions or contextual advice provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully disclose the behavioral traits. The description adds no additional behavioral details beyond what annotations provide.
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 that immediately conveys the tool's purpose with no extraneous words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, an output schema exists, and annotations cover behavioral traits), the description is complete. It provides sufficient information for an AI agent to select and invoke this tool 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?
There are zero parameters, so the description has no burden to explain parameter semantics. The baseline of 4 applies, and the minimal description does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the installed Godot version, with a specific verb ('Get') and resource ('Godot version'). This directly distinguishes it from sibling tools that focus on projects, scenes, or game interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the tool is simple, mentioning that it is useful for verifying the environment before running project operations would improve it. Currently, usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/beremaran/godot-agent-loop'

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