Skip to main content
Glama
Sign In
laaielichter

Godotwright

by laaielichter
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

AAA review

godot_review

Statically reviews Godot projects or unsaved GDScript for API correctness, performance, and code quality, returning category scores and file-specific findings without running the engine.

Instructions

Static AAA review of the project, no Godot needed: API correctness (Godot 3 code, unknown classes, functions, members, signals, wrong argument counts, missing input actions), performance, code quality and structure. Returns a 0-100 score per category, then one line per finding: res://file.gd:12: error [rule] message; detail full adds the fix under each finding. Pass files to list only findings in files you changed. Pass code and file to review GDScript before writing it to disk. Pass only_new: true while you are fixing: new findings in full, the ones you already saw as one short line each, and how many are fixed. It never changes your code; it keeps the last review in .godot/godotwright/ for only_new and counts rule hits in the local learning file. For errors only the engine finds, run godot_check after it; godot_checklist lists every rule.

Input Schema

NameRequiredDescriptionDefault
codeNounsaved GDScript to review in place of the file on disk
fileNores:// path the code belongs to (required with code)
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.
filesNoonly show findings in these res:// files
detailNobrief: short output with capped lists; full: everything (default for this premium profile: full).
only_newNoshow only what changed since the last review of this project (saves tokens in a fix loop)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.1
    • changedInput schema / properties / detail / description
      Previous value: -"Output detail (default for this premium profile: full)."New value: +"brief: short output with capped lists; full: everything (default for this premium profile: full)."
    • 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?

Annotations only say readOnlyHint=false/destructiveHint=false; the description goes further, disclosing that it never mutates code but does persist side effects — the last review in .godot/godotwright/ and rule-hit counts in a local learning file. That is exactly the kind of state-change detail annotations 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?

Purpose and output shape are front-loaded and nearly every clause carries information (side effects, output format, sibling routing). It is dense to the point of being run-on and slightly harder to scan than it needs to be.

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 takes on the return-format burden and delivers: a 0-100 score per category plus the exact `res://file.gd:12: error [rule] message` line format. For a six-parameter, stateful review tool, an agent has everything needed to call 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?

Schema coverage is 100%, so baseline is 3, but the description adds usage-level meaning the schema lacks: `files` targets changed files, `code`+`file` reviews unsaved GDScript, `only_new` collapses already-seen findings and reports a fixed count, and `detail: full` inlines fixes. Only `path` is left entirely 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 and resource — 'Static AAA review of the project, no Godot needed' — and enumerates exactly what it checks (API correctness, performance, quality, structure). It explicitly distinguishes itself from siblings: godot_check handles 'errors only the engine finds' and godot_checklist 'lists every rule.'

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?

Gives concrete when-to-use modes: pass `files` for changed files, `code` + `file` to review GDScript before writing to disk, `only_new: true` during a fix loop. It also names the complementary alternative (godot_check) and when to escalate to it.

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