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

Annotations already cover read-only, non-destructive, closed-world, so the description isn't burdened with safety disclosure and instead adds real behavioral context: the record comes back joined with contact, call, transcript and message. It also discloses a non-obvious downstream trait — that message_author determines whether a message may be attributed to the lead — which nothing in the structured fields conveys.

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 purpose is front-loaded, which is good, but the paragraph spends most of its length on message_author and repeats the same conditional twice ('Only when message_author is "the lead"...' then 'unless message_author says the lead wrote it'). The aside 'That field is not decoration' is editorial filler that could be cut.

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 carries the burden of describing return content, and it does so reasonably: contact, call, transcript, and message with author attribution. It does not say what happens for an unknown or deleted lead_id, and the enumeration of returned fields isn't exhaustive, which keeps it from a 5.

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?

One parameter at 100% schema coverage, so the baseline is 3. The description adds nothing about lead_id — no format, no hint that it typically comes from list_leads or a lead-creation response — so it neither compensates nor detracts.

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 and resource ('Fetch a single lead') and enumerates the expansions it hydrates: linked contact, originating call, transcript, and taken message. It never names a sibling (list_leads, get_contact) to disambiguate, so it lands at 4 rather than 5.

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?

Usage guidance is entirely about how to interpret and re-use the returned message (never quote it back, never write 'you said' unless message_author is 'the lead'), which is genuinely useful. But there is no guidance on when to call this versus list_leads or search_contacts, nor any precondition such as needing a lead_id from a prior listing call.

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