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

Annotations already establish read-only and idempotent behavior. The description adds context beyond that by revealing the output format ('sentences with numbers'), the scope of diagnostic rules, and a recommendation to run it multiple times to isolate per-client problems. No contradictions with annotations 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?

The description is compact and front-loaded, with each paragraph earning its place. The first paragraph gives purpose and the second gives a use pattern. Minor vagueness ('when a rule fires') and slightly awkward grammar keep it from being flawless, but it is not bloated.

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 an output schema present, the description does not need to explain return values. It covers the diagnostic scope, usage context, and a strategy for per-client investigation. The only noticeable gap is leaving 'when a rule fires' undefined, but the rest of the definition is sufficiently complete for correct invocation.

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?

Input schema descriptions cover 100% of the parameters, so the baseline is met. The description's mention of running 'once unfiltered, then once per client' adds mild usage context for the clients parameter, but it does not add substantial meaning beyond what the schema already documents.

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 diagnoses server health through five named problem categories ('low first-call success, heavy payloads, silent empty results, dead tools, slow tools') and is explicitly distinguished from retrieving a specific figure. The odd phrasing still conveys a specific verb+resource purpose and separates it from siblings like get_usage and get_overview.

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 explicitly says when to use this tool: 'when the user asks how their server is doing rather than for a specific figure.' It also provides a concrete usage strategy ('Worth running twice when a rule fires: once unfiltered, then once per client') and refers the agent to get_overview for per-client context, giving clear operational guidance.

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