Skip to main content
Glama

godot_run_tests

Run Godot test scenes or unit test runners in headless mode, specifying optional paths and arguments.

Instructions

Execute test scenes or unit test runners headlessly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior2/5

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

Annotations are minimal (all false hints), so the description carries the burden of disclosing side effects. 'Headlessly' provides some context, but there is no mention of what the tool actually does to the project, whether it modifies files, what success/failure looks like, or any output specifics. The description adds little beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence without unnecessary fluff, so it is concise. However, it is under-specified and does not structure information such as usage, parameters, or outputs. It is minimally concise but not appropriately informative.

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

Completeness2/5

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

For a tool with multiple parameters, an output schema, and many test-related siblings, this description is severely incomplete. It lacks any mention of how to specify a test, what formats are accepted, or what the tool returns. An agent cannot correctly invoke this tool without deep schema inspection and assumptions about behavior.

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

Parameters2/5

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

The schema descriptions for each parameter are present, but the tool description itself provides zero parameter context. With 4 parameters and 0% description coverage of them, the description does not compensate. The agent must read the schema to understand what test_path, extra_arguments, etc., mean, which is acceptable but leaves the description lacking added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb 'execute' and identifies both 'test scenes' and 'unit test runners' as targets, and specifies 'headlessly' as a mode. This makes the tool's basic purpose clear. However, it does not distinguish this tool from sibling godot_run_gut_tests, which also runs tests, so it loses a point for lack of differentiation.

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

Usage Guidelines2/5

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

No guidance is given on when to prefer this tool over alternatives like godot_run_gut_tests, nor any mention of prerequisites or when not to use it. The description simply states what it does, leaving the agent to infer usage context without any explicit direction.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mcintalmo/godot-engine-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server