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

Annotations only declare readOnlyHint=true, and the description adds genuine behavioral context beyond that: result ordering (newest first), the per-run payload contents, and the important semantic caveat that failuresOnly results do not imply an Incident. It does not mention pagination behavior, though cursor/limit are covered by the schema.

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?

Three sentences, front-loaded with the resource and ordering, then filtering, then the interpretative caveat — no filler. The definitional clause about location/Check is dense but earns its place by explaining the record shape.

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?

Output schema exists and parameters are fully described in the schema, so the description only needs to cover scope, ordering, and interpretation — which it does. Minor gaps: no explicit statement about page size defaults or how to continue paging, though the schema handles both.

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 100%, so the schema already documents all seven parameters including the limit cap and cursor chaining. The description repeats the three filter parameters (location, checkType, failuresOnly) without adding format or behavior details the schema lacks, so the baseline 3 applies.

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 concrete resource and scope ('A Monitor's recent runs, newest first') and even defines what a run is — one location checking one Check — plus what it carries (outcome, status code, error, timings). That is specific enough to distinguish it from siblings like get_uptime or list_incidents, though no sibling is named explicitly.

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?

Gives operational narrowing guidance (location, checkType, failuresOnly) and a useful interpretation rule that a single failed run is not an outage, implicitly routing the agent to Incident concepts for outage questions. It never states explicitly when to prefer this tool over get_uptime, get_response_times, or list_incidents, so usage is implied rather than directed.

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