Skip to main content
Glama

AI Design Blueprint

by com.aidesignblueprint
OverviewDiscussionsAdmin

Post a Team Event to a Governed Session

me.session_event

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 AIDB Studio-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 AIDB Studio 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 AIDB Studio. Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorYesWho acted: pm | engineer | designer | system (`human` is reserved for AIDB Studio)
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 AIDB Studio-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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / summary / description
      Previous value: -"One-to-two sentence event summary (truncated to 500 chars) — a decision or transition, not a chat message."New value: +"One-to-two sentence event summary (truncated to 500 chars): a decision or transition, not a chat message."
  2. Changed2 schema fields changed
    • changedInput schema / properties / actor / description
      Previous value: -"Who acted: pm | engineer | designer | system (`human` is reserved for the cockpit channel)"New value: +"Who acted: pm | engineer | designer | system (`human` is reserved for AIDB Studio)"
    • changedInput schema / properties / event_type / description
      Previous value: -"handoff | pushback | plan_preview | gate | ack (ack = started working on a steer; `steer` itself is cockpit-only and refused on this channel)"New value: +"handoff | pushback | plan_preview | gate | ack (ack = started working on a steer; `steer` itself is AIDB Studio-only and refused on this channel)"
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only mark mutating, non-idempotent, non-destructive behavior; the description adds substantial constraints: channel provenance refusing steer/human, team-mode requirement, owner-scoping, 500-event limit, blank-summary refusal, and durable channel stamping. It also states auth plan 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 description is long but densely structured with labeled sections (CHANNEL PROVENANCE, REQUIRES, WHEN TO CALL, WHEN NOT TO CALL, REJECTION CODES, Auth), and the core purpose is front-loaded. A few phrases are redundant with the schema, but overall the length is justified by the number of constraints.

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—team-mode gating, channel provenance, error codes, auth, and call-ordering—the description covers prerequisites, exclusions, failure modes, and alternatives. Output schema exists, so return-value documentation is not needed. Nothing essential is missing.

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 already covers 100% of parameters, but the description enriches them: ack semantics ('STARTED working on a steer'), summary truncation to 500 chars and content guidance, session_id ownership/team-mode requirement, and the explicit event_type/actor enumerations. This goes well beyond the 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?

The description opens with a specific verb and resource: 'append a TYPED TEAM EVENT to a Governed Session's timeline (GEP-M6).' It enumerates the event vocabulary and explicitly contrasts with sibling flows by stating that steer events and human actors are refused, so an agent can tell it apart from me.await_steer and me.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?

WHEN TO CALL lists concrete triggers (role handoffs, pushbacks, plan previews, hard gates) and WHEN NOT TO CALL excludes chat logging and steer recording. It names the alternatives (me.await_steer, me.sessions) and gives an ordering rule: post ack first, then execute, then handoff.

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

All AI Design Blueprint toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources