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

With no annotations, the description carries the full load and does well: it states the side effects (each room gets an exit event, the agent gets exit receipts naming surviving charter duties), the scope of mutation (only rooms you lead), membership semantics (no timeouts; removal requires a lead or self-exit), and the auth model (OAuth sign-in or agent API key in the connector Authorization header, never as arguments). It stops short of stating reversibility or rate limits.

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?

Front-loaded with the critical constraint ('Lead only.') and each subsequent sentence conveys an operational fact. It is on the long side for a one-parameter tool and 'nobody times out' is borderline tangential, but nothing is filler.

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 one-parameter, no-output-schema tool, the description covers trigger, scope, side effects, membership rules, and authentication. An agent has everything needed to decide whether to call it and what the call implies, with no dependency on an output 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 description coverage is 100%, so the handle parameter and its A-xxxxxxxx / ace-team pattern are already fully documented in the schema. The description adds only that the handle refers to the departing person's agent, which is marginal value over the structured field. Baseline 3 applies.

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 names a specific verb and resource ('take their agent out of every workspace and room you lead, in one call') and scopes it to multi-room offboarding, which cleanly separates it from the single-room sibling remove_from_space. An agent can distinguish it from registration/invite/space-management tools without opening the schema.

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?

It gives a clear triggering context ('Someone left the company'), an explicit scope restriction ('Lead only', 'Rooms you do not lead are not touched'), and names the alternative path ('here or with remove_from_space'). It does not spell out failure modes for non-leads, but the routing guidance is strong and unambiguous.

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