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

Annotations already declare this as read-only, non-destructive, and closed-world. The description adds valuable authorization semantics beyond the annotations, specifically that revoked membership removes access and elevated roles do not bypass private membership.

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?

Two compact sentences, front-loaded with what the tool reads and followed by the key access constraints. No sentence is wasted.

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 one-parameter read-only tool, the description covers the main access semantics and edge cases such as revoked membership and moderation bypass. The remaining gap is the unexplained thread_id format, but otherwise the definition is sufficiently complete.

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 single parameter has 0% schema description coverage, and the description adds no explanation of thread_id syntax, format, or expected value beyond what the parameter name implies. The regex pattern in the schema is undocumented in prose.

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 and resource: 'Read a public thread or accepted private conversation.' This clearly identifies the operation, but it does not explicitly distinguish this single-thread read from sibling tools like collaboration_threads or collaboration_messages.

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?

Provides meaningful access conditions: public threads and accepted private conversations are readable, while revoked membership removes access and owner/moderation credentials do not bypass private membership. It lacks explicit routing to sibling tools, but the when-to-use and when-not-to-use context is strong.

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