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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Read-only' is redundant. The one genuinely new behavioral fact is the null-return path when no conversation exists, which matters for callers but is stated briefly and overlaps with the usage guidance. Nothing about permissions, error modes, or what the chat object contains is added.

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?

A single tight sentence with the key constraint first and the fallback parenthesized. It borders on telegraphic style ('The existing one-to-one conversation...' with no verb) but contains no filler.

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 small, read-only, two-parameter lookup with annotations covering the safety profile and no output schema, the description covers the essential behavior: what it returns (a chat for the DM), the empty case, and the alternative tool. Remaining gaps are minor.

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 50%: user_id is documented in the schema, but account_id has no description anywhere. The description only gestures at 'a person', adding no meaning beyond the schema for either parameter and leaving the account scoping parameter unexplained.

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 identifies a specific resource: the existing one-to-one conversation between the account and a person. It is a noun-phrase fragment rather than a verb+resource statement, but the scope (existing DM only) is unambiguous and is contrasted with start_chat.

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?

It explicitly states the condition that selects this tool ('the existing ... conversation with a person, if there is one') and names the fallback ('chat_id null when there is none: use start_chat'). That is clear routing guidance; only the general purpose ('to get a chat_id') is left implicit.

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