Skip to main content
Glama
Sign In
laaielichter

Godotwright

by laaielichter
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Rename everywhere

godot_rename
Destructive

Rename functions, signals, variables, classes, autoloads, groups, input actions, nodes, or res:// files everywhere they are referenced; preview the plan, then apply changes.

Instructions

Rename a function, signal, variable, class_name, autoload, input action, group or node name everywhere it is used (GDScript, scene connections, node paths, groups, project settings), or move a res:// file together with its .uid and .import files and every reference to it. from and to are both names or both res:// paths. Without write it changes nothing and returns the exact lines it would change and what it could not change; with write: true it applies them and reports the review errors before and after (an error result when there are more after). Refuses, with an error, when the new name is already taken. Call godot_usages first to see what it will touch. For a setting value, an input event or a node property, use godot_project_edit or godot_scene_edit instead.

Input Schema

NameRequiredDescriptionDefault
toYesthe new name, or the new res:// path
fromYesthe current name, or a res:// path
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.
writeNoapply the rename (default false: show the plan only)

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: default is a no-op dry run returning the exact lines that would change and what could not change; write:true applies and reports review errors before and after, erroring when post-count exceeds pre-count; it refuses when the new name is taken. This is consistent with destructiveHint=true and readOnlyHint=false (the danger only materializes under write:true).

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?

Dense but front-loaded: the rename surface comes first, then the file-move mode, then dry-run/write behavior, then the safety refusal and sibling routing. Individual sentences are long and clause-heavy, but nothing is redundant.

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?

With no output schema, the description carries the return-value burden and does so fully: exact changed lines, unchangeable locations, and before/after review errors. For a destructive, non-idempotent rewrite tool, an agent has everything needed to call it safely.

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 a real constraint the schema does not express: 'from and to are both names or both res:// paths,' and it clarifies write's semantics (default false = plan only). Path's project-root resolution is left to 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?

States a specific verb (rename) plus the full resource surface (functions, signals, variables, class_name, autoloads, input actions, groups, node names) and a second mode (moving a res:// file with .uid/.import and references). This is enough for an agent to distinguish it from godot_project_edit and godot_scene_edit without opening any 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 routes the agent: 'Call godot_usages first to see what it will touch' and 'For a setting value, an input event or a node property, use godot_project_edit or godot_scene_edit instead.' Both the when and the when-not-with-alternative are named.

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