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

With no annotations, the description carries the full burden and does so well: it discloses live subphase publishing on Tasks/MC overlay, cooperative cancel, the shared next_action/sleep_ms poll loop, the rule against silently inheriting a cadence column, and protocol-version-gated in-band prompting vs legacy INVALID_REQUEST behavior. It omits the mutation/permission profile (whether the build overwrites existing territories) and any expected_revision concurrency semantics, keeping it out of the top band.

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 tier and "When" clause are front-loaded and nearly every sentence carries actionable content (scope semantics, progress model, cadence rule, client compatibility). It is nonetheless densely telegraphic, with fragments like "That session is the TS" and opaque scenario codes (ACB-001..004, MC-011) that cost readability without adding selection value.

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?

An output schema exists, so return values are already covered, and the description supplies everything else an agent needs for this complex 17-param builder: prerequisites, scope selection branching, progress/cancel behavior, cadence handling, and host-compatibility fallbacks. Nothing material to invoking it correctly appears to be 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?

Schema description coverage is only 6% across 17 params, so the description must compensate, and it explains roughly a dozen of them in prose: ts/ts_handle omission when a session id is set, part_scope default of bbox_intersect, part_filter/part_ids placement as top-level scope fields, grouping_field, part_layer, tal_label, visit_frequency_field and ignore_visit_frequency. It leaves the single required parameter (point_layer) and repair_policy/conflict_policy/expected_revision/guidance_handle unexplained, so the coverage gap is narrowed but not closed.

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 tier tag "Attribute Grouping Builder" plus "territories should mirror an account attribute column from CRM exports" states a specific verb (build) and resource (territories grouped by an account attribute), which cleanly separates it from auto_build, seed_build and direct_build siblings. It never states the purpose in one plain sentence, so it is clear but leans on the reader to assemble the meaning from fragments.

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?

It gives an explicit "When" condition (territories should mirror a CRM attribute column), prerequisites (ingest_accounts with grouping column, part_layer chosen, viewer connected), and a concrete routing rule for the common ambiguity: naming a state/region requires part_scope=explicit with part_filter, not bbox_intersect. It also points to the follow-up (analyze + load_analysis_panel) and names auto_build as the shared poll-loop peer.

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