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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that results reflect current state (up/down now) plus a percentage, and that check failures identify the failing step, which is useful output-shape context. It does not describe freshness, polling cadence, or what happens for a monitor with insufficient history.

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?

A single dense sentence with no filler, and the two content categories are stated up front. The parenthetical field hints are compact and earn their place.

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, two-optional-parameter tool with no output schema, the description is close to adequate but doesn't say how monitors and checks are grouped in the response (two sections? per-project?), which matters since two data types are returned. Annotations cover safety, so the remaining gap is structural rather than behavioral.

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 both the range enum (24h/7d) and the project scoping rule are already documented in the schema. The description adds nothing about how range affects uptime percentage calculation or which project is chosen by default. 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?

The description names two concrete resources it reports on: uptime monitors (up/down state, uptime %) and Relia's own synthetic checks (passing, failing step). That is specific enough for an agent to know what comes back. It stops short of a clean verb+resource statement and doesn't distinguish itself from nearby siblings like relia_status or relia_vitals.

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?

There is no guidance on when to call this versus relia_status, relia_vitals, or relia_dashboard, which all plausibly overlap. No prerequisites, no exclusions, no mention of which project context is required.

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