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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral detail beyond that: a hard cap of 10, newest-first ordering, inclusion of resolved incidents, non-deleted filtering, and organization scoping. It says nothing about what happens when the heartbeat does not exist.

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?

Two tight sentences: the first front-loads scope, limit and ordering, the second handles routing to the alternative. No filler or repetition.

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 one required parameter, full annotation coverage and no output schema, the description supplies everything needed to call correctly: the cap, ordering, what incident states are returned, and where to go for broader search. Nothing material is missing for a tool of this 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?

The single parameter has 100% schema description coverage, including the pointer to HeartbeatList for obtaining the Id, so the schema carries the semantics. The description only implies that this identifier selects the heartbeat; it adds no format or sourcing detail of its own, making baseline 3 correct.

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 gives a specific verb and resource (get incidents for a heartbeat) plus hard scope: max 10 results, non-deleted only, authenticated organization, newest first, active and resolved included. That is enough to distinguish it from heartbeat_logs, incident_list and monitor_incidents without opening any schema.

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?

It routes the agent explicitly to IncidentList (sibling incident_list) when paginated searching is needed, which is concrete when-to-use-elsewhere guidance. It does not address other plausible alternatives such as monitor_incidents or heartbeat_get, so it stops short of full exclusion guidance.

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