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

Annotations are minimal (three false hints), so the description carries the behavioral burden. It discloses the tool's most non-obvious contract: a partial/incomplete profile is still saved and missing fields are reported back, rather than the call failing validation; and sending is gated on completeness. This is exactly the kind of behavior an agent cannot infer from the name or schema and it is clearly stated.

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 tight sentences per language, each carrying one distinct fact: purpose/scope, the partial-save-and-report behavior, and the sending requirement. The content is front-loaded and every clause earns its place; the only length comes from the deliberate bilingual (DE/EN) duplication, which is an accessibility choice rather than bloat.

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 9-parameter write tool with nested objects and no output schema, the description covers the key uncertainty an agent faces — what happens on incomplete input (saved, missing fields reported) — and sketches the sending consequence. The remaining operational details (id-based upsert selection, isDefault default-marking side effects) live in the schema, which is rich enough to carry them.

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 89% (only 'reasoning' lacks a description), and the schema descriptions are already rich — id's create-vs-edit semantics, isDefault's side effects, defaultDesignId's null-vs-omit distinction. The description's field list (Rechtsform, Pflichtangaben, Bankverbindung, Haftungsausschluss, Briefpapier) merely mirrors the schema property names without adding deeper meaning, so the baseline 3 is correct.

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 opens with a specific verb-resource pair — "Legt ein Absenderprofil an oder bearbeitet es" (creates or edits a sender profile) — and enumerates the affected fields (Rechtsform, Pflichtangaben, Bankverbindung, Haftungsausschluss, Standard-Briefpapier). The create/edit (upsert) semantics clearly distinguish it from the read-oriented siblings sender_profile_get, sender_profile_list, and sender_profile_validate.

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 conveys workflow context: incomplete profiles are saved and missing fields reported for step-by-step completion, and sending requires complete mandatory details. This implies when the tool is useful (iterative profile setup), but it never names alternatives or states explicit when/when-not conditions — the routing to sender_profile_validate for per-legal-form required fields appears only in the schema, not in the description.

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