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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true and non-idempotency, so the mutation profile is covered. The description adds that the code governs what access the redeemer receives and that the code itself must be handed off elsewhere rather than recorded here. It does not state whether repeated calls with the same label create duplicates or what the response contains, which would be the higher-value addition for a create tool.

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 sentence, but the definition is padded: the 'Weg (b) | Die Einladung geht in beide Richtungen' passage is vague and off-topic, and the 'EN: invitation, invite, voucher, code, bundle' keyword tail is search metadata rather than agent guidance.

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 10-parameter create tool with full schema coverage and no output schema, the description supplies the purpose, the permission dimension, the handoff rule and the two sibling routes, which is close to sufficient. It would be complete with a note that the created code is returned by the call and a hint about the can_manage_scope prerequisite.

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 the schema already explains kind, max_uses, unlimited, expires_days and the permission flags in detail. The description adds nothing about individual parameters beyond the general 'der Code steuert, welchen Zugang der Beitragende erhaelt'. With the schema doing all the work, the baseline 3 applies.

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 first sentence gives a concrete verb+resource (create an invite code) plus its effect: new members can self-register and the code determines the access the redeemer gets. Siblings are named explicitly (list_invite_codes, revoke_invite_code), so the boundary is visible. However, the trailing 'Weg (b)' sentence about inviting people/agents into your scope after setup describes a different workflow and blurs what this tool actually does.

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 ('Nutze es zum Anwerben von Mitgliedern/Subunternehmern') and explicit routing to alternatives for the adjacent tasks: manage with list_invite_codes, invalidate with revoke_invite_code. It also warns not to store the code here. The only gap is that the ambiguous 'Weg (b)' paragraph reads like an alternative usage without saying when that path applies.

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