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

Goes well beyond the annotations by disclosing side effects (points, part-layer overlays and routes survive; the map falls back to a remaining alignment or points only), the synchronous nature of the call, the already_absent=true no-op result, and the AMBIGUOUS_TAL error path. The already_absent behavior is arguably idempotent while annotations claim idempotentHint=false, but this reads as a partial-no-op nuance rather than a contradiction.

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 the destructive action and scope in the first sentence, then layers constraints and fallbacks efficiently. Dense but every sentence carries distinct information; borderline on length for a single-call tool.

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?

Output schema already covers return values, yet the description still surfaces the notable result states (already_absent, AMBIGUOUS_TAL) and the post-delete map behavior. Nothing an agent needs to invoke this destructively and safely is missing.

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?

With 0% schema description coverage the description must carry the parameter burden, and it does explain that tal_id accepts an id or an exact unique label and that map_session_id/ts_handle are alternative context handles. It never clarifies the relationship or precedence between ts_handle and map_session_id, leaving that pair ambiguous.

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 (deletes) and a precisely scoped resource (one whole territory alignment, explicitly glossed as 'the territory layer', 'all territories'), and distinguishes it from the nearest sibling by naming delete_territory for the single-territory case.

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 the required inputs (tal_id or exact unique label, plus map_session_id or ts_handle) and explicitly routes the neighbouring case to delete_territory, so an agent can choose between the two without opening either schema.

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