Skip to main content
Glama
Sign In
laaielichter

Godotwright

by laaielichter
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Run the unit tests

godot_test
Idempotent

Execute project tests using GUT or GdUnit4 in Godot 4.7 headless mode. Identify failing tests and script errors after code changes to ensure stability.

Instructions

Run the project's GUT or GdUnit4 tests in Godot 4.7 headless and return only the totals and the failing tests, each with res://file:line and the failure message, plus script errors from the run. Use it after a change to see whether the tests still pass. Needs Godot on this machine and GUT (res://addons/gut) or GdUnit4 (res://addons/gdUnit4) in the project. framework picks one when both are installed; dirs chooses the test folders or scripts (default: the framework's config, else res://test and res://tests); filter runs only matching GUT tests. An error result when a test fails, or when Godot or a framework is missing. Test files are not changed; reports go to a temporary folder or .godot/godotwright/. To try input without writing tests use godot_play; for load errors only use godot_check.

Input Schema

NameRequiredDescriptionDefault
dirsNotest folders or scripts as res:// paths (default: the framework's config, else res://test and res://tests)
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.
filterNoGUT only: run only tests whose name contains this text
frameworkNowhich framework (default: whichever is installed)
timeout_secondsNotimeout of the run (default 600)

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: it discloses prerequisites (Godot installed, addons/gut or addons/gdUnit4 present), the error-result contract (error when a test fails or a dependency is missing), and the on-disk side effects (test files untouched, reports written to a temp folder or .godot/godotwright/). That last point usefully explains why readOnlyHint is false despite the tool being non-destructive and idempotent.

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 purpose and return shape, then prerequisites, then parameters, then alternatives — a sensible ordering with no filler sentences. It is a dense single paragraph with heavy backtick usage, which makes it slightly harder to skim than a short bulleted split would 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?

There is no output schema, so the description carries the return-value burden, and it does: totals, failing tests with locations and messages, plus script errors from the run. Combined with prerequisites, failure semantics, and side effects, an agent has everything needed to decide and invoke 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 already 100%, so the baseline is 3; the description adds real meaning on top by explaining resolution order for `framework` (picked explicitly when both are installed), the defaulting cascade for `dirs` (framework config, else res://test and res://tests), and that `filter` is GUT-only. It does not touch `path` or `timeout_seconds`, but the schema handles those adequately.

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 (run the project's GUT/GdUnit4 tests in Godot headless) and pins down return content (totals plus failing tests with res://file:line and messages). It also explicitly distinguishes itself from godot_play and godot_check by naming when each of those is the right tool instead.

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?

"Use it after a change to see whether the tests still pass" gives the trigger, and the final sentence names two alternatives with their selecting conditions (godot_play for trying input without writing tests, godot_check for load errors only). "Use when both frameworks are installed" for `framework` resolves the one common ambiguity.

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