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

Even with annotations already declaring readOnlyHint, idempotentHint, and destructiveHint, the description adds substantial behavioral detail: blocking long-poll, at-least-once durable cursor delivery, best-effort in-process wake-up, timed_out only after a confirming read, and explicit 'never writes events'. This is consistent with and extends the annotations.

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 and uses heavy formatting (caps, sections), but it is structured into deliverable pieces: purpose, delivery guarantee, loop, requirements, rejection codes, auth. Nearly every sentence carries unique information, and the key action is front-loaded in the first sentence, though it could be tightened.

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 the tool's interaction complexity, the description covers all operational aspects: blocking semantics, delivery guarantee, loop sequence, team-mode requirement, owner scoping, rejection codes, auth plan, and read-only nature. An output schema exists to cover return values, so nothing essential 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% and the parameter descriptions are already rich (timeout clamping, cursor semantics, ownership). The description adds value beyond the schema by specifying the loop usage—re-calling with the returned after_event_id on timed_out—and by pointing to the parameter descriptions for the authoritative semantics, so an agent has a complete picture.

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?

Description opens with a specific verb and resource: 'BLOCK until the session owner posts the next steer event to a Governed Session from AIDB Studio, then return it.' It clearly differentiates from siblings like me.session_event (posting events) and me.sessions (listing sessions) by defining its exact role as the waiting/reading counterpart in the handoff loop.

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?

Provides an explicit 'THE LOOP' section that tells exactly when to call the tool: after posting a handoff via me.session_event, on every received steer, and again after timed_out with the returned cursor. It also states requirements (team mode, owner scope) and lists rejection codes, so an agent knows both when and when not to use it.

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