delete_seat_offering

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

Annotations already carry readOnlyHint=false, destructiveHint=true, and idempotentHint=true, and the description aligns with and substantially extends them. It discloses permanent destruction ('no undo from this server'), async continuation after the initial response, server-side auth injection, throttling under the 30-per-10s cap, retry on 429/5xx, and per-status-code error semantics — exactly the behavioral context the annotations alone do not provide.

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 long but deliberately structured with labeled sections (Behavior, Returns, Use when) and a front-loaded destructive warning. Nearly every sentence carries operational value for a destructive, asynchronous, rate-limited call; the error-code enumeration is slightly verbose but aids agent-side error diagnosis.

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?

With no output schema present, the description correctly compensates by disclosing success status codes, empty-on-success body, and how non-2xx replies surface as tool errors. For a one-parameter destructive tool, it covers prerequisites (user confirmation), auth model, rate limits, retry policy, alternatives, and related tools — nothing an agent needs to invoke it correctly is missing.

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 100%, so the id parameter is fully documented in the schema itself. The description only restates that the record is 'identified by its unique ID,' adding no format, syntax, or constraint detail beyond the schema. Baseline 3 is appropriate when the schema carries the full load.

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 uses specific action verbs ('Deletes', 'removes') with an explicit resource ('specific seat offering') and scope ('identified by its unique ID'), and discloses the asynchronous execution mode. It clearly distinguishes from siblings by naming update_seat_offering and remove_user_seat as different operations, so an agent can disambiguate without opening other tool definitions.

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?

Contains an explicit 'Use when' clause with a hard gate ('only after the user confirms the removal'), plus an explicit exclusion condition ('To merely revoke access or deactivate, use the matching update or unenroll tool instead'). It also lists the related multi-seat sibling tools, giving the agent concrete routing alternatives.

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