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

Annotations already cover readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, and the description adds substantial context beyond these: the login requirement, the semantic meaning of each returned field (unread, muted, invite), group-type behavior differences (activity group vs icebreak intro group), and the isSecretary official-account behavior. No contradiction with annotations — the description's read-only list semantics align perfectly with the annotations.

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 description is dense — four paragraphs — but every sentence carries routing or disambiguation value. The primary purpose is front-loaded in the first sentence, followed by group-type discrimination, then per-field semantics, then the official account case. It is longer than typical but the length is earned: a list tool with no output schema in a 200+ sibling ecosystem needs this much routing detail to be safely used.

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?

Given there is no output schema and the tool sits in a large conversation-tool ecosystem, the description is thorough: it explains the primary use (obtain conversationId), all returned field semantics, group-type discrimination, the no-contact-exchange-in-groups rule, and the official secretary channel. It routes to at least 8 sibling tools correctly. The only minor omission is pagination/limit behavior, but with 0 parameters that's likely a full listing, so nothing essential is missing.

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 tool has 0 parameters and schema description coverage is trivially 100%, so the baseline is 4. The description compensates for the absence of an output schema by explaining what the returned fields mean (unread, muted, invite, isSecretary), which is valuable routing semantics. It doesn't deeply define types/formats but that's not required with no parameters to document.

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+resource: '列出当前用户的所有私信会话' (lists all the current user's private message conversations), and enumerates the returned fields (unread count, latest preview, member info). It clearly differentiates from siblings by explaining what it is NOT (not read_messages, not send_message, not get_conversation) and routes to them explicitly. The 认群 (group recognition) section further disambiguates against get_conversation_members and get_conversation.

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 explicit when-to-use and when-not-to-use guidance: '先用它拿 conversationId 再 read_messages / send_message' establishes it as the entry point. It names alternatives with selection conditions: get_conversation_members for activity-group member walls, get_conversation to verify icebreak groups, request_contact_exchange for contact exchange in DMs (explicitly NOT in groups), list_my_invitations/respond_activity_invitation for pending invites, set_conversation_muted for muted. It even warns against looking for a separate 'unread total' tool. Nothing is left to inference.

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