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

No annotations are provided, so the description carries the full burden and does well: it declares 'Read-only' and discloses the best-effort nature ('last 150 events per search, lost on restart'). This retention caveat is exactly the kind of behavioral context an agent needs and would not otherwise know.

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?

Front-loads 'Read-only', then content, then polling mechanics, then caveats. Every sentence earns its place 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 polling/read tool with no output schema, the description covers safety (read-only), incremental mechanics (next_since), and limits (150 events, reset behavior). It implicitly reveals the next_since return field, which is valuable. The only gap is the unexplained 'limit' parameter.

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 only 33% schema description coverage, the description must compensate. It fully explains 'since' semantics (the next_since chain) but says nothing about 'limit' (max 200) or 'search_id' beyond what the schema format already states, leaving two of three parameters under-explained.

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?

States a specific verb and resource ('what the hunters are doing right now') and enumerates the event types (queries, companies resolved, signals saved, contacts found). It does not differentiate itself from close siblings like sdr_activity_feed or sdr_recent_signals, so an agent must infer which feed to call.

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 line 'Pass since = next_since of the previous call to get only new events' gives practical polling guidance, which implies this is an incremental-tail tool. However, there is no explicit when-to-use or when-not-to-use statement versus sdr_activity_feed or sdr_recent_signals, so selection relies on inference.

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