Forge Engine MCP Server

by mxn2020

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: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific Godot editor operations, such as scene manipulation (add_node, move_node, remove_node), debugging (evaluate, set_breakpoint), file handling (list_files, get_script, set_script), and project control (run_project, stop_project). There is no significant overlap in functionality, making tool selection straightforward.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with the 'forge_' prefix, such as forge_add_node, forge_get_scene_tree, and forge_set_property. This uniformity enhances readability and predictability across the toolset.
Tool Count4/5
With 21 tools, the count is slightly high but reasonable for a comprehensive Godot editor integration covering scene management, debugging, file operations, and project control. It provides extensive coverage without being overwhelming, though it borders on the heavy side.
Completeness5/5
The toolset offers complete coverage for Godot editor interactions, including CRUD operations for nodes and scripts, debugging capabilities, project lifecycle management (run/stop), and utility functions like screenshot and status checks. There are no obvious gaps that would hinder agent workflows in this domain.
Average 3.3/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
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?
No annotations are provided, so the description carries the full burden. It states the tool adds a node but doesn't disclose behavioral traits such as whether this requires specific permissions, if changes are reversible, potential side effects (e.g., scene modification), or error conditions (e.g., invalid parent paths). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 appropriately sized and front-loaded, stating the core purpose in the first clause. It uses two sentences efficiently: one for the main action and parameters, and another for optional properties. There's no wasted text, though it could be slightly more structured (e.g., bullet points).
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 (a mutation tool with 4 parameters, no annotations, and no output schema), the description is incomplete. It lacks behavioral context (e.g., what happens on success/failure), doesn't explain the return values or potential errors, and provides minimal guidance. For a tool that modifies a scene tree, more completeness is needed to aid an AI agent effectively.
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 all parameters thoroughly. The description adds minimal value by listing the three required parameters (parent path, node type, name) and implying the optional 'properties' parameter, but doesn't provide additional semantics beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('Add a new node') and resource ('to the Godot scene tree'), making the purpose immediately understandable. It distinguishes from siblings like 'forge_move_node' and 'forge_remove_node' by specifying creation rather than modification or deletion. However, it doesn't explicitly contrast with all siblings (e.g., 'forge_set_property' for property setting).
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. While it's clear this creates nodes, there's no mention of prerequisites (e.g., needing an open scene), when not to use it (e.g., for modifying existing nodes), or explicit alternatives among siblings like 'forge_set_property' for property updates. The description assumes context without stating it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool evaluates an expression in a debug session, but doesn't describe what happens after evaluation (e.g., returns a value, logs output, affects state), potential side effects, error handling, or any constraints like session requirements. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it efficient and easy to parse, with no wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a debug evaluation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, how results are handled, or any behavioral traits like dependencies on an active debug session. This leaves significant gaps for an AI agent to understand the tool's full context 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?
The description implies the parameter is a GDScript expression to evaluate, but the input schema already provides 100% coverage with a clear description for the 'expression' parameter. The description adds no additional semantic details beyond what's in the schema, such as expression syntax examples or evaluation context, so it meets the baseline for high schema coverage.
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's purpose: evaluating a GDScript expression during a debug session. It specifies the verb 'evaluate' and the resource 'GDScript expression', making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like forge_execute_gdscript, which might also involve GDScript execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance, stating it's for 'during a debug session' but not explaining when to use this tool versus alternatives like forge_execute_gdscript or forge_set_breakpoint. There's no mention of prerequisites, limitations, or specific contexts where this tool is preferred, leaving the agent with little direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, if it requires the editor to be running, potential rate limits, or what format the output returns (e.g., plain text, structured logs). This leaves significant gaps for a tool interacting with an editor console.
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, direct sentence with zero wasted words. It front-loads the core purpose efficiently, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves console output. It doesn't explain what the output contains (e.g., errors, logs, timestamps), how 'recent' is defined, or prerequisites like needing the Godot editor to be active. For a development/debugging tool, this leaves critical context unspecified.
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, with the 'lines' parameter well-documented in the schema itself. The description adds no additional parameter semantics beyond implying 'recent' output, which is already suggested by the parameter's purpose. This meets the baseline for high schema coverage.
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 action ('Get') and target ('recent console output from the Godot editor'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like forge_get_properties or forge_get_script, which also retrieve information but from different sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like debugging, monitoring project execution, or how it relates to siblings like forge_run_project or forge_status, leaving the agent to infer context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' signals, implying a read operation, but doesn't clarify if it's safe, what format the signals are in, or any limitations like rate constraints or permissions needed.
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, clear sentence with zero waste. It's appropriately sized and front-loaded, efficiently conveying the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'signals' are in this context, the return format, or any behavioral traits, leaving significant gaps for a tool that likely returns complex data.
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 description coverage is 100%, so the input schema fully documents the 'nodePath' parameter. The description adds no additional meaning beyond implying the node is the source of signals, which aligns with the schema but doesn't provide extra context like examples or edge cases.
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 action ('Get') and resource ('all signals available on a node'), making the purpose understandable. However, it doesn't differentiate from siblings like 'forge_get_properties' or 'forge_get_scene_tree', which also retrieve node information, so it lacks specific distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Move a node') but fails to describe critical traits: whether this requires specific permissions, if it's destructive (e.g., affects scene state), what happens on failure (e.g., invalid paths), or any rate limits. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., error handling, side effects), usage context, or return values, which are essential for safe and effective tool invocation in this scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('path' and 'newParent') documented in the schema. The description adds no additional meaning beyond implying node relocation, so it meets the baseline of 3 where the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Move') and resource ('a node'), specifying the action of relocating a node within a scene tree. It distinguishes from siblings like 'forge_remove_node' (deletion) and 'forge_add_node' (addition), but does not explicitly differentiate from tools like 'forge_set_property' that might also affect node positioning, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites (e.g., needing an open scene), exclusions (e.g., not for moving nodes across scenes), or comparisons to siblings like 'forge_set_property' for property-based adjustments, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Open') but doesn't explain what 'Open' entails—e.g., whether it loads the scene for editing, triggers UI changes, requires the editor to be running, or has side effects like locking the file. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and efficiently communicates the core functionality, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficient for a tool that performs an 'Open' operation. It doesn't cover what happens after opening (e.g., success/failure states, editor response, or error handling), leaving the agent with incomplete context for proper invocation and interpretation.
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 description coverage is 100%, with the parameter 'path' fully documented in the schema as 'Path to the .tscn scene file'. The description doesn't add any additional meaning beyond this, so it meets the baseline of 3 where the schema handles the parameter documentation adequately.
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 action ('Open') and the target resource ('a scene file in the Godot editor'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'forge_get_scene_tree' or 'forge_save_scene', which 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 is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used for editing scenes versus just viewing them, or how it relates to tools like 'forge_get_scene_tree' or 'forge_save_scene'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't cover critical aspects like whether this requires a running project, if it's reversible, what happens on invalid inputs, or any rate limits. This is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after setting the breakpoint, error conditions, or dependencies on other tools. For a tool that modifies debug state, more context is needed.
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 description coverage is 100%, so parameters are fully documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain path format or line number constraints). This meets the baseline for high schema coverage.
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 action ('Set a breakpoint') and target ('in a GDScript file at a specific line'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'forge_evaluate' or 'forge_execute_gdscript' that might also involve debugging operations, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention prerequisites like needing an active debug session or how it relates to tools like 'forge_run_project' or 'forge_stop_project'. This leaves the agent without context for proper tool 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action 'set a property' but doesn't mention whether this requires specific permissions, if changes are reversible, potential side effects (e.g., on node behavior), or error conditions. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Set a property on a node') and follows with helpful examples. There is no wasted text, and it's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or return values, which are critical for safe and effective use. The examples help but don't compensate for the lack of broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (nodePath, property, value). The description adds minimal value by providing examples of property names ('position', 'color', 'energy', 'modulate'), which slightly clarifies the 'property' parameter but doesn't go beyond what the schema implies. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'property on a node', with specific examples like position, color, and energy. It distinguishes from siblings like forge_get_properties (which retrieves properties) and forge_move_node (which specifically moves nodes), though it doesn't explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't specify whether to use forge_move_node for position changes instead of setting the 'position' property directly, or when forge_set_script might be more appropriate for script-related properties. The description only gives examples without contextual rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves editable properties, implying a read-only operation, but doesn't clarify if it requires specific permissions, has rate limits, returns partial data on errors, or how it handles invalid node paths. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get all editable properties') and includes relevant examples. There is no wasted verbiage, and it directly communicates the tool's function without unnecessary details, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving node properties), lack of annotations, and no output schema, the description is minimally adequate. It specifies what properties are retrieved but doesn't cover behavioral aspects like error handling or output format. For a read operation with no structured output documentation, it provides basic context but leaves gaps that could hinder effective 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?
The description adds no specific meaning beyond what the input schema provides. The schema has 100% coverage with a clear description for 'nodePath' as 'Path of the node to inspect,' and the description doesn't elaborate on parameter usage, formats, or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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's purpose: 'Get all editable properties of a node in the scene' with specific examples (position, rotation, scale, type-specific properties). It uses a specific verb ('Get') and identifies the resource ('node in the scene'). However, it doesn't explicitly differentiate from sibling tools like forge_get_scene_tree or forge_get_signals, which might also retrieve node-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open scene), exclusions, or comparisons to siblings like forge_get_scene_tree (which might list nodes) or forge_set_property (which modifies properties). Usage is implied through the action 'Get all editable properties,' but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a listing operation but doesn't disclose important behavioral traits like whether it's read-only, what permissions are required, how it handles errors, or what format the output takes. For a file system operation with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple listing tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with 1 parameter fully documented in schema, the description is minimally adequate. However, with no annotations and no output schema, it should ideally provide more context about what the listing returns (e.g., file names, types, sizes) and any constraints. The current description meets basic requirements but could be more 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?
Schema description coverage is 100%, so the schema already documents the single parameter completely. The description mentions 'in a project path' which aligns with the schema's path parameter, but adds no additional semantic context beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose with a specific verb ('List') and resource ('files and directories'), and specifies the scope ('in a project path'). It doesn't distinguish from sibling tools, but it's unambiguous about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like forge_get_scene_tree and forge_get_properties that might retrieve related information, there's no indication of when this specific listing tool is appropriate versus other retrieval methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'save' implies a write operation but lacks details on permissions, file overwrites, error handling, or confirmation behavior. This is inadequate for a mutation tool with zero annotation coverage.
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, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a save operation (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'save' entails (e.g., file path, format, success indicators), leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is fine here. Baseline is 4 for zero parameters, as it avoids unnecessary details.
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 action ('Save') and the resource ('the currently edited scene'), making the purpose understandable. It doesn't explicitly distinguish from siblings like 'forge_open_scene' or 'forge_list_files', but the verb 'save' implies a write operation versus their read operations, providing some implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open scene), exclusions, or comparisons to siblings like 'forge_run_project' or 'forge_stop_project', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'execute arbitrary GDScript code' and 'in the editor context', but lacks details on behavioral traits: e.g., whether this is a read-only or destructive operation, if it requires specific permissions, what happens on errors, or if there are rate limits. The description is minimal and doesn't compensate for the lack of annotations.
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 short sentences with zero waste: the first states the purpose, and the second adds usage context. It's front-loaded and appropriately sized, earning its place efficiently.
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 (executing arbitrary code is a powerful, potentially risky operation), lack of annotations, no output schema, and minimal description, this is incomplete. It doesn't cover safety, return values, error handling, or how it integrates with the editor context, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'code' parameter is fully described in the schema as 'GDScript code to execute'), so the baseline is 3. The description doesn't add any parameter-specific information beyond what the schema provides, such as syntax examples or constraints, so it meets the minimum but doesn't enhance 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 states the action ('Execute arbitrary GDScript code') and the context ('in the editor context'), which is specific and distinguishes it from siblings like forge_run_project (which runs the full project) or forge_evaluate (which might evaluate expressions). However, it doesn't explicitly differentiate from all siblings like forge_set_script or forge_get_script, keeping it at 4 rather than 5.
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?
It provides some usage context ('Useful for quick automation tasks'), which implies when to use it, but doesn't explicitly state when not to use it or name alternatives. For example, it doesn't clarify if this is for one-off scripts vs. persistent changes, or how it differs from forge_evaluate. This is implied guidance, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the tool removes a node, it doesn't describe critical behaviors: whether this is destructive/permanent, if it requires specific permissions, what happens to child nodes, error conditions (e.g., invalid path), or return values. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Remove a node') and includes essential context ('from the Godot scene tree by its path'). Every element earns its place.
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 this is a mutation tool (removing nodes) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like destructiveness, error handling, or what happens upon success/failure. For a tool that modifies scene state, more context is needed to use it safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'path' fully documented in the schema (including an example). The description adds no additional parameter semantics beyond what's in the schema—it merely restates that removal is 'by its path.' With high schema coverage, the 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 clearly states the specific action ('Remove a node') and target resource ('from the Godot scene tree by its path'), distinguishing it from siblings like 'forge_move_node' (which moves rather than removes) and 'forge_add_node' (which adds rather than removes). It uses precise terminology that matches the domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the node must exist, if the scene must be open), exclusions (e.g., can't remove root nodes), or related tools like 'forge_move_node' for repositioning instead of removal. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a read operation, which is helpful, but lacks details like error behavior (e.g., if file doesn't exist), permissions needed, rate limits, or output format (e.g., raw text). For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes essential details (file types). Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, read-only), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on output format, error handling, or usage context, which could help an agent use it correctly. It's complete enough for a simple tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'path' fully documented in the schema. The description adds no additional meaning beyond implying the path must point to a .gd or .cs file, but this is already covered by the schema's example. Baseline 3 is appropriate as the schema handles parameter documentation.
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 specific action ('Read') and the resource ('source code of a GDScript (.gd) or C# (.cs) file'), distinguishing it from siblings like forge_set_script (which writes) or forge_list_files (which lists). It precisely defines what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., file must exist), exclusions (e.g., not for binary files), or compare to siblings like forge_get_output or forge_get_properties. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the file will be 'saved and reloaded,' which hints at persistence and editor integration, but lacks details on permissions, error handling, or side effects (e.g., overwriting existing content). More behavioral context is needed for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and outcome. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is minimal but covers the basic purpose. It lacks details on return values, error cases, or integration with other tools (e.g., forge_run_project), leaving gaps in 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%, so parameters are documented in the schema. The description adds no additional meaning beyond implying 'path' targets a script file and 'source' is complete replacement code, which aligns with schema descriptions. 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 clearly states the specific action ('Write/update'), the resource ('source code of a script file'), and the outcome ('saved and reloaded in the editor'). It distinguishes from siblings like forge_get_script (read-only) and forge_evaluate (execution-focused).
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 for modifying script files, but does not explicitly state when to use this vs. alternatives like forge_set_property (for property changes) or forge_evaluate (for immediate execution). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, if it requires specific conditions (e.g., project running), potential errors, or return format. More behavioral context is needed for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core purpose without any wasted words. It's perfectly front-loaded and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the resolution data returns (e.g., pixels, dictionary structure), whether values are integers, or any error conditions. For a tool with zero structured metadata, more descriptive context is needed.
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 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
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 specific action ('Get') and resource ('current viewport resolution') with precise details ('width and height'). It distinguishes itself from siblings like forge_get_properties or forge_get_output by focusing specifically on viewport resolution.
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 when viewport dimensions are needed, but provides no explicit guidance on when to use this versus alternatives like forge_get_properties (which might include resolution) or forge_screenshot (which captures visual output). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it captures a screenshot (implying a read-only operation) and returns a base64-encoded PNG image. However, it lacks details on potential side effects (e.g., performance impact, viewport changes), error conditions, or limitations (e.g., resolution, timing). The description adds basic context but is not comprehensive.
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-loaded with the core purpose ('Capture a screenshot...') followed by additional context on return format and usage. Every sentence adds value: the first defines the action, the second explains output and high-level use case. It is efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (capturing visual data) and lack of annotations or output schema, the description is minimally adequate. It covers what the tool does and the return format, but does not address potential behavioral nuances (e.g., what 'current viewport' entails, failure modes). For a tool with no structured output documentation, more detail on the returned image or usage constraints would improve completeness.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, maintaining focus on the tool's function. Baseline is 4 for zero parameters, as it avoids unnecessary information.
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's purpose: 'Capture a screenshot of the current Godot viewport.' It specifies the verb ('capture') and resource ('screenshot'), but does not explicitly differentiate it from sibling tools like 'forge_get_scene_tree' or 'forge_get_properties' that also retrieve visual/state information. The purpose is specific but lacks sibling comparison.
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 implied usage guidance with 'Use this to "see" the game or editor state,' suggesting it's for visual inspection. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'forge_get_scene_tree' for structural data or 'forge_get_properties' for property values), nor does it mention any prerequisites or exclusions. The guidance is contextual but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a read operation ('Get'), which implies it is non-destructive, but does not disclose behavioral traits such as performance considerations, error handling if no scene is open, or the format of the returned tree. The description adds basic context but lacks depth on operational details.
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, well-structured sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the main action and resource, making it easy to understand at a glance. Every part of the sentence earns its place by specifying key details.
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 no parameters, no annotations, and no output schema, the description is moderately complete. It explains what the tool does but lacks information on return values, error conditions, or dependencies like requiring an open scene. For a read-only tool with zero parameters, it is adequate but has clear gaps in behavioral context.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention any parameters, which is appropriate. It adds value by clarifying the scope of retrieval (nodes, types, hierarchy), but since there are no parameters, the baseline is 4, as it compensates adequately for the lack of parameter info.
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 specific action ('Get'), the resource ('full scene tree of the currently open scene in Godot'), and the scope ('including all nodes, their types, and hierarchy'). It distinguishes itself from siblings like forge_get_properties or forge_get_script by focusing on the scene hierarchy rather than properties, scripts, or other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'currently open scene,' suggesting it should be used when a scene is loaded and active. However, it does not explicitly state when to use this tool versus alternatives like forge_list_files for file-level information or forge_get_properties for node properties, nor does it mention prerequisites like needing an open scene first.
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?
With no annotations provided, the description carries the full burden. It discloses the tool's behavior as a status check, implying it's non-destructive and read-only, but does not add details like error handling, latency, or what specific status information is returned. It meets the baseline for a simple tool but lacks rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple tool, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It covers the basic purpose but does not explain what the status check entails or what output to expect, leaving gaps in completeness for a tool that might return connectivity details.
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 100% schema coverage, so no parameter documentation is needed. The description does not add parameter semantics, which is appropriate, earning a baseline score of 4 for tools with no parameters, as there is nothing to compensate for.
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 specific action ('Check') and resource ('connection status to the Forge Engine editor'), distinguishing it from siblings that perform operations like adding nodes, executing scripts, or managing scenes. It precisely defines the tool's purpose without ambiguity.
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 implies usage context—verifying connectivity to the editor—but does not explicitly state when to use it versus alternatives or any prerequisites. It provides clear intent but lacks explicit guidance on scenarios or exclusions, such as whether it should be used before other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action is equivalent to pressing the stop button, which suggests it halts execution but does not disclose behavioral details like whether it requires specific permissions, if it's reversible, or potential side effects (e.g., unsaved changes). This leaves gaps in transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Stop the running Godot project') and adds clarifying context ('Equivalent to pressing the stop button') without any wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation to stop a project), lack of annotations, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on outcomes (e.g., what happens after stopping, error conditions) or prerequisites, leaving room for improvement in completeness.
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, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics, but this is appropriate. A baseline of 4 is given since no parameters exist, and the description does not mislead about inputs.
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 specific action ('stop') and resource ('running Godot project'), distinguishing it from siblings like 'forge_run_project' (which starts the project) and 'forge_status' (which checks status). The analogy to pressing the stop button reinforces the purpose effectively.
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 implies usage context by specifying 'running Godot project'—this tool should be used when a project is actively running. However, it does not explicitly state when NOT to use it (e.g., if no project is running) or name alternatives like 'forge_status' to check if stopping is applicable, which prevents a perfect score.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool initiates gameplay, implying a state change (from stopped to running), but does not detail effects like whether it halts other processes, requires specific project states, or has side effects. It adds some context (the F5 analogy) but lacks depth on behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that front-load the core action ('Run the Godot project') and add clarifying analogy. Every word earns its place with no waste, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is largely complete for its purpose. It explains what the tool does and provides a relatable analogy. However, it could be more complete by mentioning potential outcomes or errors, but the lack of complexity makes this less critical.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention parameters, which is appropriate. A baseline of 4 is applied since it avoids redundancy and focuses on the tool's action, though it could slightly improve by noting the lack of parameters explicitly.
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 specific action ('Run the Godot project') and the resource ('the game'), with a helpful analogy ('Equivalent to pressing F5 in the editor') that distinguishes it from sibling tools like 'forge_stop_project' or 'forge_status'. It precisely communicates what the tool does without ambiguity.
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 implies usage context by referencing the editor's F5 key, suggesting it's for starting gameplay during development. However, it does not explicitly state when to use this tool versus alternatives like 'forge_stop_project' or 'forge_execute_gdscript', nor does it mention prerequisites (e.g., requiring an open project). This provides clear context but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![forge-mcp-server MCP server](https://glama.ai/mcp/servers/mxn2020/forge-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/mxn2020/forge-mcp-server)

Score Badge

Copy to your README.md:

[![forge-mcp-server MCP server](https://glama.ai/mcp/servers/mxn2020/forge-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/mxn2020/forge-mcp-server)

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/mxn2020/forge-mcp-server'

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