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

With no annotations, the description carries the behavioral burden. It adds useful facts: archived read-only rooms are included, the private memory vault is covered, and no reconnect is needed. However, it does not state whether this is a safe read-only operation, describe result shape, or clarify pagination, which would strengthen an otherwise list-style tool.

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 compact and front-loaded with the core purpose, then shifts to usage workflow. Each sentence adds value, though the parenthetical '(archived=true)' and dense chaining of channel_id usage make it slightly overloaded.

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 simple listing tool with one optional connection parameter and no output schema, the description covers the main workflow and follow-up actions. It is not fully complete because the room_id/private parameters referenced in text are absent from the schema, and return fields are not described.

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 fully documents the single connection parameter, so the baseline is 3, but the description instructs the agent to use room_id and private, which are not present in the input schema. This creates a mismatch between the invocation guidance and the actual tool contract, making the parameter semantics misleading.

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 channels') and clearly scopes it to joined rooms, the private memory vault, and archived read-only rooms. This distinguishes it from siblings like rooms_list, channel_create, and pages_list without opening their schemas.

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 explains how to use room_id and private to narrow the listing, and tells the agent to use the chosen channel_id for sending/searching and to call pages_list(channel_id) for shared pages. It lacks explicit when-not-to-use guidance, but the workflow guidance is actionable and clear.

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