Skip to main content
Glama
aidesignblueprint

AI Design Blueprint Doctrine

Official
by aidesignblueprint
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

me.await_steer

Read-onlyIdempotent

Wait for the session owner to post a steer event in a governed session, then return it. Use in a loop to coordinate task 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: Bearer , Pro/Teams plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeout_sNoSeconds 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_idYesThe Governed Session to watch. Must be YOURS and have team_agents enabled; list sessions via me.sessions.
after_event_idNoCursor: 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
NameRequiredDescriptionDefault

No arguments

Tool Definition Quality

A4.8/5.0
Behavior5/5

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

Discloses behavioral traits beyond annotations: read-only nature, idempotent delivery (at-least-once), wake-up mechanism, and that timed_out is only returned after confirming read. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint all align).

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?

Description is long but well-structured with labeled sections (DELIVERY GUARANTEE, THE LOOP, REQUIRES, REJECTION CODES). Each sentence adds necessary detail for correct usage. Could be slightly shorter, but complexity justifies length.

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

Completeness4/5

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

Covers core loop, error cases, delivery guarantees, and parameter semantics. With output schema present, return values need not be described. Addresses prerequisites (team mode, ownership). Lacks examples of output or edge cases, but overall sufficient for a complex tool.

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

Parameters5/5

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

Schema coverage is 100%, but description adds substantial value: explains timeout default relative to Claude Code timer, session_id ownership and team mode requirement, after_event_id cursor semantics with at-least-once delivery and re-issuability. Adds context not in schema.

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?

The description clearly states the tool blocks until the next steer event and returns it. It uses specific verbs ('BLOCK', 'await', 'return') and distinguishes itself as read-only and owner-scoped. Sibling tools like me.session_event or me.sessions serve different functions, so purpose is well-defined.

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 explicit guidance: REQUIRES team mode, owner-scoped, explains loop pattern (handoff -> await_steer -> ack -> execute -> handoff -> await_steer again). Includes when to use on timed_out and how to reuse cursor. Mentions alternative for listing sessions (me.sessions). Also specifies rejection codes.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aidesignblueprint/integrations'

If you have feedback or need assistance with the MCP directory API, please join our Discord server