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

Annotations already declare readOnly/destructive=false, so safety needs no coverage; the description instead contributes real interpretive context — ageCategory thresholds and, importantly, that chronic (>24h) alerts are known ongoing issues rather than new incidents, which materially changes how an agent should report results. It does not cover limits, pagination, or auth requirements, hence not a 5.

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?

Purpose is front-loaded correctly, but nearly half the text is output-formatting mandates ('ALWAYS start your response with _summaryNote verbatim', 'include _signatureAscii in a code block') that are instruction creep relative to selecting and invoking the tool, and several listed result fields are already covered by the output schema.

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 read-only, zero-required-parameter lister with an existing output schema, the description is close to complete: it defines sources, active states, age semantics, and presentation expectations. Gaps remain around result limits/windowing and how to choose between this and the dedicated Datadog/PagerDuty/Prometheus sibling tools.

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% with only three params, so the baseline is 3. The description adds modest semantics for `source` (alert/warn vs triggered/acknowledged) but never mentions `withDowntimes` or `context_id`, leaving whatever nuance those need entirely to the 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?

States a specific verb and resource ('List active alerts') and defines what 'active' means per source: Datadog monitors in alert/warn, PagerDuty incidents in triggered/acknowledged. It does not, however, distinguish itself from siblings like dd_monitors_lookup, pd_incidents_search, or prom_alerts, so an agent must infer the boundary.

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?

Usage is implied through the source split (datadog vs pagerduty), but that split is already encoded in the schema enum, so the description adds little routing guidance. There is no explicit 'use this instead of X' or when-not guidance against the many sibling alert/incident tools in this namespace.

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