Skip to main content
Glama
Pseudogiant-xr

PseudoLife-MCP

Official

memory_episode_start

Open a named sub-episode to group related memories under the current session, tagging them for episode-scoped search. Close it later to return to the parent episode.

Instructions

Open a named sub-episode; it nests under the session episode, and memories stored while it is open carry its id + title for episode-scoped search. memory_episode_end closes it and pops back.

Input Schema

NameRequiredDescriptionDefault
hintNoOptional note on what the task is about.
titleYesShort name for the task, used in later recaps.
episodeNoYour session handle (from the session-start briefing) — anchors the sub-episode to YOUR session when several run concurrently.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.18.1
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed3 schema fields changedv0.15.0
    • addedInput schema / properties / episode
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Your session handle (from the session-start briefing) — anchors the sub-episode to YOUR session when several run concurrently.",
      +  "title": "Episode"
      +}
    • addedInput schema / properties / hint / description
      Added value: +"Optional note on what the task is about."
    • addedInput schema / properties / title / description
      Added value: +"Short name for the task, used in later recaps."
  3. First observedv0.11.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations declare non-readonly, non-idempotent, non-destructive, but the description adds genuine behavioral context beyond them: the sub-episode nests under the session episode, memories written while open are tagged with its id and title, and end pops back to the parent. What it does not clarify is what repeated starts do or whether state persists across calls.

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?

Two sentences, front-loaded with the action and then the consequence and pair-tool. The only blemish is the awkward mid-sentence line wrapping in the source text; content-wise there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the description covers the lifecycle (start/end), the nesting model, and the memory-tagging effect. It is nearly complete for a state-mutating episode tool, missing only edge-case behavior on repeated starts or when a session handle is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so title, hint, and episode are already documented in the schema; the description only reinforces 'named' and the title's role in recaps/episode-scoped search. It adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 ('Open') and resource ('named sub-episode') and immediately explains the nesting relationship and its effect on subsequently stored memories. It also names the paired sibling memory_episode_end, so an agent can distinguish it from the closing tool without opening the schema.

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

Usage Guidelines3/5

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

Usage is implied by the effect statement ('memories stored while it is open carry its id + title for episode-scoped search') and by naming memory_episode_end as the closer, but there is no explicit 'use this when / not when' guidance or discussion of alternatives for scoping memories.

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