Skip to main content
Glama

AI Design Blueprint Doctrine

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 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

TDQS

A5/5.0
Behavior5/5

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

Discloses refusal conditions (steer/human posts, team mode off, event limit, blank summary), channel provenance, and owner-scoping. Annotations are minimal and do not contradict.

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?

Well-structured with sections, front-loaded action, and every sentence contributes value without redundancy.

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?

Covers purpose, usage, behavior, parameters, rejection codes, limits, and cross-references to related tools. Highly complete 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 has 100% coverage, but description adds significant meaning: event_type explanations, actor restrictions, summary constraints, and session_id prerequisites.

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, lists event types and actors, and distinguishes from siblings by noting steer events are cockpit-only.

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?

Explicit WHEN TO CALL and WHEN NOT TO CALL sections provide clear guidance, including alternatives like me.await_steer for steers and me.sessions for reading events.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool targets a clearly distinct purpose. For example, architect.validate vs architect.validate_consensus differ in single-shot vs consensus; handoffs.agency, handoffs.operator, and handoffs.partnership are separated by engagement type. No significant overlap.

Naming Consistency4/5

Tools follow a consistent dot-notation grouping (architect.*, clusters.*, examples.*, guides.*, handoffs.*, me.*, principles.*, signals.*, team.*) with predictable verbs (validate, list, get, search, add, etc.). Minor deviation: some underscore within names (e.g., me.add_evidence) but overall pattern holds.

Tool Count4/5

24 tools is on the higher side but justified given the broad domain spanning validation, certification, learning, handoffs, and feedback. Each tool has a clear role, and the count reflects the platform's comprehensive scope without feeling bloated.

Completeness5/5

The tool surface covers the full workflow (validate → consensus → certify), discovery (principles, clusters, examples, guides), personal progress (learning path, coaching, evidence), handoffs (support, partnership, agency), feedback, and team summaries. No obvious gaps for the stated purpose.

Resources