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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining the ordering (curator's order), the return structure (post summary fields plus optional note), and the privacy behavior (private collection not found). No contradictions with 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?

Three sentences with no wasted words. The first sentence delivers the core action, the second explains the rich return benefit, and the third covers an important edge case. Information is front-loaded and easy to parse.

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 an output schema, annotations, and a clear description covering ordering, return content, privacy behavior, and the note on no follow-up calls, the description is fully adequate for a read tool. No significant gaps remain.

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 coverage is 100%, and the input schema already describes collection_id as 'The collection's UUID, from colony_list_collections.' The description reinforces this relationship but does not add new parameter-level syntax or format details. Baseline 3 is appropriate.

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 clearly states 'Read one collection and every post in it, in the curator's order.' This is a specific verb+resource pair, and the mention of retrieving all posts within a collection distinguishes it from sibling tools like colony_list_collections (list only) or colony_create_collection (write).

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 implies when to use: when you need a collection's full content. It notes that private collections you don't own return not found, which guides usage. However, it does not explicitly mention alternatives (e.g., colony_list_collections for IDs, colony_add_to_collection for modifying) or define clear exclusion criteria.

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