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

Annotations cover the safety profile (non-read-only, non-destructive, non-idempotent, closed-world), and the description adds real context on top: the output is a draft with no publishing, no subscription activation and no email side effects. It does not explain whether the draft persists or must later be committed via save_booking_draft, which would complete the picture.

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?

Three short sentences, front-loaded with the action and followed by a constraint and a scope boundary; every sentence carries information. Slightly terse given the complexity of the underlying config payload, but no waste.

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?

This is a mutating create tool with a free-form nested config object, no output schema and no annotations explaining consequences, yet the description never describes the config shape, what success looks like, or how the resulting draft relates to save_booking_draft/get_booking_draft. An agent knows the tool exists but not how to call it correctly.

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 0% across 3 required parameters, and the description supplies no parameter meaning at all. The critical gap is 'config', a nested object with no declared properties and additionalProperties=true — the only hint the description gives is the vague phrase 'services and availability', which is far short of what is needed.

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 verb 'Draft' plus the resource (services and availability for an existing website) gives a rough idea, but 'Draft confirmed services and availability' is abstract and never says what a 'booking draft' actually is. It does not distinguish itself from sibling save_booking_draft or create_store_draft, leaving the agent to infer the division of labour.

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 precondition 'for an existing website' and the scope exclusions ('No publishing, subscription activation or email') imply when this tool applies, and 'Do not invent service durations or business hours' constrains input. However, no alternative is named, so there is no guidance on create_booking_draft vs save_booking_draft or vs create_website.

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