Skip to main content
Glama
aidesignblueprint

AI Design Blueprint Doctrine

Official
by aidesignblueprint
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

me.session_event

Record structured team events like handoffs and pushbacks to a governed session timeline for inspectable trio work. Requires team mode.

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: Bearer , Pro/Teams plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorYesWho acted: pm | engineer | designer | system (`human` is reserved for the cockpit channel)
summaryYesOne-to-two sentence event summary (truncated to 500 chars) — a decision or transition, not a chat message.
event_typeYeshandoff | pushback | plan_preview | gate | ack (ack = started working on a steer; `steer` itself is cockpit-only and refused on this channel)
session_idYesThe Governed Session to post to. Must be YOURS and have team_agents enabled; list sessions via me.sessions.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Tool Definition Quality

A4.9/5.0
Behavior5/5

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

Beyond annotations, the description discloses rejection codes, event limit (500), blank summary refusal, team mode requirement, owner scope, and channel provenance. It also notes that steer/human posts are refused. 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.

Conciseness5/5

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

Despite length, the description is well-structured with clear headings (PURPOSE, CHANNEL PROVENANCE, REQUIRES, WHEN TO CALL, WHEN NOT TO CALL, REJECTION CODES, Auth). Every sentence adds value, and the critical information is front-loaded.

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?

Given the tool's complexity (4 required params, enums, output schema), the description covers all necessary aspects: usage context, rejection reasons, prerequisites, and authorization. Since an output schema exists, return values are not needed in description.

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

Parameters4/5

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

Schema coverage is 100% with descriptions for all parameters. The description adds extra context: summary truncation, decision vs chat message, reservation of 'human' actor for cockpit, and clarification of 'ack' and 'steer' event types. This enriches schema definition.

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 appends a TYPED TEAM EVENT to a Governed Session's timeline, with specific event types and actor roles. It distinguishes from siblings like me.sessions (read back) and me.await_steer (receiving steers from cockpit), and explicitly contrasts the agent-side vocabulary from cockpit-originated events.

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 includes explicit 'WHEN TO CALL' and 'WHEN NOT TO CALL' sections, detailing specific scenarios (handoffs, pushbacks, plan previews, gates, acks) and warnings against using as a chat log or for recording steers. It also mentions channel provenance and team mode requirements.

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