Synap Memory

ai.maximem由 maximem.ai 發布官方發布者v0.1.0更新於 Oct 24, 2026

Persistent memory for AI agents — log and recall conversation context over MCP.

已驗證Streamable HTTP可網頁執行知識與記憶AI 與機器學習

概覽

AI 產生的概覽

託管的 Synap 記憶伺服器，讓助理記錄對話往來並回想已掌握的某位使用者資訊。

可以做什麼
  • 記錄每則使用者訊息與助理回覆，由 Synap 擷取並保存其中重要的內容
  • 在回覆前以使用者最新訊息檢索過往脈絡
  • 列出近期記住的内容，用於除錯或確認記憶是否生效
  • 查詢某次記錄是否處理完成，以及擷取出多少筆記憶
適用情境
適合希望代理跨對話保留終端使用者記憶、又不想自建儲存的情境，尤其是只接受 MCP 網址與權杖的無程式碼平台。B2C 與 B2B 部署下的依使用者回想皆適用。
執行需求
遠端 MCP 端點，無需本機安裝。需要一組 Synap API 金鑰，以 Authorization Bearer 權杖形式送出，可於 Synap 主控台取得。若服務多位終端使用者，記錄與回想時需傳入相同的 user_id；B2B 執行個體另需 customer_id。
安裝前請注意
API 金鑰會轉送至 Synap 後端並代表你的帳戶，應視為機密。記錄會把使用者訊息與助理回覆送往 Synap 並加以儲存與擷取，請勿送出不希望被保留的敏感內容。寫入為非同步；作用域設定錯誤（B2C 執行個體傳 customer_id，或 B2B 執行個體只傳 user_id）會被拒絕或把記憶歸錯人。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Synap Memory，將其新增到工作區。
  2. 連接 Authorization token 憑證。它們會被私密儲存，絕不會在公開頁面上展示。
  3. 為需要使用其工具的對話啟用該服務。

Web executable，透過 Streamable HTTP。 遠端服務在工作區中設定後即可從網頁執行環境執行。

交給代理程式安裝

把這段提示詞貼上到 Claude Code、Codex、Cursor 等代理程式，或 SourceWeft 對話中。代理程式會讀取該伺服器的安裝指南，先向你展示發布者、端點和登入方式，經你同意後再把它新增到你的客戶端。金鑰不會寫進任何命令。

閱讀 https://sourceweft.com/mcp/ai.maximem%2Fsynap/install.md，並按其中說明把這個 MCP 伺服器接入我的客戶端。修改任何設定之前，先告訴我它的發布者、端點和登入方式，等我確認。不要把 API 金鑰寫進命令或我會提交的檔案；問我金鑰應從哪裡取得。

檢視代理程式所依據的安裝指南

其他 MCP 客戶端

把它新增到你客戶端的 mcpServers 設定中。

{
  "mcpServers": {
    "synap-memory": {
      "type": "http",
      "url": "https://synap-mcp.maximem.ai/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_TOKEN>"
      }
    }
  }
}

README

synap-mcp-server

[Maximem Synap MCP connector – tool definition quality and endpoint health on Glama]

Hosted remote MCP server (Streamable HTTP) that re-fronts the existing Synap public REST operations as MCP tools, so no-code platforms (Gumloop, n8n) can give their agents persistent memory with nothing but a pasted MCP URL and a Bearer token.

It is a stateless adapter — no new backend, storage, or pipeline. Each tool call maps to one existing REST operation, and the incoming Bearer synap_<key> token is forwarded verbatim to synap-cloud, which owns auth.

  • Public endpoint (prod): https://synap-mcp.maximem.ai/mcp
  • Health: https://synap-mcp.maximem.ai/health

Tools

ToolREST operationNotes
log_exchangePOST /api/v1/memories/create (mode=long-range)Forward every turn; extraction decides what persists. user_id scopes per end-user, customer_id is B2B only (see Scoping); optional conversation_id.
recall_contextPOST /v1/context/{client|user|customer}/fetch (mode=fast)Hot path; no IDs ⇒ client scope. customer scope is B2B only.
list_recent_memoriesbroad /v1/context/.../fetch (no query)Debug / "test my memory". Same scoping rules.
check_memory_statusGET /api/v1/memories/status/{id}Takes no scope ids: the ingestion_id already identifies the write.

Scoping: one contract, two modes

The REST API enforces this. It is not advice, and it has been live on production since 2026-08-26 07:07 UTC.

Instance mode (user_context_isolation)What to sendWhat happens otherwise
equals_customer (B2C)user_id and nothing else. The user id is the whole identity.Any customer_id is rejected with HTTP 400. /v1/context/customer/fetch is not available at all.
strict (B2B)customer_id is required, alongside user_id.A user_id on its own is an error. Unchanged by this contract.

GET /api/v1/auth/whoami reports the mode as user_context_isolation. This server reads it once per token and refuses a customer_id locally on a B2C instance, so a model gets a sentence telling it what to send instead of a status code it cannot act on. If the mode cannot be read, nothing is refused and the API stays authoritative.

Pass no IDs at all ⇒ client scope (shared per credential), which is valid in both modes. Note: client-scope writes are not surfaced on the dashboard Memories page (relational), so per-user scoping is recommended when dashboard visibility matters. Fill user_id from an n8n expression / Gumloop input, and pass the same value on log_exchange and recall_context so writes and reads address the same person.

Host header. The server disables the MCP transport's DNS-rebinding check (it sits behind a proxy + Bearer auth), so any reverse proxy can forward the real Host — no Host-rewrite hack needed.

Run locally

bash
pip install -e ".[dev]"SYNAP_API_URL=http://localhost:8000 uvicorn synap_mcp_server.server:app --port 8090curl http://localhost:8090/health        # {"status":"ok",...}

Reporting the turn to the anticipation agent

An MCP server is not an agent. It exposes tools to somebody else's agent and is handed one stateless HTTP call at a time, so most of what an agent does is invisible here: the caller's tool calls, its tool results and its reasoning never reach this process, and nothing tells a stateless server that a conversation has ended. Those are not reported, because there is nothing to report.

The turn does exist. log_exchange is handed the user's message and the assistant's reply as arguments. Set MCP_STREAM_EVENTS=true and each logged exchange is also reported as a conversation turn on POST /v1/events/batch, the HTTP door onto the same listening path the gRPC stream feeds, so the anticipation agent sees the turn and not only the memory extracted from it. This server does not use the SDK's gRPC stream, as the other integrations do: it holds no SDK, keeps no state between requests, and every request can carry a different tenant's key, so a stream per key would be an unbounded pool of connections that nothing closes. Moving it onto the SDK would be a rewrite of its transport for a caller that has no use for what the stream brings back.

Nor does it replace anything of Synap's compaction: the caller's agent keeps its own history and no tool here returns a conversation.

It is off by default, on purpose. Turning it on adds a second backend call per log_exchange, writes the turn to conversation history in addition to the long-range document, and runs the anticipation agent, which bills model calls.

It is not on by default for a second reason. Synap extracts from a conversation when it is compacted, which starts once ten messages have been recorded. Recording every exchange as turns instead of the long-range document would hold the memory back until then (the next recall_context finds nothing, and there is no ingestion_id to check); recording them as well extracts each exchange twice.

What does not change either way: log_exchange still queues the long-range document and still returns the ingestion_id that check_memory_status and wait_for_processing are built on. A turn report is best effort and can never alter what a tool answers. A turn with no user_id or no conversation_id is not reported at all, because the events route requires both.

Test

bash
pip install -e ".[dev]"pytest -q

Config (env)

VarDefaultMeaning
SYNAP_API_URLhttp://synap-cloud:8000Backing REST API base URL (internal docker hostname in prod).
MCP_PORT8090Listen port.
MCP_RECALL_TIMEOUT_S10Recall (read) timeout.
MCP_INGEST_TIMEOUT_S8Log/ingest (write) timeout.
MCP_DEFAULT_MAX_RESULTS10Default recall result count.
MCP_STREAM_EVENTSfalseAlso report a logged exchange as a conversation turn for anticipation. See above before enabling.
MCP_EVENTS_TIMEOUT_S4Turn-report timeout. Best effort; a miss never changes a tool's answer.
LOG_LEVELINFOLog level.
ENVIRONMENTproductionReported in /health.

No Synap API key is configured on the server — the end user's key arrives per-request as a Bearer token.

See the Synap MCP documentation for platform setup guides (Gumloop, n8n) and deployment details.

來源：packages/mcps/synap-mcp-server/README.md，提交 d56bd9c

工具

4

log_exchange

After each user message, send the exchange here so it can be remembered. You do not need to decide what is important, just forward the user message (and your reply, if you have one) and Synap will keep what matters. If your app serves more than one end-user, pass that person's stable id as user_id so each person's memory stays separate; if every conversation is the same single user, omit it. SCOPING: customer_id is B2B ONLY. On a B2B instance (user_context_isolation=strict) it is REQUIRED and a user_id on its own is an error. On a B2C instance (user_context_isolation=equals_customer) it is NOT accepted: the API rejects it with HTTP 400, customer-scoped retrieval does not exist there, and user_id is the whole identity. If you do not know which mode this instance is in, send user_id only and no customer_id; GET /api/v1/auth/whoami reports the mode as user_context_isolation. Logging is fire-and-forget by default; set wait_for_processing=true only when you need to confirm the memory finished extracting before continuing.

輸入參數user_idcustomer_iduser_message必填conversation_idassistant_messagewait_for_processing

check_memory_status

Check whether a logged exchange has finished processing. Pass the ingestion_id returned by log_exchange. Returns the processing status and how many memories were extracted. Useful to confirm a save completed (extraction is asynchronous). Takes no user_id or customer_id: an ingestion_id already identifies the write, so the identifier contract does not apply here.

輸入參數ingestion_id必填

recall_context

Before replying, call this to recall anything already known about this user from past conversations. Use the user's latest message as the query. If you serve multiple end-users, pass the same user_id you log with so you recall the right person's memory. SCOPING: customer_id is B2B ONLY. On a B2B instance (user_context_isolation=strict) it is REQUIRED and a user_id on its own is an error. On a B2C instance (user_context_isolation=equals_customer) it is NOT accepted: the API rejects it with HTTP 400, customer-scoped retrieval does not exist there, and user_id is the whole identity. If you do not know which mode this instance is in, send user_id only and no customer_id; GET /api/v1/auth/whoami reports the mode as user_context_isolation.

輸入參數query必填user_idcustomer_idmax_results

list_recent_memories

List recent things remembered about this user. Useful for debugging or to confirm that memory is working. Pass user_id to scope to one person. SCOPING: customer_id is B2B ONLY. On a B2B instance (user_context_isolation=strict) it is REQUIRED and a user_id on its own is an error. On a B2C instance (user_context_isolation=equals_customer) it is NOT accepted: the API rejects it with HTTP 400, customer-scoped retrieval does not exist there, and user_id is the whole identity. If you do not know which mode this instance is in, send user_id only and no customer_id; GET /api/v1/auth/whoami reports the mode as user_context_isolation.

輸入參數user_idcustomer_idmax_results

版本歷史

1
  1. v0.1.0最新Sep 16, 2026

評分

已滿足適用檢查項的 100%

該評分衡量此收錄條目的完整程度，依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價，也不表示伺服器安全或目前可用：可連通性是帶日期的檢查結果，評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通必需25 分
  • 已宣告認證方式必需10 分
  • 已列出工具必需15 分
  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分