AI Design Blueprint

Official

Overview Schema Source Related Servers Discussions Admin

me.session_event

Post typed team events to a Governed Session timeline so handoffs, pushbacks, plan previews, gates, and acks become inspectable structured decisions.

Instructions

Pro/Teams — append a TYPED TEAM EVENT to a Governed Session's timeline (GEP-M6). This is how the user's own harness makes trio work inspectable: handoffs between role lenses, pushbacks, plan previews, gates, and acks land as structured events next to the validation runs, so the session reads as a system, not a transcript. CHANNEL PROVENANCE: this MCP channel posts the AGENT-SIDE vocabulary only. steer events and actor human are cockpit-originated by contract (the owner posts them from the AIDB Studio session surface) and are REFUSED here, so a timeline entry can never impersonate the human side of the loop. Every event posted here is durably stamped with its channel. REQUIRES team mode: the session must have team_agents enabled (toggled in the web app on the session page); posting to a standalone session is refused so non-team sessions stay byte-identical. Owner-scoped: foreign session ids read as not found. event_type: handoff | pushback | plan_preview | gate | ack. actor: pm | engineer | designer | system. Read events back via me.sessions(session_id=...). WHEN TO CALL: at every role handoff (who -> who, what was passed), when a role pushes back on another's output, when the PM's plan is previewed for the co-planning gate, and when a hard gate blocks on an irreversible side-effect. ack: the IDE agent confirms it STARTED working on a steer. Post it FIRST on receiving a steer (summary like 'Started: '), then execute, then post handoff with the result. WHEN NOT TO CALL: not a chat log: post decisions and transitions, not every message; never to record a steer (steers arrive FROM the cockpit via me.await_steer). 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); 'This session has reached its event limit (500).' (the shared volume brake: start a new session for further team events); 'summary must not be blank.' (empty summaries are refused); steer/human posts are refused with a pointer to the cockpit channel. Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan.

Input Schema

TableJSON Schema

Name	Required	Description
`actor`	Yes	Who acted: pm \| engineer \| designer \| system (`human` is reserved for the cockpit channel)
`summary`	Yes	One-to-two sentence event summary (truncated to 500 chars) — a decision or transition, not a chat message.
`event_type`	Yes	handoff \| pushback \| plan_preview \| gate \| ack (ack = started working on a steer; `steer` itself is cockpit-only and refused on this channel)
`session_id`	Yes	The Governed Session to post to. Must be YOURS and have team_agents enabled; list sessions via me.sessions.

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.9/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the full burden of behavioral disclosure. The description richly discloses mutation behavior, the durable channel stamp, team-mode refusal, owner scoping, the 500-event limit, blank-summary refusal, and auth/plan requirements. It even enumerates exact rejection messages. No contradiction with annotations is present.

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 description is longer than average, but densely packed with actionable sections: channel provenance, requirements, event types, when to call, when not to call, rejection codes, and auth. The structure is clear and front-loaded with the core purpose. Some repetition exists (steer refusal appears multiple times), which costs a bit of conciseness, but every sentence carries real operational value.

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 write tool with sparse annotations and moderate parameter count, this description is complete: it covers prerequisites, permission model, failure modes, exact rejection strings, the sibling read-back path (me.sessions), and the relationship to me.await_steer. The output schema exists, so lack of return-value explanation is not a gap. An agent has everything needed to select and invoke this tool correctly.

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 the description adds meaningful semantics beyond the schema: event_type is tied to specific call scenarios, actor 'human' is explicitly reserved for the cockpit, summary is framed as 'a decision or transition, not a chat message', and session_id must be owned and team-enabled. The description also adds operational guidance like 'List sessions via me.sessions' and 'ack = started working on a steer'. This substantially exceeds the baseline for full schema coverage.

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 opens with a specific verb and resource: 'append a TYPED TEAM EVENT to a Governed Session's timeline'. It clearly distinguishes this tool from siblings by stating it posts the AGENT-SIDE vocabulary only)Skip steer/human events, and explicitly contrasts itself with cockpit-originated channels. An agent can immediately tell what this tool does and what it is not.

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?

The description provides explicit WHEN TO CALL conditions: role handoffs, pushbacks, plan previews, gates, and acks, with a concrete ack workflow ('Post it FIRST on receiving a steer... then execute, then post handoff'). It also gives WHEN NOT TO CALL guidance: not a chat logainer never record a steer, and references the correct alternative (me.await_steer for receiving steers). Sibling routing is unambiguous.

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