Check what the exported game will hold

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

Annotations already cover read-only, idempotent and non-destructive, yet the description adds substantive domain behavior: no export is performed, Godot silently drops excluded files even when preloaded (so the build fails), plain data files must be named in include_filter while JSON and imported CSV are safe, and run-time built paths under excluded folders are flagged. It also discloses the export-template check. This is information an agent could not get from 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.

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

The core action and the critical caveat ('without exporting') are front-loaded, then details follow. The long middle enumeration of file types and failure modes is dense but each item maps to a concrete warning the agent would otherwise miss. There is mild repetition in restating 'Read-only'.

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?

With no output schema, the description carries the burden of telling the agent what comes back, and it does so by enumerating the finding categories (excluded-but-loaded files, unexported plain data files, run-time paths, missing export templates). What it omits is the result shape (list of issues? per-preset summary? severity?) and whether defaults include all presets when 'preset' is omitted.

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%, so both parameters are already documented; the description only restates that 'preset' limits the run to one preset by name or number. The 'path' parameter (project folder, walk-up to project.godot) is not mentioned in the description at all. Baseline 3 applies when the schema carries the parameter detail.

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 opens with a specific verb and resource: 'Compare the export presets (export_presets.cfg) with what the scripts and scenes load, without exporting.' That is far more precise than a tautology and an agent can immediately tell it is an export-readiness audit. It never names the adjacent siblings (godot_check, godot_doctor, godot_review), so the differentiation from generic check tools is inferred rather than stated.

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?

The final sentence gives explicit timing guidance: 'Run it before an export and after changing what the game loads.' That is a clear usage context with a concrete trigger. There are no stated exclusions or named alternatives for when a different tool would be better.

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