godot_check_material_compatibility

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

Annotations already declare readOnlyHint=true, and the description adds one behavioral nuance beyond that: an empty object_name widens the check to all meshes. It does not explain what a successful/failed check looks like or whether non-empty names are the only scoped case, but no contradiction exists.

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 text is short and free of filler, which is good, but it is under-specified rather than elegantly concise: the conditional clause is used in place of a complete definition. It could state the same scope in one full sentence without adding length.

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?

For a one-parameter, read-only check tool, the description covers the important empty-vs-scoped behavior and would let an agent invoke it correctly. However, with no output schema, it omits what the check returns and what compatibility criteria are being evaluated, leaving some contextual ambiguity.

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?

With 0% schema description coverage, the description compensates by explicitly defining the default/empty behavior of the only parameter: empty object_name checks all meshes. It does not spell out the non-empty case, but the parameter name plus default make that obvious enough for a single optional string.

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 identifies an action ('checks') and a scope ('all meshes'), and the tool name/annotation title supply 'material compatibility,' so the overall purpose is inferable. But the sentence is elliptical and never states what is actually verified, making it less than a fully clear purpose statement.

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 only guidance is the empty-object_name behavior; there is no statement about when to prefer this tool over siblings such as validate_mesh or godot_validate_scene, nor any exclusion criteria. The tool context must be inferred entirely from the name.

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