Stop Project

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

Annotations declare readOnlyHint=false and destructiveHint=false but idempotentHint=false. The description doesn't contradict annotations. However, it adds no behavioral context beyond 'stops the running project' — it doesn't clarify whether stopping is reversible via run_project, whether debug output is preserved, or what happens with pending editor transactions. With sparse annotations, the description carries the burden but adds little.

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 extremely brief — a single partial sentence. While conciseness is generally good, the truncation ('pro…') suggests incompleteness rather than intentional minimalism. A complete description could add meaningful context like effect on debug sessions or project state.

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?

The tool is a simple state-changing operation with 0 parameters and an output schema. Given this low complexity, the description is mostly adequate. However, it's truncated mid-word, and with no annotation coverage for what 'stopping' destroys or affects (e.g., debug session state), a slightly more complete description would help the agent understand side effects.

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?

The tool has 0 parameters with schema description coverage at 100%, so there are no parameters requiring documentation. Per the rubric, 0 params earns a baseline score of 4, and with no params to describe, this 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 "Stop the currently running Godot pro…" clearly indicates a verb (Stop) and resource (the running Godot project). It distinguishes from the sibling run_project. However, the description appears truncated (ends mid-word with 'pro…'), losing potentially important context about scope or effects.

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?

No explicit guidance on when to use this tool versus alternatives. While the purpose is implied by the name and truncated description, there's no stated context like 'use after run_project' or prerequisites (e.g., only works if a project is running), nor exclusions about when not to use it.

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