Session Memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_sessionA | Start or resume Session Memory tracking for the current project. Call this AUTOMATICALLY at the beginning of meaningful project work (e.g., 'Continue implementing auth', 'Fix the tests', 'Work on the API'). After starting, immediately call get_context to load previous project state. Do NOT start sessions for trivial questions like 'What does this function do?' |
| end_sessionA | Finalize the current work session. Call after recording unfinished TODOs and creating a final checkpoint. Previously recorded events are already durable; this operation finalizes the session for clean handoff to the next AI. |
| get_active_sessionB | Get information about the currently active session. |
| append_eventA | Record an important event that future AI sessions may need. Use during work for meaningful decisions, bugs, test results, TODOs, discoveries, commands, or state changes. Use |
| log_activityA | Record an important activity during work. Use for: decisions (architecture/implementation choices), bugs (issues discovered), todos (unfinished work), commands (significant commands run), test_result (test outcomes), error (errors encountered). Record outcomes, not reasoning. Be specific: 'Use PKCE for OAuth' not 'Made a decision'. |
| log_file_changeA | Record a significant file change after the change is actually made. Include the path, what changed, and why. Do not log every temporary edit. Example: 'src/auth.py modified - Added refresh token validation before issuing new access token.' |
| resolve_todoA | Mark a previously recorded TODO as resolved after the work has been completed. Use this when an open task from get_context has been finished. Resolved TODOs remain in history but no longer appear under Open Tasks. |
| checkpoint_sessionA | Create a recovery snapshot of the current work state. Call after meaningful milestones, before ending work, or before switching to another major task. Include enough state (goal, current_state, next_action) that a fresh AI could continue from this point without needing the full conversation history. |
| get_contextA | Retrieve continuation context from previous sessions for the current project. Call this IMMEDIATELY after start_session and BEFORE making significant changes. Use the returned goal, current state, decisions, bugs, TODOs, files changed, and next recommended action to continue previous work correctly. This is the most important tool for cross-session continuity. NOTE: This returns selective/compact context. If specific information is not found here, use search_memory() for durable facts or search_history() for detailed historical events. |
| rememberA | Store a long-term memory with provenance. Memories persist across sessions and can be retrieved later. |
| update_memoryC | Update an existing memory's content or status. |
| search_memoryA | Search durable project knowledge and previous important decisions. Use when reasoning depends on why a previous architectural or implementation decision was made, or to find long-term project facts, conventions, and user preferences. Call this when get_context() does not contain the needed information. |
| get_sessionA | Retrieve a session by ID with its events and checkpoint. |
| list_sessionsB | List recent sessions. |
| recover_sessionB | Recover an abandoned or crashed session. |
| search_historyA | Search exact historical session events when current context does not contain enough detail. Use for questions about previous commands, errors, file changes, test results, bugs, user-provided information, or historical actions. Returns raw events from past sessions. Call this when get_context() and search_memory() do not contain the needed information. Different from search_memory which searches curated long-term knowledge. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
append_event and log_activity are near-duplicates, both recording important events/activities with overlapping examples like decisions, bugs, TODOs, and test results; remember also blurs into append_event's territory. The retrieval tools are well-differentiated, but these boundary issues create real misselection risk.
Nearly every tool follows a clean snake_case verb_noun pattern such as start_session, search_memory, and list_sessions. The single-verb 'remember' is the main deviation, and append_event/log_activity are synonymous in style, but the overall convention is consistent.
16 tools is at the heavy end for a session-memory server, especially with redundant event-recording tools like append_event and log_activity. Each cluster has a purpose, but consolidating the overlapping logging tools would make the set tighter.
The surface covers the full session lifecycle, event and file-change logging, TODO resolution, memory storage/update/search, and context/history retrieval. Minor omissions like explicit memory deletion are workaroundable, so agents should not hit major dead ends.