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

With annotations declaring readOnlyHint=false, destructiveHint=false, openWorldHint=true, the description adds real value beyond them: it discloses the replace-semantics of the assignment, the team-membership validation failure, the no-confirmation default, and the API-key/scope requirement. It does not describe rate limits or auth failure responses, so it falls short of 5.

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-loaded with the core action, and every sentence carries information. The phrasing "runs without asking by default and one more call reassigns it" is slightly awkward but conveys useful reversibility context; otherwise efficient.

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 two-param mutation with no output schema, the description covers purpose, replacement behavior, failure condition, reversibility and auth scope. An agent has enough to invoke it correctly; only the exact error/response shape is unaddressed.

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 100% and both params already point to their discovery sources (list_leads, get_lead). The description adds no semantics beyond the schema, so the baseline 3 applies.

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+resource ("Assign a lead to a team member") and adds the crucial qualifier that it replaces the current assignee rather than adding to a list. This clearly distinguishes it from resimpli's other lead mutations (tag_lead, update_lead_status, enroll_lead_in_automation).

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 a concrete failure condition ("fails if the user_id is not on your team") and notes the operation is reversible by calling again, which tells the agent when it can safely proceed. It stops short of naming explicit alternatives or prerequisites for obtaining the IDs beyond the schema, so not a 5.

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