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

Annotations already declare the operation read-only and safe; the description adds meaningful behavioral detail beyond that: inboxes are read sequentially to respect rate limits, unreadable inboxes yield 'unavailable' instead of failing, and clients should preserve inbox_id and chat.id. This gives the agent useful expectations about partial failures and data relations.

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?

Four sentences, front-loaded with the core purpose, followed by the most important operational details. Every sentence adds distinct value: default behavior, alternatives via inbox_ids, rate-limit handling, and relationship to linkedin_read_conversation.

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 zero-required-parameter tool with rich annotations, the description covers the essential call patterns, failure behavior, and cross-tool dependencies. It could be slightly stronger on whether limit applies per inbox or overall, but the default usage and alternative inbox handling are fully actionable.

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?

The schema describes inbox_ids and account_id well, and the description adds value by explaining the default CLASSIC_PRIMARY behavior and the purpose of inbox_ids across inbox types. The limit parameter is not addressed in the description, but its min/max constraints in the schema make it self-explanatory.

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?

Clearly states the verb and resource: 'List LinkedIn private conversations' with a specific default inbox behavior. It distinguishes itself from linkedin_read_conversation by saying it should be used first, but it does not explicitly differentiate from the similar sibling linkedin_list_inbox_chats.

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?

Gives clear context: use it before linkedin_read_conversation when chat_id is unknown, and pass inbox_ids from linkedin_list_inboxes to read non-default inboxes. It does not explicitly state when to prefer linkedin_list_inbox_chats or other alternatives, but the primary routing guidance is present.

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