gameforge_audit_asset_consistency

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

No annotations are provided, so the description carries the full burden. It never says whether the gate is read-only or writes/clips output, whether it raises on failure versus returning a report, how long/expensive binary decoding is, or how the 10 points are reported. Enumerating the checks adds real context, but the operation's side effects and result contract are undisclosed.

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?

One front-loaded sentence that leads with the verb and the gate name before the check list. Every clause maps to a concrete verification, though the unbroken chain of jargon makes it a wall of text rather than scannable structure.

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 annotations, no output schema, and two undocumented parameters, the description leaves the agent without the result contract (pass/fail payload? per-check findings?) or the meaning of the scope selectors. For a multi-stage QA gate this is materially incomplete.

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 coverage is only 33%: clip_name is documented as defaulting to the first animation or 'walk', but project_id and character_id have no schema descriptions at all. The tool description mentions none of the three parameters, so the two most important identifiers are entirely unexplained in both places.

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?

States a specific verb and resource: 'Run the 10-Point Pixel-Verified Technical Art QA Gate' that 'inspects' and 'binary-decodes' atlases. It is clearly an audit/verification tool, distinguishable from generation and export siblings (e.g. gameforge_compile_sprite_atlas, gameforge_export_unity_package). The dense jargon ('Paper-Doll Z-matrix', 'Style Bible denoise bounds') adds flavor but the core action is legible.

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 on when to run it, what must exist first, or which sibling to use instead. An agent cannot tell whether this should run before export, after atlas compilation, or per-clip, nor what to do on failure. The only implied usage is 'run it on a project', which is not a routing rule.

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