Get one storyline

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

Annotations already cover read-only, idempotent, open-world safety. The description adds meaningful behavioral context beyond that: `top_topics` appears only when the members list is cut, `more_statements` indicates truncation, and crucially the cursor is null unless `statements` is at maximum, causing `search_statements` to restart and repeat. That cursor-reset behavior is a subtle trait worth disclosing.

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 return summary, followed by dense but purposeful paging instructions. Every sentence carries information about output or continuation behavior. It is a single dense paragraph rather than clearly structured subsections, but it avoids true redundancy.

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 must explain the return shape, and it does: topics (oldest first), newest statements, `top_topics` fallback, `more_statements`, and `statements_cursor`. It does not describe the internal fields of a topic or statement, but for a retrieval tool that is reasonable and likely covered by sibling tools.

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%, so baseline would be 3. The description adds value by explaining the practical consequence of parameter values: `members` at maximum versus paging via `find_topics`, and `statements` at maximum as the only way to obtain `statements_cursor`. It clarifies how parameters interact with returned fields, not just their types.

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 resource (one storyline) and what it returns (topics oldest-first and newest statements), making the detail-view nature clear against the plural `storylines` sibling. It does not explicitly name the list endpoint or `get_topic` as alternatives, so sibling differentiation is inferable rather than stated.

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 gives explicit paging guidance: raise `members` to maximum if topics are truncated, use `find_topics` for longer storylines, and raise `statements` to maximum to get a cursor for `search_statements`. It never says when to choose this over `storylines` or `get_topic`, but the within-call guidance is strong.

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