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

Annotations already cover read-only, idempotent, non-destructive and open-world traits, and the description adds value beyond them: pagination tie-breaking for revisions sharing a timestamp and the note that source announcements retain their original date. It does not address return shape or ordering guarantees beyond 'chronological'.

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 short sentences, front-loaded with what the feed contains, then the operational instruction. No filler, though the 'source announcements retain their original date' caveat is appended without indicating why an agent should care.

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 3-param, no-output-schema read tool this is nearly sufficient, but it introduces response fields (nextCursor, hasMore) that are not documented in any output schema, uses a cursor name that mismatches the schema, and leaves 'limit' and result ordering unexplained.

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?

With 0% schema description coverage, the description must carry all parameter meaning, and it covers only part of it: 'since an ISO timestamp' explains the required param, and the cursor is referenced obliquely as 'nextCursor' — a name that does not match the actual parameter 'cursor'. The 'limit' parameter (default 100, max 200) is never mentioned anywhere.

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 is precise about the feed's semantics: it returns chronological first observations plus status/date revisions, which tells an agent this is a revision feed rather than a snapshot. It never names the resource (catalysts) and does not distinguish itself from siblings like catalysts.event or market.catalysts, so an agent must infer scope from the tool name alone.

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?

'Persist nextCursor and follow hasMore to avoid missing revisions with identical timestamps' gives real operational guidance about how to consume the feed. However, there is no statement of when to use this versus catalysts.event or market.catalysts, nor any prerequisite (e.g. which timestamp domain 'since' refers to).

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