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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered; 'Read only' merely repeats it. The description does add real behavioral context beyond annotations: newest-last ordering, the cursor-chaining contract, the per-event payload shape, and a privacy constraint ('Words only with Messages, never someone under 18's'). However the privacy sentence is fragmentary and its operational consequence (filtering? error? omission?) is never made explicit.

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?

Very short and mostly front-loaded: the core purpose and cursor rule come first, payload description second. A few sentences are telegraphic fragments ('Words only with Messages, never someone under 18's') that trade clarity for brevity, and the 'For an AI that keeps watch' framing is flavor that costs a clause.

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 carries the return-shape burden and does so: sphere, kind, short line, and ids to continue reading with. The cursor contract closes the loop. Remaining gaps are the sparse meaning of `sphere` and the exact effect of the minor-protection rule, but an agent could call this correctly.

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 50% – `since` and `limit` are documented in-schema, while `kinds` and `sphere` are bare enums. The description reinforces `since` by telling where the value comes from, and lists the same kind values as the enum. It never explains `sphere` filtering or how `kinds` interacts with `sphere`, leaving two parameters semantically thin.

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 names a specific resource and shape: an event stream of 'what happened since a cursor, newest last', enumerating event kinds (message, mention, request, join_request, event_signup, plan_answer). It distinguishes itself from the firehose by being a cursor-driven feed and points at waiting_for_me as a related source of cursors. It stops short of crisply stating how it differs from waiting_for_me in selection terms.

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 concrete operational guidance: 'Pass `since` = the `next` from your last waiting_for_me or events call', which is the polling loop an agent needs. It also frames the audience ('For an AI that keeps watch'). It does not state when NOT to use it or how to choose between events and waiting_for_me when both could serve.

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