synapse-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAI_MODEL | No | Model name for the OpenAI-compatible LLM provider. | gpt-4o-mini |
| SYNAPSE_MODEL | No | Optional dedicated Synapse endpoint override model name. | |
| OPENAI_API_KEY | No | API key for the OpenAI-compatible LLM provider. May be left blank for local runners such as Ollama or vLLM. | |
| OPENAI_BASE_URL | No | Base URL for any OpenAI-compatible LLM provider (OpenAI, Ollama, vLLM, Groq, etc.). | https://api.openai.com/v1 |
| SYNAPSE_API_KEY | No | Optional dedicated Synapse endpoint override API key. | |
| SYNAPSE_DB_PATH | No | SQLite database location. For the MCP server, defaults to ~/.synapse/synapse.db so all assistants share the same memory pool; set this to isolate memory per project. | ./data/synapse.db |
| SYNAPSE_BASE_URL | No | Optional dedicated Synapse endpoint override for the LLM base URL. | |
| SYNAPSE_VAULT_PATH | No | Optional Markdown knowledge base / vault path. | ./vault |
| SYNAPSE_TOKEN_BUDGET | No | Context packing token budget for recall results. | 250 |
| OPENAI_EMBEDDING_MODEL | No | Optional OpenAI-compatible embedding model to use for semantic search instead of the default zero-dependency subword vectorizer or sentence-transformers. | |
| SYNAPSE_EMBEDDING_MODEL | No | Optional embedding model override when using sentence-transformers. | all-MiniLM-L6-v2 |
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 |
|---|---|
| synapse_recallA | Recall memories, SOPs, and past architectural decisions from Synapse Memory Engine using hybrid semantic vector and BM25 search. |
| synapse_retainB | Save an atomic fact, architectural decision, permanent directive, or SOP into Synapse Memory. |
| synapse_record_episodeC | Record an episodic learning memory (Situation -> Action -> Outcome -> Lesson) so agents never repeat past mistakes. |
| synapse_get_statsA | Get real-time statistics and node counts of the Synapse memory cortex. |
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 4 tools
The read/write split is clear: synapse_recall and synapse_get_stats are retrieval, while synapse_retain and synapse_record_episode are storage. synapse_retain and synapse_record_episode both write memories, which could be confused, but the descriptions distinguish atomic facts/SOPs from structured Situation-Action-Outcome-Lesson episodes.
All tools share the synapse_ namespace prefix and use verb-based names, giving a predictable pattern. Minor deviation: recall and retain are bare verbs while record_episode and get_stats use verb_noun form, but the set still reads consistently.
Four tools is a tight, focused surface for a memory engine, and each one has a distinct role (store fact, store episode, recall, stats). It sits at the low end of the comfortable range, with room for lifecycle operations without feeling padded.
Core workflows (store and retrieve memories, check stats) are covered, but the lifecycle is incomplete: there is no update/edit, delete/forget, or list/enumerate operation. For a persistent memory system, the inability to correct or remove outdated facts or SOPs is a notable gap.