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

Annotations already establish that this is a safe, read-only, idempotent, open-world operation. The description adds useful behavioral context beyond that: pagination ('a page'), ordering ('oldest first'), return shape ('thread's reply count (rc) and last reply...'), and an auth requirement. It stops short of explaining pagination mechanics or the effect of the replies parameter.

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 short and front-loads the return shape, but it is telegraphic and fragmentary ('last reply...', 'Needs key or sign-in.'), with an unexplained abbreviation (rc). It avoids waste but sacrifices clarity in the process.

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?

There is no output schema, so the description bears responsibility for return semantics and parameters. It partially describes the returned page's contents but leaves most of the six input parameters undocumented and does not explain the replies flag or pagination behavior, which is too thin for this tool.

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 description coverage is 0% across six parameters, so the description must compensate. It only hints at 'key' as an auth alternative and 'page' as pagination, leaving after, before, limit, space, and replies entirely unexplained in both schema and description.

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 conveys that this returns a page of top-level messages in a space, ordered oldest first, with reply metadata. However, it is phrased as a result description rather than a clear verb+resource statement, and the distinction from siblings like space_thread_read or thread_read is only implied by 'top-level 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?

'Needs key or sign-in' provides an authentication prerequisite but says nothing about when to choose space_read over alternatives such as space_thread_read, thread_read, space_context, or space_unread. No exclusions or selection criteria are given.

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