Skip to main content
Glama

Change project settings, input map or autoloads

godot_project_edit
Destructive

Safely update project.godot without opening Godot: set or unset settings, add or remove input actions and events, and manage autoloads with validation and optional diff preview before writing.

Instructions

Change project.godot safely, without the editor: set or unset a setting (name and type checked against the Godot 4.7 reference), add events to an input action or remove it, add or remove an autoload (the file must exist and be a Node script or a scene; the name must not clash with a class). Only the lines of that entry change. Events: Key:Space, Key:Ctrl+S, Mouse:Left, JoyButton:A, JoyAxis:left_y-. op picks the change and which fields it needs: set (key, value), unset (key), input_add (action, events, deadzone), input_remove (action), autoload_add (name, file, global), autoload_remove (name). Without write it changes nothing and returns the diff and warnings; with write: true it writes and reports the review errors before and after (an error result when there are more after). A missing field or a change it refuses (bad event, unknown action, name clash) returns an error and writes nothing. Use it instead of editing project.godot by hand: the input map format is easy to break. For .tscn files use godot_scene_edit; to rename an action or autoload everywhere, use godot_rename.

Input Schema

NameRequiredDescriptionDefault
opYeswhat to change
keyNoset/unset: the setting path, e.g. display/window/size/viewport_width
fileNoautoload_add: res:// path of the script or scene
nameNoautoload_add/autoload_remove: the autoload name, e.g. Game
pathNoThe project folder, or any file or folder inside it (Godotwright walks up to project.godot). Relative paths start at the server's folder. Default: the current project.
valueNoset: the value, e.g. 1920, true, 1.5, a text, res://main.tscn or Vector2i(1920, 1080)
writeNowrite the change (default false: show the diff only)
actionNoinput_add/input_remove: the action name, e.g. jump
eventsNoinput_add: events such as Key:Space, Mouse:Left, JoyButton:0, JoyAxis:1-
globalNoautoload_add: make a global variable (default true)
deadzoneNoinput_add: deadzone of a new action (default 0.2)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.1
    • changedInput schema / properties / path / description
      Previous value: -"Project directory or a path inside it (default: the current project)."New value: +"The project folder, or any file or folder inside it (Godotwright walks up to project.godot). Relative paths start at the server's folder. Default: the current project."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false): it discloses the dry-run default, that only the lines of that entry change, that refusals and missing fields return an error and write nothing, and that with write it reports review errors before and after with an error result if errors increase. This is exactly the mutation-safety context annotations alone cannot convey.

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?

Front-loaded with the safety model and the tool's scope before the dense op/field enumeration. Every sentence carries information, though the middle section is a long run-on that would read better as a list.

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

Completeness5/5

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

For an 11-parameter destructive mutation with no output schema, the description covers what is returned in both modes (diff, warnings, before/after review errors), what happens on failure, and the validation rules for every op. Nothing an agent needs to call it safely is missing.

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 100% so the baseline is 3, but the description adds the op-to-field dependency mapping (set/key+value, input_add/action+events+deadzone, autoload_add/name+file+global) that the schema only implies, plus event string syntax with concrete examples. It does not restate path/write defaults, which the schema already covers.

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?

States a specific verb and resource (edit project.godot: settings, input map, autoloads) and immediately names the boundaries against siblings godot_scene_edit and godot_rename. An agent can distinguish this from every other godot_* tool without opening a schema.

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

Usage Guidelines5/5

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

Explicitly says to use it instead of hand-editing project.godot because the input map format is easy to break, and routes .tscn work to godot_scene_edit and renaming to godot_rename. The dry-run-first workflow ('without write it changes nothing and returns the diff') is also spelled out as guidance.

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