find_unused_resources

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to explain what 'unreferenced' means (orphaned files? dangling pointers?), what the tool returns (paths? resource IDs?), or whether it modifies state. The 'Compatibility tool' notation is cryptic without elaboration on behavioral implications.

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 brief (five words plus a parenthetical), but given the complete lack of schema documentation and annotations, this brevity becomes under-specification rather than efficient communication. The structure is simple but insufficiently informative for the complexity of the domain.

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, no annotations, 0% parameter coverage, and a complex domain (Godot game engine), the description should explain return values, resource types scanned, and scope limitations. It provides none of this necessary context, leaving agents uncertain about what the tool returns or operates upon.

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 input schema has 0% description coverage for its two parameters (timeoutMs and autoConnect), and the description makes no attempt to explain what these control (search timeout vs connection timeout? auto-connect to what?). The description completely fails to compensate for the undocumented schema.

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 states the basic action ('Find unreferenced resources') but lacks specificity about what constitutes a 'resource' in the Godot context (assets, files, nodes?) and fails to differentiate from sibling tools like 'find_node_references' or 'find_script_references'. The parenthetical '(Compatibility tool)' hints at context but remains unexplained.

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 guidance provided on when to use this tool versus alternatives like 'find_node_references' or 'get_scene_dependencies'. The '(Compatibility tool)' label suggests specific usage constraints but offers no explanation of what they are or when this should be preferred over non-compatibility alternatives.

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