Skip to main content
Glama
0Mattias
by 0Mattias

episode_search

Retrieve past episodes from memory across sessions using filters like scope, time, session, or swarm ID. Returns most recent matches to review conclusions and takeaways.

Instructions

Cross-session lookup for journal-shaped entries (episodes). NOT ranked — episodes are chronological and the filter set (scope / since / session_id) is the discovery surface. For the loop-iteration-entry case prefer episode_handoff, which auto-resolves the prior session and caps the surface.

Returns {id, session_id, created, takeaway, body, scopes, swarm_id} per row, oldest-first inside the most-recent-max_results window: over the cap it keeps the MOST-RECENT N, so 'what did I conclude lately?' reads the tail, not the head. session_id is present because this surface spans sessions (unlike episode_handoff); swarm_id (may be null) is the multi-agent cohort tag — pass a coordinator's session id to gather every sub-agent's takeaways in one read.

WORKTREE SCOPING: by default (auto_scope=True) the bare discovery walk (no swarm_id / parent_session_id) drops episodes whose captured git worktree differs from yours. PERMISSIVE, not a boundary, and weaker than the strict equality episode_handoff applies — it passes an episode through when there is nothing to compare (none captured, or you outside any git checkout), when the recorded worktree is gone from disk, and when you are in a LINKED worktree of the checkout that wrote it, so under agent fan-out the primary checkout's episodes stay visible. An EXPLICIT swarm_id / parent_session_id / ids is never worktree-filtered: naming a cohort or session is deliberate cross-worktree intent.

Parameters (full reference in docs/api.md):

  • scopes (optional): keep only episodes whose scope list intersects this filter.

  • parent_session_id (optional): restrict to one session's directory. Composes with swarm_id to narrow a fan-in.

  • swarm_id (optional): fan-in filter — episodes tagged with this cohort id, across all sessions.

  • since (optional ISO-8601): created at-or-after this instant.

  • auto_scope (default True): worktree-scope the bare walk (see WORKTREE SCOPING). False sweeps every worktree sharing the root.

  • max_results (default 20, cap 200): surfaces the most-recent N.

  • ids (optional): only these episode ULIDs — explicit selector, never worktree-filtered; unknown ids are absent, not an error.

  • include_bodies (default True): False OMITS body — takeaway-only rows. Scan, then re-read one via ids.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsNo
sinceNo
scopesNo
swarm_idNo
auto_scopeNo
max_resultsNo
include_bodiesNo
parent_session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description fully bears the burden of disclosing behavior. It explains ordering (oldest-first within most-recent-N window), max_results overflow behavior (keeps MOST-RECENT N), worktree scoping nuances (permissive, when it passes through), explicit filters never being worktree-filtered, and the effect of `include_bodies`. This is exceptionally transparent.

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?

Although lengthy, the description is densely packed with necessary information. It is structured with clear sections (purpose, return shape, worktree scoping, parameters) and front-loaded with the core purpose. Every sentence adds technical value; there is no fluff or repetition of schema defaults.

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 (8 parameters, no annotations, sibling distinctions) the description is remarkably complete. It covers return shape, ordering, scoping rules, parameter semantics, and alternative tool selection. An agent has everything needed to select and invoke the tool correctly.

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 coverage is 0%, so the description compensates fully. Each of the 8 parameters is explained with its meaning, default, and behavior, including compositional relationships (e.g., `parent_session_id` composes with `swarm_id`) and edge cases (unknown `ids` are absent, not an error). This goes far beyond the raw schema.

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: 'Cross-session lookup for journal-shaped entries (episodes).' It immediately distinguishes itself from sibling tools by noting it is NOT ranked and explicitly contrasts with `episode_handoff` for the loop-iteration case, making its role unambiguous.

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 provides explicit when-to-use guidance: 'For the loop-iteration-entry case prefer `episode_handoff`' and explains cross-session vs. single-session contexts. It also details when to use explicit filters (`swarm_id`, `parent_session_id`, `ids`) to bypass worktree scoping, giving clear decision criteria for alternatives.

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