Skip to main content
Glama

brain_session_relay

DestructiveIdempotent

Relay an open agent session in brain-v42 to its slot or project base: capture knowledge, write a handover, end the old session, and open a successor.

Instructions

Relay an open session onto its slot, or its project base: capture, end, restart.

One transaction: the named knowledge_ids are captured into the old session, the handover is written under a compare-and-swap, the old session ends, and a successor opens under new_client_key; its briefing follows. Two forms, and exactly one revision per call.

briefing defaults to full detail; compact returns counts and IDs in at most 4,000 characters. Focus text appears only in session.started_focus.

Bound session: send expected_slot_revision; the handover (at most 4,000 characters) REPLACES the whole slot body and the successor stays on the slot. A closed slot or a stale revision changes nothing and leaves the session open.

Unbound session: send expected_focus_revision, the BASE revision; the handover becomes the project's whole base focus and the successor is unbound. A stale revision (focus_revision_conflict) changes nothing and leaves the session open, unlike end, which closes anyway. SHRINK GUARD: a handover under 70% of the current base focus is refused (base_focus_shrink, both lengths in the message), because it REPLACES the whole base: carry the durable content over. An operator relay may pass allow_focus_shrink = true only with an active /brain-admin elevation for this credential and MCP connection; a guard mod never can.

The same 70% guard applies to a bound slot body (slot_focus_shrink). The override is enforced before mutation: only initiator='operator' can pass it, and only with an active /brain-admin elevation for this credential and MCP connection. A guard_mod relay is refused even if elevated.

An equal replay returns the same successor with replayed = true; any other payload on an ended session is terminal_conflict. The successor's next end or relay sends result.slot.revision (bound: the SLOT revision, from bind, resume, or relay) or result.focus_revision (unbound: the new BASE revision), never started_focus_revision for a bound one.

A guard mod the operator explicitly enabled may make this call as a standing user command, and only this one (Amendment โ€” slot relay (ADR #34)); with initiator = 'guard_mod' it is refused while BRAIN_SESSION_RELAY_GUARD_MOD_ENABLED is false.

An agent tracer is the only session the server opens or closes on its own; no hook and no auto-close may invoke this lifecycle boundary.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>",
      "expected_client_key": "<expected_client_key>",
      "summary": "<summary>",
      "handover": "<handover>",
      "new_client_key": "<new_client_key>",
      "initiator": "<initiator>"
    },
    "name": "brain_session_relay"
  }
}

Input Schema

NameRequiredDescriptionDefault
summaryYes
briefingNofull
handoverYesREPLACES the whole project base focus for an unbound session, or the whole slot body for a bound session. A replacement under 70% of the current length is refused (`base_focus_shrink` or `slot_focus_shrink`), leaving the session open. Carry all durable content forward. The override is operator-only: an elevated /brain-admin session may override on end, or a relay with initiator='operator' may pass allow_focus_shrink=true. A guard_mod relay cannot override, even with elevation.
initiatorYes
session_idYes
knowledge_idsNo
new_client_keyYesStable identity for one intended session. Reuse it for every retry of that session; use a distinct stable key for each parallel session.
allow_focus_shrinkNoOperator-only override of the 70% guard for the whole base focus or slot body. Requires an active /brain-admin elevation for this credential and MCP connection; guard_mod is refused in code, even with elevation.
expected_client_keyYesClient identity expected for the addressed session UUID. The pair must match before any session mutation. This is an isolation guard, not authentication.
expected_slot_revisionNo
expected_focus_revisionNo
nothing_to_capture_reasonNo

Output Schema

NameRequiredDescriptionDefault
slotNo
sessionYesPersistent state of one explicitly controlled concurrent session.
briefingNo
replayedYes
focus_revisionNo
ended_session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.3
    • addedInput schema / properties / briefing
      Added value: +{
      +  "default": "full",
      +  "enum": [
      +    "full",
      +    "compact"
      +  ],
      +  "type": "string"
      +}
  2. Changed2 schema fields changedv0.7.0
    • addedInput schema / properties / allow_focus_shrink / description
      Added value: +"Operator-only override of the 70% guard for the whole base focus or slot body. Requires an active /brain-admin elevation for this credential and MCP connection; guard_mod is refused in code, even with elevation."
    • addedInput schema / properties / handover / description
      Added value: +"REPLACES the whole project base focus for an unbound session, or the whole slot body for a bound session. A replacement under 70% of the current length is refused (`base_focus_shrink` or `slot_focus_shrink`), leaving the session open. Carry all durable content forward. The override is operator-only: an elevated /brain-admin session may override on end, or a relay with initiator='operator' may pass allow_focus_shrink=true. A guard_mod relay cannot override, even with elevation."
  3. Addedv0.6.7

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, and the description corroborates and enriches all three: the handover REPLACES the whole slot body/base, equal replay yields `replayed=true`, and it discloses error names, CAS semantics, the 70% shrink guard, env-var gating, and elevation requirements. It adds substantial behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The purpose is front-loaded but the body is dense and repetitive, restating the operator-only /brain-admin override rule in two separate paragraphs. For a 12-parameter lifecycle tool the length is defensible, but the redundancy costs conciseness.

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 an output schema is present, the description needn't document return values, and it still explains replay and conflict outcomes. Between the description, schema, and annotations, an agent has the CAS, permission, and guard behavior needed to call this correctly.

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?

With only 33% schema description coverage, the description carries the load: it defines `handover` replacement semantics (max 4,000 chars), the distinction between `expected_slot_revision` and the BASE `expected_focus_revision`, `allow_focus_shrink` operator-only behavior, and `briefing` full vs compact. It omits meaning for `summary` and `nothing_to_capture_reason`, so it does not fully compensate for the coverage gap.

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?

States a specific verb+resource (relay a session onto its slot or project base) and enumerates the composite effect: capture, end, restart. It explicitly differentiates from siblings, e.g. contrasting its stale-revision behavior with `end` and noting the capture of `knowledge_ids`, so an agent can place it against brain_session_end/brain_session_capture without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly splits the two forms and the condition selecting each: bound sessions send `expected_slot_revision`, unbound send `expected_focus_revision`. It also names the guard_mod/operator gating condition. It lacks a crisp top-level 'use relay instead of capture+end+start when...' statement, so usage is well-contextualized but not framed as an explicit choice against all alternatives.

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