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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: results are scoped to the current team, all extra data (submissions, comments, change timeline) is opt-in, and lookup must never use a masked email. Return-value details are left to the output schema, which is appropriate.

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 two sentences with no filler. The first sentence front-loads the primary purpose and result contents; the second covers optional inclusions and the critical lookup rule. Every clause earns its place and the structure supports quick comprehension by an agent.

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 read-only tool with a rich output schema and fully described parameters, the description is complete: it names the identifier, scopes the query to the current team, explains the optional expansions, and warns against the masked-email anti-pattern. An agent has everything needed to call this tool correctly without further inference.

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 four parameters well, giving a baseline of 3. The description adds value by translating the boolean flags into the exact content they include (submission history, internal comments, change timeline) and by emphasizing the leadId/examineeId reference rule. This is useful extra semantic guidance, though the schema already carries the core meaning.

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 and resource: 'View one lead of the current team by leadId.' It then enumerates the payload contents (follow-up status, assignee, tags, respondent block, next booking), making it unambiguous what this tool returns and clearly distinct from list-oriented or examinee-focused siblings. It leaves no doubt that the resource is a single lead, not a record or examinee.

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?

The description gives clear contextual guidance: the lead must belong to the current team, and lookups must use leadId/examineeId rather than a masked email. It also clarifies the optional include flags behavior. However, it does not explicitly state when to prefer get_lead over sibling tools like get_examinee or list_leads, so it stops short of full routing guidance.

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