godot-mcp-omni

by Stankjedi

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.3.0-codex
Disambiguation5/5
Each tool targets a distinct aspect of Godot development (assets, batch, docs, editor, meta, project, runtime, scene, script) with clear, non-overlapping descriptions.
Naming Consistency5/5
All tools follow a consistent 'godot_<domain>' pattern, making it easy for agents to infer each tool's purpose from its name.
Tool Count5/5
With 9 tools, the scope is well-calibrated—comprehensive enough for full Godot workflows without being bloated or sparse.
Completeness5/5
The tool surface covers asset handling, project management, scene/script editing, runtime control, documentation, and editor integration, leaving no obvious gaps for typical Godot development tasks.
Average 3.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation is present, but the description adds no additional behavioral context. It does not clarify that write and edit actions are destructive while list, read, and check are safe. With annotations already indicating destructiveness, the description fails to add meaningful behavioral details beyond what is already structured.
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 concise (one sentence), which is good for brevity, but it omits the 'edit' action and lacks structure. It is not front-loaded with the most critical information (e.g., the action enum is essential but not highlighted). The sentence is clear but marginal for a tool with 8 parameters.
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 (8 parameters, action enum, output schema), the description is too minimal. It does not explain that the action parameter is required, how different actions map to other parameters, or the role of projectPath. The output schema exists but the description does not reference it. The context feels incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description provides a high-level overview but does not add meaning beyond the existing parameter descriptions. It does not link actions to specific required parameters or explain the interplay between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool handles reading, writing, listing, and syntax-checking of GDScript/C# files. It is specific about the resource type (scripts) and actions, which helps distinguish from sibling tools like godot_scene or godot_asset. However, it omits the 'edit' action present in the schema, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like godot_editor or godot_batch. There is no mention of prerequisites, context, or when to avoid using it. The description merely lists actions without providing decision-making 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 provide destructiveHint:true, but the description adds no behavioral context beyond the action list. It does not mention side effects, permissions, or safe usage.
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 listing all actions is concise and front-loaded. Could benefit from structure (e.g., listing actions), but it efficiently conveys core functionality.
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 8 parameters, multiple actions, and output schema, the description is too minimal. It fails to explain which parameters are needed for which actions or discuss outcomes.
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 covers 100% of parameters with descriptions. The description's overview of actions adds little extra meaning beyond the schema. 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 lists specific actions (version, run, stop, smoke, logs, export) with clear verbs, distinguishing it from sibling tools that focus on assets, projects, scenes, etc. However, it does not explicitly state it manages the Godot runtime.
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. The description simply enumerates actions without contextual usage hints.
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 annotation declares destructiveHint: true, so the description's mention of creation/node operations aligns. The description adds 'headless' context, which is useful beyond annotations. However, it does not elaborate on side effects, permissions, or error conditions.
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 a single sentence with no wasted words, but it is vague and lacks structure. It does not front-load critical information or use bullet points. Could be more informative without added 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?
With 11 parameters, a single sentence is insufficient to cover the tool's scope. While an output schema exists, the description fails to convey key details like which actions are read-only vs destructive, or how steps work. The tool is complex but the description is too brief.
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 high (91%), so the description does not need to explain parameters in detail. The description provides minimal extra meaning beyond the schema, simply restating the action types. 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 tool reads scene text and performs headless scene creation/node operations. It uses a specific verb-resource combination ('Read...perform'). However, it does not distinguish from sibling tools like godot_asset or godot_batch, which could also involve scene operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention prerequisites, when-not to use, or suggest alternative tools for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool can be destructive (import, mkdir), which aligns with the destructiveHint=true annotation. However, it lacks detail on side effects, such as whether existing files are overwritten or if permissions are required. The annotation provides the safety context, so the description adds moderate value.
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 that efficiently lists the tool's capabilities. While it is compact, it could be improved by structuring actions more clearly or indicating the primary action parameter.
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 7 parameters, outputs, and a destructive annotation, the description is too brief. It does not cover error scenarios, return value structure, or usage patterns for individual actions, which limits its completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters having descriptions in the schema. The tool description groups parameters by action but does not add new semantic detail beyond what is already in the schema. Thus, the description provides minimal added value for parameter understanding.
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 lists the main actions (scan, import, resolve UIDs, create folders), which correspond to the action enum. It's specific about the tool's purpose but does not differentiate it from sibling tools like godot_batch or godot_project, which may have overlapping capabilities.
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 are no usage conditions, prerequisites, or exclusion criteria mentioned, leaving the agent to infer applicability from the action list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that dump_api writes a cache under .godot_mcp/api, revealing a side effect. However, it does not discuss other behavioral aspects (e.g., whether search_classes or class_info require network calls or have rate limits). Annotations only provide idempotentHint:false, which is consistent but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main purpose without any fluff. Every sentence adds value, and the structure is clear.
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 an output schema existing, the description does not explain the different actions (dump_api, search_classes, etc.) in sufficient detail for an agent to choose correctly. With 9 parameters and 4 action enums, more context about each action's purpose and typical use cases would be necessary for complete guidance.
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?
All parameters have descriptions in the schema (100% coverage), so the description adds no new parameter-level meaning beyond the schema. The mention of caching relates to the tool's behavior, not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool dumps/searches Godot API docs including classes, methods, properties, and command-line help. It distinguishes from siblings (godot_asset, godot_project, etc.) by focusing solely on API documentation. However, it could be more specific about the search capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer context from the name and sibling tools. A 'when-not' or alternative mentioning would improve this.
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 destructiveHint=true, indicating potential destruction. The description adds that writes are 'constrained to the Godot project root,' which mitigates risk but doesn't detail other 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?
Two concise sentences, front-loaded with key actions and a safety constraint. Slightly improved structure could include bullet points for actions, but it's 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?
Given the tool has 14 parameters, one required enum for actions, and an output schema, the description is adequate but minimal. It covers scope but omits details on parameter usage or action-specific behavior.
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 description adds little about parameters beyond listing actions. Baseline 3 is appropriate as the description provides minimal additional meaning.
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 lists actions (discover, inspect, scan, read, safely edit) and resource (project-root files). However, it does not differentiate from sibling tools like godot_asset or godot_scene, which may also involve files, so it's not fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'safely edit' implies a safe usage context, but no when-not-to-use or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. The description adds context about live editor RPC and connection setup, but does not detail behavioral traits like authentication, rate limits, or side effects beyond the generic 'perform RPC'.
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?
Single sentence of 16 words, front-loaded with key actions, no redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (14 parameters, output schema, nested objects), the description covers the core functionality. Output schema exists so return values need no explanation. Missing guidance on usage contexts, but otherwise 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?
Schema coverage is 86% (high), so baseline is 3. The description adds value by framing parameters within the overall purpose of connecting and performing RPC, helping interpret parameters like host, port, token, and action.
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?
Description clearly states it syncs/connects to the in-editor bridge and performs live editor RPC, listing specific capabilities like scene tree, selection, inspection, and properties. It distinguishes itself from sibling tools by being the low-level bridge manager, but does not explicitly differentiate.
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. The description only states what it does, without any context for selection among sibling tools or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists the actions (server_info, doctor, tool_help, codex_profile), which adds context beyond the annotations (readOnlyHint, idempotentHint). It does not contradict annotations and clearly indicates a safe, read-only, idempotent 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 sentence that front-loads key information. It is concise, contains no filler, and effectively communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations cover safety, the description is sufficient for a meta tool. It lists actions and hints at usage, though it could briefly explain when to use each action.
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 100% coverage with descriptions for all 4 parameters. The description lists the action enum values but does not add significant meaning beyond what the schema provides. Baseline 3 is appropriate.
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 explicitly lists the tool's capabilities (server info, doctor checks, tool help, codex profile) and distinguishes it from sibling tools by stating 'Start here.' This makes it clear that it's a meta-information tool, not for domain-specific tasks.
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 phrase 'Start here' implies it is the initial tool to use, but it does not specify when to avoid it or provide alternatives. While the context suggests it is for meta queries, no explicit usage guidance or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint: true. The description adds behavioral details: bounded execution (implied by maxSteps), dryRun capability, and stopOnError. No contradiction; it supplements the annotations with additional 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 two sentences, front-loading the core purpose without any extraneous information. Every sentence serves a clear role.
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?
While the description covers purpose and usage context, it omits details about execution order (sequential), result aggregation, and that steps can call any Godot tool. Output schema exists but is not shown; given the tool's complexity, more execution behavior context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter is already described in the schema (steps, dryRun, maxSteps, stopOnError). The description adds no additional meaning beyond what the schema provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool runs a bounded sequence of other Godot MCP tool calls, using specific verb 'run' and resource 'bounded sequence'. This clearly distinguishes it from sibling tools that handle individual asset, doc, editor, etc. tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is 'useful for Codex multi-step workflows and recovery loops', providing clear context for when to use. However, it does not explicitly state when not to use or compare to alternatives (e.g., using individual tools directly).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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

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