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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers: it reveals that no persistent connection is required, that state must be persisted between calls (next_id), that the tool batches results, and that immediate re-calling is needed to drain the backlog. This is exactly the kind of behavioral context an agent needs for a stateful sync operation.

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 efficiently structured: a purpose sentence, a pattern statement, a usage flow, and a compact Args block. Every sentence earns its place — the 'No persistent connection required' note and the drain instruction are behaviorally significant, not filler. There is no repetition of schema information, and the content is front-loaded with the core purpose.

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?

Given this is a stateful pagination tool with no annotations and no output schema, the description covers the critical operational details: first-run initialization, state persistence, backlog draining, and parameter ranges. The only minor gap is that the min_severity 0–10 scale's meaning is left to the agent's inference (does higher mean more severe?), and the next_id return contract is implied rather than explicit.

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%, so the description must fully compensate, and it does. It adds substantive meaning beyond the schema's bare defaults: last_id is explained as the high-water mark to persist between calls, batch_size gets a valid range (1–5000) and semantics ('max signatures to return'), and min_severity gets a range and behavior ('skip signatures below'). This directly enables correct parameter usage.

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 opens with a specific verb-resource-scope construction: 'Fetch new threat signatures since a high-water mark ID.' This clearly identifies the tool's function and differentiates it from siblings like get_new_threats (bulk retrieval) and check_freshness (status check) by emphasizing the incremental high-water mark pattern and explicitly labeling it 'the recommended sync pattern.'

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?

The description gives strong usage guidance: call with last_id=0 on first run, persist next_id, pass it on subsequent calls, and drain backlog when count == batch_size. It explicitly states this is 'the recommended sync pattern' versus a persistent connection. However, it doesn't name specific sibling alternatives or state when NOT to use this tool, stopping just short of the explicit when/when-not standard.

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