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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description is not required to restate them, and it doesn't. Instead it adds genuine behavioral context the annotations cannot carry: the data is team-scoped, values are team-specific, and downstream write tools reject unrecognized values. It stops short of describing size or stability of the result set, but the output schema covers the return shape.

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?

Two sentences, zero filler. The payload is front-loaded in the first sentence and the operational instruction follows in the second, with an em-dash clause supplying the rationale rather than a separate sentence.

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?

The tool is a parameterless read whose annotations carry the safety profile and whose output schema carries the return structure. The description supplies the one thing neither structured field can: the prerequisite relationship to the three write tools. Nothing an agent needs in order to call it correctly 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?

There are zero parameters and the schema is closed (additionalProperties=false), so there is no parameter meaning left to convey. Baseline of 4 applies; the description correctly spends no words on nonexistent inputs and instead invests them in the return contents.

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 specific verb+resource ('Read the current team's lead configuration') and then enumerates the three contents returned: follow-up status codes with label/colour/display order, the colour tag library, and assignable members. This is precise enough that an agent can distinguish it from the many list_* siblings without opening the schema.

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 names the exact alternatives to sequence against ('Call this before update_lead / set_lead_tags / assign_leads') and supplies the reason that makes the ordering binding: status codes, tag codes and member ids are team-specific and the write tools reject unknown values. That is an explicit when-to-use plus a stated failure mode, not an inferred one.

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