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

Annotations only declare the safe-read profile; the description adds substantial behavioral context: data is from a once-daily turbocheck report with a timestamp, events since the last run are absent, incoming mail is excluded, and an unreadable log yields an explicit message rather than a misleading zero. It also separates stuck-queue mails from these figures.

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?

Purpose is front-loaded in the first clause, followed by tightly packed caveats that each add non-obvious information. It is dense and slightly long, but no sentence is filler.

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?

There is no output schema, yet the description explains what is returned (counts by category plus a timestamp) and the critical edge cases around missing data. For a single-parameter read tool this is 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 coverage is 100% for the single 'domain' parameter, so the schema already carries the parameter meaning. The description adds domain scoping semantics (counts only outgoing mail of that domain), which is useful but not a substitute for additional syntax detail. Baseline 3 is appropriate.

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 states a specific verb and resource (retrieving a domain's email sending status) and enumerates the exact categories reported (gesendet/gebounced/verzögert heute). No sibling tool covers this resource, so the agent can identify it immediately.

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?

Usage is implied through the scope constraints (outgoing mail only, daily report, current day), which tells the agent when the numbers are meaningful, but no alternative tool or when-not-to-call condition is named. Adequate but leaves routing to inference.

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