Update Luma guest tickets

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

The description goes beyond the annotations by specifying concrete behavioral consequences: adding tickets may exceed capacity, removing tickets invalidates them without refund, and Luma sends in-app notifications even when email is disabled. These details are not present in the annotations (which only indicate destructiveHint=true, readOnlyHint=false, etc.) and give the agent a clearer picture of side effects. No contradictions with annotations are present.

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 description is three sentences long and front-loads the core action ('Preview or add and remove tickets for one guest') before adding essential caveats. Every sentence provides distinct, non-redundant information: the action, the capacity/refund implications, and notification behavior. There is no filler or repetition, making it efficient and easy to parse.

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?

Given that there is no output schema, the description adequately covers the operational context: it explains the two modes (preview vs. actual changes), the nature of add/removal, capacity limits, monetary consequences, and notification behavior. It also mentions the single-guest scope. While it does not cover every edge case (e.g., maxItems limits, which are in the schema) or authentication prerequisites, the core information needed to invoke the tool correctly is present. It falls slightly short of being fully complete due to the absence of guidance on handling partial failures or response expectations, but it is sufficient for most agent use.

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 only 33%, with descriptions available only for guest_id and confirmed. The description compensates by explaining the overall behavior of key parameters: 'added tickets are complimentary administrative tickets and may exceed capacity' clarifies tickets_to_add; 'removed tickets are invalidated without a refund' clarifies ticket_ids_to_remove; and 'sends an in-app notification even when email is disabled' clarifies send_email. This adds meaning beyond the bare schema, though it does not provide per-parameter syntax or constraints (which the schema partially covers). The description effectively bridges the coverage gap.

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 opens with a precise, action-oriented statement: 'Preview or add and remove tickets for one guest.' It names the verb (preview/add/remove), the resource (tickets), and the scope (one guest), making it unambiguous. It also distinguishes itself from sibling tools by focusing specifically on per-guest ticket management, which no sibling addresses. The additional details about complimentary admin tickets clarify the nature of the operation.

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 does not explicitly mention when to use this tool versus alternatives or when not to use it. It implies usage via the 'preview' vs 'apply' distinction (confirmed=false for preview) and clarifies that added tickets are complimentary admin tickets that may exceed capacity, which signals a specific use case. However, it lacks any comparison to sibling tools or exclusion criteria, leaving the agent to infer the appropriate context from the tool name and description.

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