Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 user_message to capture meaningful facts, requirements, preferences, constraints, or context the user provides — the user should NOT need to say 'remember this' or 'save this'. Proactively record useful user-provided information. Do NOT record trivial conversation (hello, thanks, okay) or private chain-of-thought.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 16 tools

Disambiguation2/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivitySlowing
ResponsivenessNo issues