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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat that. It adds value by clarifying the output semantics: 'Returned participant user IDs can be reused for membership operations; they are NOT chat IDs.' This prevents a common misuse. It also states the tool works only for group/multi-party chats, which is a behavioral constraint not in annotations. No contradiction.

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 front-loaded with the purpose, then provides resolution guidance and output clarification. It's not overly long, and every sentence contributes value. The warning and reuse note are important. Slightly verbose due to repetition of schema content, but still efficient.

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, the description explains what is returned (participant user IDs) and clarifies they are not chat IDs. It covers how to obtain chat_id and what not to pass. It doesn't mention pagination, error cases, or authorization requirements, but for a simple list operation with strong annotations (readOnly, idempotent), this is adequate. Minor gaps remain but the essentials are covered.

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 100% – both chat_id and account_id have detailed descriptions that already cover semantics. The tool description repeats some of that (e.g., 'Never pass: person name, user_id, message_id') but adds no new parameter-specific information beyond what's in the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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: 'List members of an exact group/multi-party chat.' It clearly differentiates from sibling tools like chat_add_participant and chat_remove_participant by focusing on listing. The emphasis on 'exact group/multi-party chat' and the warning about not passing person names or message IDs further pin down the scope.

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?

The description gives explicit instructions: 'Resolve chat_id first,' how to obtain it ('Obtain with: provider list conversations/inbox chats -> chat.id'), and what never to pass ('Never pass: person name, user_id, message_id'). It also notes that returned user IDs can be reused for membership operations, implying when this tool is useful before adding/removing participants. This is comprehensive and unambiguous.

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