shared-memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VOYAGE_API_KEY | No | Voyage AI API key. Alternative to EMBEDDING_API_KEY when EMBEDDING_PROVIDER=voyage. | |
| EMBEDDING_MODEL | No | Embedding model id. Defaults to a local MiniLM multilingual model, or voyage-4 for Voyage AI. | |
| SHARED_MEMORY_DB | No | SQLite database file. | ./memory.sqlite |
| EMBEDDING_API_KEY | No | API key for a remote embedding provider. Required for openai_compatible and voyage providers. | |
| SHARED_MEMORY_ENV | No | Location of the env file. | ./embedding.env |
| EMBEDDING_BASE_URL | No | Base URL for a remote OpenAI-compatible /v1/embeddings endpoint. Required when EMBEDDING_PROVIDER=openai_compatible. | |
| EMBEDDING_PROVIDER | No | Embedding provider: local (fastembed), openai_compatible, or voyage. | local |
| SHARED_MEMORY_HOME | No | Moves both the config directory and data directory. | |
| EMBEDDING_COLLECTION | No | Collection name (display only on SQLite). | shared_memory |
| SHARED_MEMORY_BACKEND | No | Storage backend: sqlite or chroma. | sqlite |
| SHARED_MEMORY_DATA_DIR | No | ChromaDB persistence directory. | ./chroma_data |
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 | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| memory_searchC | Semantic search across shared memory. |
| memory_addC | Add an ad-hoc memory chunk. Returns the generated id. |
| memory_updateA | Update an existing memory chunk in place; the id is kept. Keeping the id means references to it stay valid. An unknown id raises, so a typo never silently turns into a new chunk. |
| memory_forgetA | Delete memory chunks by explicit ids or by agent/source filter. Deletion is irreversible, so there are two safety catches: dry_run is on by default, and deleting by filter requires expect_count equal to the number of matches, so an over-broad filter cannot wipe the collection by mistake. A call with no ids and no filters is refused. |
| memory_statsA | Return collection statistics: total count, breakdown by agent/source. |
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 5 tools
Each tool maps to a distinct lifecycle operation on a single resource: add, search, update, forget, stats. There is no meaningful overlap — search retrieves, stats aggregates, and the write operations are cleanly separated.
All five tools follow a strict memory_<verb> snake_case pattern with clear, conventional verbs (add, search, update, forget, stats). No mixed conventions or vague names.
Five tools is a tight, well-scoped surface for a memory store: write, read, mutate, delete, and observe. Every tool earns its place with no redundancy or filler.
The set covers the full CRUD lifecycle plus stats, and search likely substitutes for a direct get-by-id. Minor gaps remain around bulk operations and explicit id-based retrieval, but core workflows are covered without dead ends.