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

With no annotations the description carries the full burden and mostly does: it declares scope (only used rooms of public projects, opened by default), the contents returned (mode, channel message counts, forum threads, last activity, voice occupancy), and hard exclusions (closed rooms, private projects). It omits pagination/result limits and any auth or rate-limit context, which is the main remaining gap for a list 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?

It is a single sentence, but a heavily nested one: a parenthetical aside, then a colon-introduced list of returned fields spliced into the middle. The core claim (list a person's rooms) is front-loaded, yet the sentence is harder to parse than it needs to be and could be split.

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?

With no output schema, the description does the work of sketching the return shape (mode, channels with counts, threads, last activity, voice participants) and the visibility rules. Missing pagination or ordering behavior is the only substantive hole for a read-only enumerator.

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?

One required parameter whose schema entry is fully documented ('Username, with or without @.'), so coverage is 100%. The description adds nothing about the handle or whether it accepts display names/IDs, so the baseline 3 applies.

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 the resource precisely: project rooms belonging to a given person, restricted to public/open projects. It does not name a sibling to contrast with, but the exclusion clauses ('closed rooms and private projects never appear') implicitly separate it from list_projects and get_project.

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?

Usage is implied rather than stated: an agent can infer this is the enumeration path for a person's rooms, and the note that empty/closed/private rooms are omitted is a useful conditional. But there's no explicit when-to-use versus read_room or vs list_projects, and no prerequisites or handle requirements beyond the schema field.

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