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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description is consistent with them by closing with 'Read-only.' Beyond that it adds real behavioral context: the line is assembled deterministically from card fields with no AI, and the response branches into 'line', 'candidates', or nobody depending on match cardinality. It does not state latency, limits, or what happens with very short queries, but the ambiguity handling is unusually explicit.

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?

Dense but front-loaded: the core purpose comes first, then the input, then the outcome branches. The parenthesized field list (role, relations, birthday, tags, last interaction) is long but earns its place by telling the agent what the returned line will contain. The opening guillemet phrase is decorative overhead.

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 a single documented parameter and no output schema, the description carries the return-shape burden and does so: it enumerates the three result states and the agent's obligation in the ambiguous one. Missing only edge details such as what an empty or malformed query yields and whether results are ordered.

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 0% — the schema only constrains 'query' to a 1–255 character string. The description compensates by specifying that any name, nickname, or spelling is acceptable and that matching is approximate (hence one vs. ambiguous vs. none outcomes), which is meaningfully more than the schema conveys. It omits whether partial/fuzzy input is scored or whether non-Latin spellings are normalized.

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 states a specific verb and resource: produce a one-line summary about a person drawn from the caller's OWN contact book, synthesized server-side from the card fields. 'OWN contact book' and 'no AI' scope it sharply against a general people search. It does not name a sibling (e.g. hr_list_people) as the alternative for enumeration, so it falls short of full sibling differentiation.

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 is implied rather than stated: you call it when you need to resolve who a person is. The description does give strong in-flow guidance for the ambiguous case (ask the person which candidate, never pick yourself), but it never says when NOT to use this tool or which sibling handles listing/merging people.

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