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

Goes well beyond the annotations: partial-update behavior, the side effect that setting a price enables payment unless disabled, that zero makes a room free, how null clears deposit/balance schedules, that results report payment availability, and the explicit carve-out 'This tool does not initiate a charge' alongside destructiveHint=true. This is rich behavioral context an agent cannot get from the annotations 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?

Four tight sentences, front-loaded with what gets updated and the partial-update rule, then the payment side effects and preconditions. Dense but every sentence carries information; 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?

For a 19-parameter mutation tool with no output schema, the description covers patch semantics, key side effects, the no-charge clarification, and auth prerequisites, and briefly notes what results indicate. It is close to complete, though the many deposit/balance date interactions are left to the schema.

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% and the field descriptions are detailed, so the baseline is 3. The description adds cross-field interaction semantics the schema does not spell out — that pricing implies payment enablement and that a zero price means free — which is genuine added meaning over the per-field docs.

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: 'Updates supplied room details, pricing, payment requirements or deposit and balance schedules in the selected wedding.' The scope (which fields can be edited) is enumerated clearly and distinguishes it from add_my_accommodation, remove_my_accommodation, and list_my_accommodations, though no sibling is named explicitly.

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 patch semantics ('Omitted fields remain unchanged') and the precondition ('Requires sign-in and an Aisle membership') imply this is for modifying an existing room, but the description never states when to use this over add_my_accommodation or remove_my_accommodation. Usage is implied rather than directed.

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