get-diagnostics

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

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely useful behavioral detail: text lists problems in state PRESENT with code/severity/date, and the full response lives in structuredContent. It stops short of explaining what PRESENT means, other states, or pagination, keeping it at a strong 4.

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, purpose front-loaded, then usage trigger, then the negative routing. No filler; every sentence 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 single-parameter read tool, the description covers purpose, trigger, exclusions, and even compensates for the absent output schema by explaining that text lists PRESENT problems while the full payload is in structuredContent. Nothing essential is missing.

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% and there is only one parameter (host_id), which the schema already documents. The description adds no additional meaning about the parameter. 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 specific verb and resource ('Get site diagnostics') and immediately clarifies scope by contrasting with sibling tools. An agent can distinguish it from get-excluded-pages and get-search-events-samples without opening any schema.

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 an explicit when-to-use trigger ('user asks what site problems Yandex currently reports, such as mobile or security issues') and an explicit when-not with named alternatives ('Do not use it for pages that dropped out of search; call get-excluded-pages or get-search-events-samples'). Routing is unambiguous.

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