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

Goes well past the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true): aliases accumulate rather than replace, so nothing is lost but they pile up; validation only rejects empty mailbox/alias so umlauts pass validation and fail at Plesk; mailbox existence is not pre-checked and a missing mailbox causes rejection with no changes (explicitly framed as normal, not a failure). This is exactly the kind of operational context annotations cannot carry.

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?

Operationally dense and mostly earning its space, but notably long, and the meta-warnings about previously incorrect answers ("die frühere Auskunft ... war falsch und darf dem Kunden nicht mehr gegeben werden") appear twice and restate the same point in different words. Useful for correcting stale agent priors, yet bloated for a three-parameter tool.

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, no enums, and a flat three-parameter object, this covers everything an agent needs: prerequisites, the additive (non-destructive) effect, the failure mode for a non-existent mailbox, the fact that umlauts surface only at Plesk, and the deletion alternative. Nothing material is left to inference.

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% and every parameter already has a description with an example, so the baseline is 3. The description adds relationship semantics (the alias is a local part attached to the named mailbox's local part within the given domain) but no syntax or constraint detail beyond what the schema states.

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 precise verb and resource ("Setzt einen Alias für ein bestehendes E-Mail-Konto") plus a concrete example showing the additive effect ("kontakt" liefert zusätzlich an "info"). It also names the sibling it is not (remove_email_alias) and the sibling that reveals state (get_email_accounts), so an agent can route 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?

Explicit when-to-use and when-not: this path cannot delete an alias, use remove_email_alias for that; call get_email_accounts first (especially before a repeat call) so you don't add another alias inadvertently; if unsure whether the mailbox exists, look it up rather than guessing. Alternatives and preconditions are both spelled out.

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