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

Goes far beyond the readOnly/non-destructive annotations: it discloses the EPSS emit policy (first score emits, later only on band crossings with 0.8 downward hysteresis), the fact that applicability is a flattened NVD config list where vulnerable=true over-approximates and vulnerable=false is context rather than exclusion, and that refusals are distinguishable from empty pages. These are non-obvious traits an agent cannot infer without calling.

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?

Every clause carries genuine technical payload, but the whole definition is one semicolon-heavy block where the most actionable routing instruction ('start with get_vulnerability_snapshot') sits mid-paragraph rather than up front. It is dense rather than bloated, yet a short lead sentence plus separated paragraphs for stream semantics and refusal handling would scan far better.

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 still covers return-shape essentials (public records only, no description text, ordered by source and cursor) and failure modes. It stops short of naming the response fields (e.g., the change list and cursor keys), but it supplies enough for correct invocation and sequencing.

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 the baseline is 3; the description adds real meaning on top by explaining the cursor's lifecycle (advance only on real results, non-advance on refusal) and by tying 'source' to distinct change streams with different emission behavior. It does not explain limit or the shape of next_cursor vs watermark_cursor beyond what the schema states.

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 is a cursor-ordered change feed per source ('Ordered changes by source and cursor') and differentiates it from get_vulnerability_snapshot (entry point) and get_epss_score (daily value). What it lacks is a plain opening statement of the verb+resource; the purpose is embedded mid-paragraph after EPSS minutiae, so an agent must read a while before confirming what the tool returns.

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?

Explicit routing: start with get_vulnerability_snapshot, use get_epss_score for the daily value rather than watching this stream, and on a refusal (feed_stale, feed_unavailable, feed_initializing, cursor_expired, snapshot_required) do not advance the cursor or treat it as no-changes. It both names alternatives and gives a when-not-to-act rule.

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