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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false). The description goes beyond them by disclosing the dual read/write mode (no fields = read, fields = write) and by scoping the mutation strictly to personal master data, excluding access rights/roles. It does not contradict the annotations; the readOnlyHint=false correctly reflects that the tool can write.

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?

The core is front-loaded and efficient: purpose first, then the read/write rule, then sibling routing. However, the trailing '| EN: file, upload, document, attachment' is unrelated keyword noise that does not earn its place and actively risks misleading an agent into thinking this tool touches files or documents.

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 simple 5-optional-string tool with no output schema, the description covers mode semantics, scope, and sibling routing adequately, and annotations supply the safety profile. The only gap is the misleading English keyword tail, which slightly undercuts an otherwise complete definition.

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 description coverage is 100% and all 5 optional string parameters are documented in the schema itself, so the baseline is 3. The description restates the fields (Anzeigename, Telefon, Organisation, Notizen, Skills) but adds no format, constraint, or partial-update semantics beyond what the schema already conveys.

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 pair: reading or changing the profile of one's OWN account, and enumerates the affected fields (display name, phone, organisation, notes, skills). It explicitly distinguishes itself from the sibling operations onto_user_update (roles, admin only), onto_user_update_profile (other people's profiles), and onto_user_get (own account including roles). An agent can tell it apart from siblings without opening a 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?

Gives explicit conditional behavior: called without fields it returns the current state, called with fields it mutates. It names the alternatives and the exact condition that selects them (roles require an admin via onto_user_update, foreign profiles go to onto_user_update_profile, own account plus roles go to onto_user_get). Nothing is left to inference.

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