set_asset_compression

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

Goes well beyond the annotations (readOnly=false, destructive=true, idempotent=true) by disclosing that the change is persisted to disk, exactly which asset class is mutated, and how failure surfaces (success:false for non-textures). It also enumerates the full response shape, so the agent knows what evidence of success or error it will receive.

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 purpose, then scope constraint, then return payload, so the ordering is sensible. The inline return-shape enumeration is long but justifiable given there is no output schema; without it the tool would be substantially less usable.

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 destructive mutation with no output schema, the description supplies the missing pieces: persistence behavior, supported asset class, failure semantics, and the full return structure. Nothing an agent needs to call this correctly or interpret the result is absent.

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 100% and the compression_type parameter already documents the High/Medium/Low values, their TCQ_* mapping, and the hard error on other values. The description reinforces the engine-level meaning of the setting but adds no new parameter-level syntax or format detail, so the baseline of 3 applies.

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 precise verb+resource (set the TextureCompressionQuality on a texture asset) and adds engine-level scope ('UTexture::CompressionQuality'), which cleanly separates it from the sibling get_asset_compression and from broader tools like set_texture_settings. An agent can pick it out without opening the schema.

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 a clear precondition and exclusion: only UTexture targets are supported, no engine-level compression concept exists for meshes/materials, and non-texture assets fail with success:false. It does not explicitly name a sibling alternative (e.g. set_texture_settings) for adjacent use cases, so routing is implied rather than spelled out.

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