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

Annotations already declare a non-read-only, non-destructive, closed-world write, and the description is consistent with that while adding genuinely useful context: it is write-only and setting requires the person's consent first. What it does not disclose is the update semantics — with zero required fields, an agent cannot tell whether sending one field merges with existing values or whether omitted fields are cleared. For an all-optional upsert tool that is a meaningful omission.

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 purpose is front-loaded in the opening clause, and the parentheticals each carry distinct routing information rather than filler. The single long sentence does stack several clauses, and 'as the agent gives them to a venue' is slightly circular, but almost nothing is redundant.

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?

There is no output schema and the safety profile is covered by annotations, so the description does not need to explain returns. The remaining gap is behavioral: five optional fields with nothing required means the definition should say what an empty or partial call does to stored values. That is the one thing an agent most needs before invoking it.

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 schema already documents all five fields, and the description correctly adds intent beyond the field descriptions (name for bookings, email for confirmations and payment links, mobile explicitly excluded, address only when a task needs it). That baseline-3 score reflects real added meaning. However, two of the five parameters, notes and timezone, receive no treatment in the description at all, so the added semantics are 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?

The description names the resource concretely (the person's full name, email, address) and what it is for (the details the agent hands to a venue), and 'Pass fields to set them; nothing to read' establishes the tool as a write-only setter. It also implicitly separates itself from my_mobile by saying 'never their mobile'. The verb is oblique, though — 'pass fields to set them' rather than a direct statement that this creates or updates stored contact details.

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?

It gives per-field usage conditions ('the address only when a task needs it', email for confirmations and payment links) and a clear precondition, 'Ask your person before setting these'. It also rules out the read direction with 'nothing to read', which steers the agent away from using this to retrieve details. No sibling is named as the read alternative, so the routing half of the guidance is only implied.

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