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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real behavior: only threads with a sent message or reply appear, each result carries its campaign and reply_classification, and the newest reply's class is retained even after the reply is marked done. It does not explain pagination behavior or ordering of results, which keeps it below a 5.

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 definition is dense and front-loaded, with the core purpose in the first sentence and the constraints packed into short, scannable clauses. A couple of fragments (e.g. 'There is no text search.') are telegraphic, but nothing is wasted.

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 read-only listing tool with a nested query object and no output schema, the description covers what is listed, what each record carries, how to filter or fetch individually, and the known dead ends (no text search). Return shape details such as field-by-field content and pagination order are left implicit, a minor residual gap.

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% and the single top-level parameter is a nested object with seven fields, so the description carries real weight: it enumerates the view values, explains that enrollment_id and thread_id are lookup keys for a single conversation, and clarifies the account_id/enrollment_id dependency. It does not explain limit/cursor semantics beyond the schema defaults and constraints.

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 names both the verb and resource ('Lists campaign email threads and LinkedIn chats') and scopes it precisely to conversations that contain a sent message or a reply, plus network chats. It also draws a clear line against the sibling 'listReplies' by warning that a reply retrieved there should be re-passed by enrollment_id, not its id.

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 tells the agent how to use it (filter by view = replies/sent/all, or fetch a single item by enrollment_id or thread_id), states an explicit limitation ('There is no text search'), and gives a dependency rule ('account_id is a sending account and needs enrollment_id'). It also names a concrete cross-tool alternative (listReplies) and the correct handoff between them.

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