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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail that the ping URL is included for heartbeat monitors and that the slug/page_id path works on shared pages. It doesn't disclose response shape or error behavior, but with annotations covering safety, a 3 is appropriate.

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, well-structured sentence that front-loads the primary lookup mode (by id), then adds the alternative mode and the shared-page caveat. No wasted words; every clause earns its 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, idempotent tool with no output schema, the description covers the two lookup paths and the special ping URL behavior. It doesn't mention what happens if both id and slug/page_id are provided, or if no parameters are given, but the schema shows no required parameters. Given the tool's simplicity and annotation coverage, this is nearly complete.

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 three parameters. The description adds the relationship between id and the slug/page_id pair, and clarifies that slug requires page_id, which is useful. However, it doesn't add details beyond what the schema descriptions imply, so the baseline 3 is 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 clearly states the tool's purpose: retrieving a single monitor by id, or by page_id and slug. It also distinguishes the two lookup modes and notes that the slug/page_id path works on shared pages, which adds specificity beyond the title.

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 description implies when to use this tool: when you need one monitor's details, especially its ping URL for heartbeat monitors, or when you have a page_id and slug. It doesn't explicitly contrast with list_monitors, but the 'one monitor' scope and the shared-page note provide clear context. No exclusions are stated, but the sibling list makes the alternative obvious.

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