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

Annotations already declare readOnlyHint=true, lowering the threshold. The description adds genuine behavioral context beyond that: 'stamped with OUR publish time' clarifies that the timestamps are the site's publication moments, not the CVE's own dates (preventing a real misinterpretation), and 'Events for withdrawn CVE ids are omitted' discloses an important filtering behavior. Both add value over the read-only annotation. No contradiction 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?

A single information-dense paragraph with the purpose front-loaded, followed by pagination mechanics and optional scoping. Every sentence earns its place: purpose, timestamp semantics, since format, cursor continuation, cve filter, and the withdrawal exclusion. Slightly long as one block, but efficient with no filler.

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 cursor-based stream with 5 parameters and no output schema, the description covers the critical calling mechanics: how to start (since), how to continue (cursor), and available filters (cve, type), plus what event types exist. Gaps are the limit parameter's semantics and the exact shape of returned events (no output schema to fall back on), but the essential continuation pattern an agent must know is fully specified. Fairly complete given the complexity.

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 only 20% (just the cve parameter has a description), so the description must compensate — and it does. It explains the since format (YYYY-MM-DD, strictly-after), the cursor continuation pattern (returned next_cursor), the cve scoping semantics, and enumerates the four type values. Only the limit parameter is left unaddressed. Strong compensation for the sparse schema.

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 identifies a specific resource ('the publication change stream: what this site published') and a distinctive mechanism (cursor-based pagination stamped with OUR publish time). This distinguishes it from siblings like get_cve (single lookup), search_cves (search), and get_epss_movers (movers) without naming them. It's clear and specific, though it doesn't explicitly contrast with any sibling.

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?

Provides concrete, actionable usage instructions: pass since in YYYY-MM-DD strictly-after on the first call, then use the returned next_cursor to continue, with optional cve/type scoping. This is explicit call-pattern guidance. However, it doesn't state when to choose this tool over alternatives such as search_cves, so the when-vs-alternatives dimension is only partially covered (clear context, no exclusions).

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