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 safety is covered structurally. The description nonetheless adds useful specifics beyond that: it will not create a mailbox and will not surface credentials, which pre-empts the two most likely wrong expectations for a 'setup' tool. It stops short of describing what the check actually reports.

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?

Two sentences, zero filler. The read-only check is front-loaded and the negative guarantees follow immediately after, which is the right ordering for an agent scanning for whether it can safely call this.

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 no output schema, the description carries the burden of telling the agent what comes back, and it only says what does not come back (no credentials, no mailbox). 'Check a configured inbox' is also ambiguous between checking a configured inbox versus checking whether the inbox is configured, and the absence of output structure leaves that unresolved. Adequate for a trivial no-arg read tool, but with a clear gap on return content.

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 zero parameters, so per the baseline rule a 4 applies and there is no schema semantics for the description to compensate for. There is nothing the schema fails to convey that the description would need to add.

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+resource combination ('Check a configured inbox', 'show the owner-controlled setup path') that separates configuration-state inspection from the message-oriented siblings voidmail_list_inbox and voidmail_read_email. It never names those siblings explicitly, so the differentiation is left partly to inference. The word 'setup' in the name is at least backed by concrete behavior in the text.

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 gives negative constraints ('never creates a mailbox or returns credentials') but no positive when-to-use condition and no named alternative. An agent must infer on its own that this is the configuration-time counterpart to the list/read/send siblings. No prerequisites or call-ordering guidance is present.

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