Skip to main content
Glama
0Mattias
by 0Mattias

episode_handoff

Retrieve the most recent journal takeaways from a prior session to get context on what the last session concluded, without needing a memory search.

Instructions

Read the most-recent journal takeaways from a prior session in this worktree. Call this FIRST at a /loop iteration entry — it answers 'what did the last session conclude here?' without needing memory_search. Episodes are the sibling-to-memory primitive for journal-shaped writes (see episode_write).

When prior_session_id is omitted the handler auto-resolves it — the most-recent event-log session_id other than this process's own — under two implicit filters that mirror the opt-out cascade memory_search / memory_list honor: caller-worktree strict equality (None matches only None, so sibling worktrees stay isolated) and the disabled_scopes cascade (a session whose only takeaways are scope-disabled is skipped; surviving episodes are scope-filtered). Pass it explicitly to override (e.g. a child agent's parent id).

Returns a dict:

  • prior_session_id: the resolved session id, or None when no prior session exists in the log.

  • episodes: list of {id, created, takeaway, body, scopes} dicts, oldest first, capped at max_episodes (default 5, cap 50); each surfaces the writer's takeaway plus the full body.

  • note (optional str): set ONLY when the immediately-prior worktree session left nothing visible; names the cause — floor-only, zero-episode, promoted-out, or all-scope-hidden. The last two DID journal, so a note never means 'wrote no journal'. episodes MAY be non-empty — the walk rewinds to an older takeaway.

For ad-hoc lookup of an older session's journal, prefer episode_search with an explicit parent_session_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_episodesNo
prior_session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description bears full responsibility. It discloses auto-resolution logic, implicit filters (worktree equality, disabled_scopes cascade), return structure, note semantics (including that note never means 'wrote no journal'), and episode ordering/cap. This goes far beyond a simple 'read' statement and covers edge cases.

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?

Long but purposeful; front-loaded with the primary action, then structured details on parameters, return values, and alternatives. Every sentence adds detail needed to use the tool safely. No fluff.

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?

The tool has complex behavior with two parameters, an output schema, and no annotations. The description covers purpose, usage, return contract, and edge cases. It is self-sufficient for correct invocation and interpretation.

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?

Input schema has zero descriptions for its two parameters. The description explains max_episodes (default 5, cap 50) and prior_session_id (auto-resolve behavior, override use case). This compensates fully for schema gaps.

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+resource+scope: 'Read the most-recent journal takeaways from a prior session in this worktree.' It distinguishes itself from siblings by referencing episode_search and memory_search as alternatives, and by positioning itself as the episode counterpart to memory. This is a clear, non-tautological statement.

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?

Explicitly directs to 'Call this FIRST at a /loop iteration entry' and contrasts with memory_search. Provides when-not: 'For ad-hoc lookup of an older session's journal, prefer episode_search with an explicit parent_session_id.' Also explains when to pass prior_session_id explicitly. Comprehensive usage guidance.

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/0Mattias/bettermemory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server