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

Beyond the readOnlyHint/idempotentHint annotations, the description adds meaningful behavioral detail: tag validation against live segment tags, a returned exact-token filter plus server-computed lead count, exclusions for do-not-contact/archived/test leads, and the explicit statement that it 'changes no data and CANNOT enroll anyone.' This fully aligns with the annotations and adds value beyond them.

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 description is well-structured: core action first, then behavioral/return details, then usage guidance and routing. It is slightly longer than strictly necessary — the routing line partially restates the 'Use when' sentence — but every section earns its place and the ordering aids quick scanning.

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?

With no output schema, the description correctly explains what the tool returns: 'the exact-token filter plus a server-computed lead count,' including exclusion logic. It does not specify failure behavior for invalid tags, but validation is clearly implied and the operation is explicitly read-only, so the invocation context is sufficiently complete.

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 100%, so the schema already documents all three parameters, their requiredness, and the action enum. The description reinforces the exactness of segment_tag and the three action states, but it mostly repeats schema information rather than adding new parameter-level semantics.

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 opens with a precise verb + resource combination: 'Organize, select, or clear a lead segment on the Leads tab by its exact source tag,' naming the resource and all three possible actions. It also explicitly differentiates from enroll_by_segment, making the tool's scope unmistakable.

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 states exactly when to use the tool: 'Use when the operator wants to focus the Leads tab on one segment or event — group it, select all its leads for enrollment, or clear that selection.' It also gives an explicit alternative: 'To enroll the segment, call enroll_by_segment — do not ask the operator to click Enroll or paste emails.' This is strong routing guidance with no ambiguity.

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