diana_status

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the three content areas the report covers, which is useful context beyond annotations, but says nothing about freshness, cost, or whether reporting triggers any probing of the bridge.

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 front-loaded sentence with no filler; the enumerations are compact and each item carries information. It is as short as it usefully can be, though the terseness contributes to the missing usage guidance.

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 zero parameters, an output schema covering return values, and annotations covering safety, the description only needs to convey scope — which it does. A brief note on when to reach for it relative to diana_start or the other status tools would make it 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No conflicting or missing parameter information is present.

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?

"Report" plus three concrete resources (DIANA installations, live DianaIE bridge sessions, cached API references) makes the tool's scope immediately legible. It is not explicitly distinguished from adjacent status-like siblings such as diana_community_status or diana_job_status, so an agent must infer the boundary from the resource names.

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 usage — check this to see what is installed, whether a bridge session is live, and what API references are cached — but never states when to call it versus alternatives or whether it should precede diana_start. Usage is inferred rather than prescribed.

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