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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that: the result is scoped to the caller's merchant (a tenancy boundary an agent must know) and the value format is exemplified ('english'). It omits not-found behavior, which is the only meaningful gap.

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 short sentences: the return value and scope first, then the call requirement. No filler, nothing repeated from structured fields except a harmless '[read]' tag.

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 simple single-value read with rich annotations, the description covers what is returned, the example format, tenancy scoping and the parameter requirement. Without an output schema it adequately describes the return; only error/empty-case behavior 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 coverage is 0% and both params are nullable with no constraint, so the schema alone would suggest calling with neither. The description's 'Pass `lead_id` or `lead_uuid`' corrects that by signalling an either/or identifier requirement, which is genuine added meaning. It does not explain when to prefer one identifier over the other.

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?

Names a specific verb+resource combination ('Content language of a lead') and gives an example value (`english`), so an agent can immediately tell this apart from get_lead (full record) and the sibling get_*_language tools for other resources. It never explicitly states the contrast with get_lead, which keeps it from a 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?

The description implies usage ('Pass `lead_id` or `lead_uuid`') and notes the caller's merchant scope, but gives no explicit when-to-use vs when-to-use-something-else guidance (e.g. use get_lead if you need the full record, not just language). Usage is inferable but never stated.

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