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

Annotations already indicate a non-read-only, non-destructive, idempotent operation, so the description doesn't need to restate that. It adds deactivation behavior via is_active=false, but it does not disclose whether updates are partial (only provided fields are changed) or full replacement, nor any side effects or permissions. This leaves meaningful ambiguity.

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 sentence that front-loads the action and resource, followed by a scannable list of update types. No filler, repetition, or unnecessary detail.

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 tool with 22 parameters, no output schema, and very low schema description coverage, the description is far too thin. It omits crucial operational details like required zone_id, partial-update semantics, and the meaning of most fields, so an agent would struggle to invoke the tool correctly for anything beyond the listed examples.

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 9% across 22 parameters, placing the burden on the description to clarify parameters. It maps some fields (lat/lng to 'move the center', radius_m to 'resize the radius', is_active to 'deactivate'), but most parameters like notify_email, required_ppe, auto_clock_in, and task_list_id are unexplained, and terms such as 'zone-lock' and 'routing target' don't map cleanly to any schema property.

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 states a specific verb and resource ('Update a geofenced zone') and enumerates several concrete update actions (move center, resize radius, toggle zone-lock, deactivate). It does not explicitly contrast with sibling tascan_create_zone, but the update framing clearly targets an existing zone.

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?

No explicit when-to-use or alternative guidance is provided. The description only says what the tool does, not when to choose it over create_zone or what prerequisites must be satisfied (e.g., zone must already exist). The verb 'update' provides only an implicit usage signal.

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