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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new context — that results come back as separate ambiguous candidates with source evidence and coverage, and that discovery is not a proof of account access. It does not say anything about matching strictness for names versus exact email/phone, so the added value is real but partial.

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 tight sentences with the lookup keys front-loaded and the scope caveat second; nothing is redundant with the title. "Honest coverage" is slightly jargon-flavoured but still conveys that partial results are reported rather than silently dropped.

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 brief return-shape sentence does useful work, and the auth caveat heads off a common misuse. Still missing for a three-required-parameter discovery tool: whether matching is fuzzy or prefix-based, and how `company`/`environment` constrain the search space.

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%, so the description carries the burden, and it does explain what `q` accepts (name, customer UUID, provider identifier, exact email/E.164 phone). It says nothing about `company` (UUID scope) or why `environment` must be chosen, leaving two of three parameters to be inferred from format/enum alone.

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 ("Search the saved company customer store") and enumerates the accepted lookup keys (name, customer UUID, provider identifier, exact email/E.164 phone). The purpose is unambiguous, but it never contrasts itself with near-neighbours such as summer_cases_customer_profile or summer_cases_search, so an agent must still infer which discovery surface to pick.

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 line "Discovery never verifies account access or searches Rebody Auth" gives an implicit when-not boundary and hints that a separate access/auth path exists, but no sibling tool is named and no positive triggering condition ("use this when you have only a name or phone") is given. Usage is implied rather than prescribed.

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