add_slice

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

Annotations already declare this is a non-read-only, non-destructive, closed-world mutation, so the safety profile is covered. The description adds real behavioral value by explaining that dict/list data is JSON-encoded and round-trips through export_slice_metadata, but it says nothing about failure modes (e.g., overlapping slices, missing filename) or whether the sprite must already exist.

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?

The one-line summary is front-loaded and the args list is tight, with conditional guidance folded into the relevant entries rather than repeated. Only the omission of filename and x/y semantics keeps it from being fully front-loaded.

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 14-parameter mutation tool with zero schema descriptions and no output schema, the description covers the tricky optional params but leaves gaps: filename is undocumented, x/y origin is unspecified, and there is no indication of what happens if a slice already exists at that location.

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 0% across 14 parameters, so the description carries the load and does so for the non-obvious ones: center_* is a 9-patch rect relative to the slice's top-left and all four must be supplied, pivot_* is a point relative to the slice, and data has special encoding rules. It omits filename and the coordinate origin for x/y, keeping it short of a 5.

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 ('Create a slice (named region)') plus the positional parameters, so the agent knows it adds a slice rather than modifying or removing one. It does not explicitly name the sibling alternatives (set_slice, remove_slice), but the create semantics are unambiguous.

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?

There is no when-to-use guidance, no prerequisites, and no reference to alternatives such as set_slice for editing an existing slice or list_slices for inspection. The args section explains what fields mean, not when this tool is the right choice.

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