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

Annotations mark this as a non-readonly, non-destructive mutation but disclose nothing else. The description adds the crucial behavioral facts: nothing is created until the recipient acts, the user gets no access to the result, the call is refused when the email is the user's own, the link expires in 14 days, and previewUrl is publicly viewable. That is context the structured fields do not 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?

The description is long but front-loaded: purpose, then the exclusion, then behavior and outputs. Nearly every sentence carries routing or behavioral information, with only mild redundancy around the intent/output mapping.

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 tool with a deeply nested blueprint object and no output schema, the description does the important work of naming the returned links (signupUrl, receiveUrl, previewUrl) and the conditions that produce them. It is close to complete, though it delegates blueprint structure entirely to prepareSignup rather than describing it here.

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 only 44%, and the description compensates for the required parameters by clarifying that name/email must be the other person's as the user gave them, and by explaining how intent/blueprint are reused verbatim from prepareSignup. However it leaves optional parameters (lang, wishText, aboutText, countries) and blueprint internals entirely unexplained, so the compensation is partial.

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 and resource ('Prepare a rikma ... for ANOTHER person') and explicitly bounds the scope to someone other than the user. It names the sibling it is not (proposeRikmaBlueprint for the user's own business) and references prepareSignup as the format source, so an agent can distinguish it from neighbors 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 when-to-use examples (new customer's business, helping another member start) and an explicit when-not-to-use rule ('NEVER use it for the user themselves ... use proposeRikmaBlueprint'). It also adds a gating instruction ('If it is not clear who the rikma is for, ask before calling'), which is strong routing guidance.

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