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

Annotations only supply destructiveHint=true; the description adds real context beyond that: it is a mutation, it hits POST /v2/guests as JSON, complex array fields must be routed through `fields`, and it returns the created guest. It does not cover auth/permission requirements or side effects like duplicate handling.

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?

Four short, front-loaded sentences with the MUTATES warning first, then endpoint, then the key parameter-handling caveat, then return value. Slightly dense but every sentence contributes; nothing is padding.

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, noting 'Returns the created guest' is valuable, and the array-via-fields caveat closes the biggest gap for a nested-object schema. Missing only auth/permission prerequisites and duplicate-guest behavior for a no-required-parameter mutation.

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% so the typed fields are already documented (baseline 3), but the description adds meaning the schema's generic `fields` blurb does not: emails/phones/addresses are arrays of objects and must go through the passthrough with a concrete example shape.

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 ('creates a new guest (contact)') and even names the underlying API endpoint POST /v2/guests. This clearly distinguishes it from siblings like update_guest, get_guest, and list_guests.

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 gives a concrete usage hint — pass array-shaped values like email_addresses through the `fields` passthrough — but never states when to choose this tool over update_guest or what prerequisites (auth, permissions) apply. Usage is implied rather than explicit.

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