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

Beyond annotations it discloses source-specific side effects: HDRIs become the world environment, models join the scene, texture sets create a wired PBR material, and Sketchfab requires an org token. It doesn't spell out that replacing the world environment is the destructive aspect flagged by destructiveHint, nor what a job handle implies for completion.

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?

Front-loads what it does and returns, then proceeds source by source. Dense but every clause carries operative information; only the nested parentheticals make it slightly hard to scan.

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?

Covers the high-risk decisions for a 10-parameter mutating import: source, slug format, sizing, auth, and revision targeting. An output schema exists so return values needn't be described, and the 'job handle' mention is enough; minor gaps are the enum-only parameters.

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 30%, and the description compensates for slug (per-source semantics), targetSize (with concrete meter anchors), applyToObjects, and baseRevisionId indirectly, but resolution, materialName, and type go unexplained in both places. Strong on the hardest parameters, silent on the rest.

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 ('Import a library asset into a project as a new revision') and adds an outcome ('Returns a job handle'). It does not distinguish itself from the sibling asset_import, which is the one ambiguity an agent would still need to resolve elsewhere.

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?

Gives an explicit precondition ('Use only after the user has chosen the asset/action or delegated source selection') and names the discovery alternatives (search, asset_preview) that present options without importing. It lacks an explicit when-not relative to asset_import, but the selection ritual is clear.

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