Asset import status

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further by disclosing the four comparison categories, the resource types inspected, and the specific validation rules emulated (material-less sub-meshes, unknown materials, control-character corruption, mesh-less physics shapes). It does not mention result size limits or pagination, which is the remaining gap.

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?

Two sentences, front-loaded with the comparison and its four result categories before moving to validation behaviour. The second sentence is dense but each clause adds a distinct check; nothing is redundant with the title or schema.

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 must convey what comes back, and it does: the four package states plus the resource inventory per package and the validation findings. For a read-only two-parameter diagnostic tool this is largely sufficient, though truncation/limits on large modules are unstated.

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% for both parameters, so the schema already carries the semantics (module id, details listing resources). The description's clause about 'the meshes/materials/textures/physics shapes each package contains' loosely corresponds to the details flag but adds no syntax or default behaviour beyond the schema. Baseline 3 is appropriate.

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?

Names a specific verb (compares) and two concrete resources (module AssetSources vs editor's imported Assets/*.tpac packages), then enumerates the exact states it classifies: imported, pending, stale, orphaned. This clearly separates it from siblings like asset_import (performs the import), asset_search (finds assets) and validate_module (validates module structure).

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 mention that it 'checks the packages like the editor will when loading them' implies a pre-flight/diagnostic use case, so an agent can infer it should run this before import or when investigating load failures. However, no explicit when-to-use, when-not, or named alternative (e.g. asset_import or validate_module) is given, so routing is left to inference.

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