runtime

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

Annotations are all false, so the description carries the full burden of behavioral disclosure. It merely lists actions in imperative form and does not disclose that run_project spawns a process, stop_project terminates it, or record_save writes a JSON file. The schema parameter hints capture some of this later on, but the tool-level description adds very little behavioral transparency.

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

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

The description is a single front-loaded sentence and is easy to skim. It is concise without padding, but the brevity comes at the cost of omitting the recording-related actions and overall dispatch nature of the tool, so it loses one point.

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

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

This is a 12-parameter dispatcher with 11 possible actions, no output schema, and no description of the return behavior or the overall orchestration pattern. The description excludes six of the action enum values entirely and does not explain how wait_for_bridge, timeout, and autostart interact. A tool can be used in a variety of configurations here, and the description is too incomplete to fully support an agent.

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

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

Schema description coverage is 100% and each parameter is well explained with enum values, defaults, and practical notes such as timeout edge cases and the GUT -gquit compatibility issue. The description text contributes no additional parameter explanation beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description lists specific verbs tied to a concrete resource: launching the editor, running/stopping the project, fetching debug output, running tests, and getting the Godot version. This makes the main intent clear. It does not distinguish itself from siblings or mention the recording actions, which keeps it from a 5.

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

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

There is no guidance about when to use this tool versus closely related siblings such as project, game, script, or runtime_assert. The description only enumerates capabilities and gives no exclusion criteria or conditions that would help an agent route between alternatives.

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