modify_sprite_asset

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context by stating this is 'one undoable edit,' which tells the agent the operation can be reverted atomically. It also discloses that the tool supports two modes (data modification vs. frame map replacement), going slightly beyond what the schema or annotations imply.

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 front-loads the primary action and lists relevant targets without repetition or filler. The alternative mode and undoability are included in a compact way. Every phrase earns its place.

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 mutating tool with a nested props object and no output schema, the description gives the purpose and the list of change targets but omits details on how to structure the frame map replacement or whether certain fields are mutually exclusive. An agent can make a basic call using `id` and `props` but may struggle with the more complex frame-map replacement path without additional examples or clearer field semantics.

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 only 50%: only `id` is described in the schema, while the entire `props` object is undocumented. The tool description partially compensates by mapping high-level concepts (atlas, frame order, pixels per unit, render mode) to the likely props fields. However, it does not explain the meaning of `textureAtlasAsset`, the structure of `frames`, or relationships between fields, so the agent still has to guess from property names and nested schema definitions.

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?

The description uses a specific verb ('Modify') and resource ('sprite data') and enumerates the exact modification targets: atlas, frame order, pixels per unit, render mode. It also names the second operation mode, replacing a texture atlas frame map. This clearly distinguishes it from generic sibling tools like modify_assets or replace_asset.

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 description implies when to use the tool (when sprite data or a frame map needs changing), but it does not explicitly contrast it with alternatives such as modify_assets, replace_asset, or convert_texture_asset. No exclusions or 'use X instead' guidance is provided, so an agent must infer the boundary from the tool name and description.

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