AI Design Blueprint

Official

Overview Schema Source Related Servers Discussions Admin

me.await_steer

Read-onlyIdempotent

Wait for the next steer event from the session owner on a governed team session, then return the instruction for execution.

Instructions

Pro/Teams. BLOCK until the session owner posts the next steer event to a Governed Session from the AIDB Studio cockpit, then return it. DELIVERY GUARANTEE: the durable cursor read against the session log is authoritative (at-least-once: a lost response is safely re-issuable with the same cursor, and timed_out is only returned after a final confirming read). The in-between wake-up is a best-effort in-process push: usually sub-second, but a steer is never lost if a wake-up is missed; the confirming read catches it. See the after_event_id and timeout_s parameter descriptions for the semantics. THE LOOP: finish a task -> post me.session_event handoff -> call me.await_steer -> on a steer, FIRST post me.session_event event_type=ack ('Started: '), then execute, then handoff, then call me.await_steer again; on timed_out, call again with the returned after_event_id. REQUIRES team mode on the session (toggled by the owner in the web app); owner-scoped, so foreign session ids read as not found. Read-only: this tool never writes events. REJECTION CODES (invalid_request): 'Session not found.' (not yours, or no such id); 'Team mode is off for this session.' (owner enables it on the session page). Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan.

Input Schema

TableJSON Schema

Name	Required	Description
`timeout_s`	No	Seconds to wait before returning timed_out. Clamped to 5-240, DEFAULT 45: safe under Claude Code's 60-second first-response-byte timer for HTTP servers. Longer waits require the per-server timeout raised in the MCP client config (e.g. "timeout": 300000 in .mcp.json).
`session_id`	Yes	The Governed Session to watch. Must be YOURS and have team_agents enabled; list sessions via me.sessions.
`after_event_id`	No	Cursor: highest session-event id you have already seen (0 = deliver any existing steer). Pass the value from your previous await_steer result or me.sessions read. Non-destructive at-least-once delivery: re-calling with the same cursor returns the same steers again, so a lost response never loses a steer.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.2.0Jul 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already mark it read-only and idempotent, and the description goes beyond them with blocking semantics, at-least-once cursor delivery, best-effort wake-up, final confirming read before timed_out, rejection codes, and auth requirements. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is long but carefully structured with labeled sections (THE LOOP, DELIVERY GUARANTEE, REJECTION CODES, Auth) and front-loads the blocking behavior. Minor redundancy exists between the opener's 'Pro/Teams' and the later Auth line, keeping it from a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a blocking, cursor-based polling tool, the description covers usage protocol, failure modes, delivery semantics, prerequisites, and auth. The existing output schema relieves it from describing return values, so nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter descriptions already document timeout clamping, cursor semantics, and session ownership. The description mostly refers the agent to those descriptions and adds only marginal behavior such as 'foreign session ids read as not found,' so it stays at the high-coverage baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a precise verb and resource: 'BLOCK until the session owner posts the next steer event to a Governed Session ... then return it.' This clearly differentiates await_steer from siblings like me.session_event (writes events) and me.sessions (lists sessions).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit end-to-end loop (handoff -> await_steer -> ack -> execute -> handoff), retry behavior on timed_out, and preconditions such as team mode, owner scoping, and plan entitlement. This is stronger than merely naming a usage context.

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