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

Goes well past the annotations by disclosing the external side effect (an email confirmation is sent, SMS if configured) and the failure shape (a clash returns booked:false + conflicts). It also flags the user-confirmation requirement and the constrained retry path, which an agent could not infer from readOnly:false / destructive:false alone.

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?

Eleven parameters are covered in five dense sentences with the primary action front-loaded and the mode prefixes ("slots:", "book:") making it scannable. No sentence is filler; the telegraphic style costs a little readability but maximizes information density.

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 an 11-param, non-idempotent, open-world write tool with no output schema, the description covers side effects, conflict handling, and consent requirements. The remaining gap is the success return shape (what a confirmed booking yields) and the exact semantics of newContact, which neither description nor schema fully pins down.

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 73%, so the schema does most of the work, but the description adds genuinely new semantics: the contactId OR name+email/phone alternative path for identifying the contact, and the from/to date format scoping for slots. It stops short of explaining newContact or the allowOverlap/conflicts interaction in detail.

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?

"Book a contact into a meeting type" is a specific verb+resource, and the description immediately separates the two modes of operation (slots vs book) so an agent knows this tool both reads availability and writes a booking. It does not name the related sibling meeting_types_list/meeting_types_manage, so differentiation from those is left to the schema's "From meeting_types_list" hint.

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?

Offers real conditional guidance: prefer an open slot, any future time only if the user asks, allowOverlap only with user agreement, and confirm with the user before proceeding. These are clear when-to/when-not rules for the internal modes, though no alternative tool is named for cases where the booking should not happen here.

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