Skip to main content
Glama
Tann2019

Godot Forge

by Tann2019
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Scripts

script

Create, edit, validate, and lint Godot code files, returning compile diagnostics to catch errors before running.

Instructions

GDScript (and C#) files. Creating/writing/editing a .gd reloads it in the editor and returns compile diagnostics immediately — fix errors before running. Use templates for common controllers.

Actions:

  • create: {path, content? | template?: 'default'|'empty'|'platformer_2d'|'topdown_2d'|'fps_3d'|'state_machine'|'autoload_events', extends?, class_name?, actions?: {jump,left,right,up,down}, attach_to?: node path, scene?} new script, optionally attached.

  • read: {path, outline?} script source (and its outline).

  • write: {path, content} replace the whole script; returns diagnostics (errors + warnings).

  • edit: {path, edits: [{old, new, replace_all?}]} exact replacements; returns diagnostics.

  • lint: {path | paths} full language-server diagnostics (all errors and warnings such as unused variables, shadowing, unsafe casts) for scripts on disk.

  • validate: {path? | paths? | content?} compile check. No args = every script in the project.

  • outline: {path} extends, class_name, signals, exported vars, functions with line numbers.

  • attach: {path: node, script, scene?}

  • detach: {path: node}

  • references: {symbol} find usages across the project.

  • classes: {} project class_name classes.

  • templates: {} available templates.

  • open: {path, line?} show the script to the user in the script editor.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNores:// script path (node path for attach/detach).
editsNoExact replacements.
sceneNores:// scene to operate on; opened in the editor if needed. Defaults to the currently edited scene.
actionYesWhat to do. See the tool description for each action's parameters.
scriptNoScript path for attach.
symbolNoIdentifier to search for.
actionsNoInput action names for templates.
contentNoScript source.
extendsNoBase class for templates.
templateNoTemplate name.
attach_toNoNode path to attach the new script to.
class_nameNoGlobal class name to declare.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), it discloses genuinely useful behavior: creating/writing/editing a .gd reloads it in the editor and returns compile diagnostics immediately, write replaces the entire script, edit does exact replacements, lint reports unused variables/shadowing/unsafe casts, and open surfaces the script to the user. This is rich context the annotations do not carry.

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?

A tight two-sentence behavioral lead-in followed by a one-line-per-action list. For a 13-action tool this is dense but every line earns its place, and the most important behavioral note (diagnostics returned on edit) is front-loaded.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does so for most actions (diagnostics, outline contents, references). It is nearly complete for a 12-param multi-action tool, though it does not explicitly confirm persistence semantics of write/edit or spell out what `read` returns versus `outline`.

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

Parameters5/5

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

Schema coverage is 100% (baseline 3), but the schema is a flat union of 12 params with only a single enum, so the description's per-action parameter mapping ('create: {path, content? | template?: ...}', 'attach: {path: node, script, scene?}') is what actually tells the agent which parameters apply to which action. That is meaningful value beyond the schema.

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 opening line names the concrete resource (GDScript/C# .gd files) and the verb set is enumerated per action, so an agent can tell this apart from the generic `files` sibling and from `scene`/`node`. Each action is stated as verb+resource (create a new script, read source, edit with exact replacements, lint diagnostics, etc.).

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?

It gives real routing guidance: 'fix errors before running', 'Use templates for common controllers', and distinguishes lint ('full language-server diagnostics ... for scripts on disk') from validate ('compile check', no args = whole project). It stops short of explicitly contrasting edit vs write or read vs outline, so it falls short of the 5-level when/when-not coverage.

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

Deploy Server

Other Tools