Validate a module

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the meaningful behavioral detail that it checks "like the game would" and enumerates breadth, implying a heavyweight comprehensive pass, but it says nothing about cost, latency, or what the result contains beyond the annotation profile.

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?

A single dense sentence that front-loads the verb and the "like the game would" framing before the enumerated checks. It is long and list-heavy, but every clause names a distinct check, so little is wasted.

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 explaining what comes back, and it never states the result shape (findings list, error severity, pass/fail). The input side is fully covered, but an agent knows what is checked yet not what to expect in return.

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 all four parameters (module, xsd, l10n, refs) are already documented with defaults. The description's check list loosely maps to the three boolean switches (XSD/XSLT, localization, references), adding marginal clarity, but supplies no syntax or semantics beyond the 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?

States a specific verb ("Checks") and resource ("a module") and then enumerates the exact scope: SubModule.xml ids/versions/DLLs, XML well-formedness and XSD, XSLT compilation, duplicate ids, unresolved references, unregistered files, and localization. This clearly separates it from narrower siblings such as l10n_scan or find_references, which cover only subsets.

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?

Usage is implied (run a full pre-flight validation of a module) but never stated explicitly, and there is no guidance on when to prefer this over the narrower sibling tools (l10n_scan, find_references, describe_schema) or when not to run it. An agent can infer the context but is given no routing rules.

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