Brain Memory
ai.brainmemory由 brainmemory.ai 发布官方发布者v0.5.1更新于 Nov 7, 2026
Persistent memory for AI agents: one brain shared across Claude, Cursor, Codex and more.
概览
远程 MCP 服务器,为 AI 助手提供持久、带评分的记忆大脑,可在 Claude、Cursor、Codex 等客户端间共享。
- 可以做什么
- 按查询召回经大脑引擎评分的记忆
- 查看记忆数量、最后更新时间,以及账户中哪个大脑处于启用状态
- 把明确提供的内容存为新记忆,并将其固定到或移出常驻层
- 归档记忆,并审核待验证记忆(批准或拒绝)
- 切换连接器所服务的账户大脑
- 适用场景
- 适合希望助手跨会话、跨不同 MCP 客户端记住事实、笔记或决定的场景,而不必每次对话从头开始。也适合已在 Brain Cloud 中维护大脑、希望在 Claude 网页版、桌面版或移动端使用同一批记忆的用户。
- 运行要求
- 通过 streamable HTTP 访问的远程端点,无需本地安装包。使用 OAuth 2.1 并以 Google(Firebase)账户登录,大脑必须属于同一账户。账户需在 Brain Cloud 中已有大脑,否则会创建一个空大脑。
安装
在 SourceWeft 中
- 打开 控制台中的 Brain Memory,将其添加到工作区。
- 连接 所需的 凭据。它们会被私密存储,绝不会在公开页面上展示。
- 为需要使用其工具的对话启用该服务。
Web executable,通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。
交给智能体安装
把这段提示词粘贴到 Claude Code、Codex、Cursor 等智能体,或 SourceWeft 对话中。智能体会读取该服务器的安装指南,先向你展示发布者、端点和登录方式,经你同意后再把它添加到你的客户端。密钥不会写进任何命令。
阅读 https://sourceweft.com/mcp/ai.brainmemory%2Fbrain/install.md,并按其中说明把这个 MCP 服务器接入我的客户端。修改任何配置之前,先告诉我它的发布者、端点和登录方式,等我确认。不要把 API 密钥写进命令或我会提交的文件;问我密钥应从哪里获取。其他 MCP 客户端
把它添加到你客户端的 mcpServers 配置中。 客户端会在首次连接时完成 OAuth 登录。
{
"mcpServers": {
"brain-memory": {
"type": "http",
"url": "https://mcp.brainmemory.ai/mcp"
}
}
}README
brain-connector
The Brain Memory Claude connector — a remote MCP server that exposes the brain's
scored recall to Claude (web / desktop / iOS / Cowork). Built with the official
@modelcontextprotocol/sdk per Anthropic's
build-mcp-server guidance. Design rationale lives in
brain-cloud/docs/connector-architecture.md.
It lives in this repo (not the npm package — excluded from package.json files, like
website/) so it reuses the real recall engine in ../src directly. One brain, one
engine, two faces.
Status: 🟢 LIVE IN PRODUCTION — Phase 1 + 2 (read + write)
Deployed at https://mcp.brainmemory.ai/mcp (Node service on the VPS beside brain-cloud;
systemd + nginx + certbot — see deploy/). Added at claude.ai and verified on Claude web +
iPhone. Tools: brain_recall, brain_status (read) + brain_memorize, brain_pin,
brain_unpin, brain_forget, brain_verify (write — writes sync back to brain-cloud; hosts gate
them behind confirmation) + brain_use (switch between the account's brains).
Two things to know in production:
- One brain ↔ one Google account — the connector serves the brain of whatever Firebase (Google) identity signs in, so the brain must be pushed to that brain-cloud account. See Identity & accounts below for how the connector now surfaces a wrong / empty / multi-brain account instead of silently serving a phantom brain.
- Sessions renew silently for ~a month — access tokens live 1 h, but the token endpoint issues
rotating refresh tokens (OAuth 2.1: single-use, family-revoked on reuse) with a sliding
30-day window (
CONNECTOR_REFRESH_TTL_MS), so an active user never sees the login page. Each refresh also renews the Firebase credential server-side (securetoken API, from the refresh token captured at login) — so sync-back and TTL re-pulls keep working far past the old ~1 h Firebase ID-token window. Grants + the DCR client registry persist underCONNECTOR_STATE_DIR(systemdStateDirectory; Firebase refresh tokens encrypted at rest viaCONNECTOR_STATE_KEY, our tokens stored hashed), so deploys/restarts no longer log users out. Local CLI memories (brain cloud push) reach an active session automatically via a TTL re-pull (CONNECTOR_REPULL_TTL_MS, default 120s) — it re-pulls only when the cloud checksum changed and never over an unsynced local write.
npm test typechecks and proves the whole path end-to-end in one server — the
complete OAuth 2.1 handshake through to real scored recall (token request is form-urlencoded,
matching real clients):
How recall stays identical to the CLI
The engine bridge (src/engine.ts) runs the repo's bin/recall.js with BRAIN_DIR
pointed at the authenticated user's brain working copy — so the connector's scoring is
byte-for-byte the CLI's, with zero reimplementation. (BRAIN_DIR is the same override
the CLI ships.)
Run / test
Tools
Writes reuse the deterministic CLIs (memorize.js / pin.js / unpin.js / forget.js) and then
syncBack() to brain-cloud.
Identity & accounts
One brain ↔ one Google account. The connector has no idea which laptop you're on — it serves the
brain belonging to whatever Firebase (Google) identity completes the sign-in. The verified uid maps
deterministically to a brain user (resolveBrainUserId), and that user's canonical brain is pulled
from brain-cloud: the brain the user chose with brain_use, or else the account's oldest. So the
rule is simple: connect with the same Google account your CLI's brain cloud syncs to, and use
the same brain (brain cloud brains shows which one the CLI is linked to).
To keep that rule from failing silently, ensureUserBrain returns an identity signal that the
tools surface to you:
This is guidance, not enforcement — a genuinely new user with no brain yet still gets a usable
empty brain. Account-linking (letting one Google identity span several brains at once) is
deliberately deferred; choosing one brain at a time is brain_use.
Auth
Two layers — both real now:
- OAuth 2.1 between Claude and the connector (
src/oauth.ts): authorize / token / register / metadata, PKCE S256, RFC 8707 audience binding, RFC 9207iss. Tokens mint intosrc/auth.ts's store; the/mcpguard validates them (incl. audience). - Who is the human (
src/firebase.ts):/authorizebounces the user through Firebase login (the same project brain-cloud uses). The connector verifies the ID token server-side and secret-free — RS256 against Google's public certs, checkingaud/iss/exp— so it needs only the public project config, no service-account key. The verifieduidmaps to the brain user, then the OAuth code is minted.
If FIREBASE_* env is not set, /authorize falls back to a fixed dev user
(STUB:FIREBASE) so the headless test runs without a browser.
See the Firebase login work (demo)
Signing in through /authorize shows the branded consent/login page and, on success, resolves
your verified firebase_uid → brain_user_id → brain_dir — which is how the connector picks
whose brain to serve. (localhost is an authorized Firebase domain by default, so popup sign-in
works locally.)
Per-user store (src/store.ts)
ensureUserBrain({ userId, brainDir, idToken }) populates the user's brain working copy from a
pluggable provider, then the engine recalls over it. Providers (via CONNECTOR_STORE, else
inferred):
brain-cloud(production) — pulls the user's{brainID}.tar.gzfromBRAIN_CLOUD_API_URL(defaulthttps://api.brainmemory.ai) using their Firebase ID token (brain-cloud's middleware accepts it directly), thentar xzfintobrainDir. Refreshed at each login.local(dev) — symlinksbrainDir→$DEV_LOCAL_BRAIN(your live~/.brain), so your machine serves your real brain through the connector.none— assume pre-provisioned (tests).
Always graceful: if the brain is still missing, it empty-inits a valid (recall-safe) brain.
The brain-cloud provider speaks the store contract, so it works
against any store that implements it, including a self-hosted
brain-store. Sync-back is conditional (If-Match): if another
device pushed first, the connector discards its working copy, starts again from the store's
brain, re-applies the write and pushes again, so nobody's memories are overwritten.
Identity providers (src/identity.ts)
Who is logging in, and what the connector presents to the store for them, sits behind one
interface. Select with CONNECTOR_IDP:
-
firebase(the default whenFIREBASE_*is set) — Google sign-in. The store credential is the Firebase ID token, renewed from the Firebase refresh token. -
static— for a self-hosted store. The sign-in page takes the token the store's operator issued (brain-store user add); the store decides who the user is. RequiresBRAIN_CLOUD_API_URLto be set explicitly, so a token can never be sent to the hosted default by accident. Rotating or removing the user at the store ends their sessions at the next silent renewal. -
oidc— for a self-hosted store that accepts your organisation's OpenID Connect issuer (Entra, Google Workspace, Keycloak, Okta)./authorizesends the browser to the issuer (authorization code + PKCE + nonce) and the issuer returns it to/oidc/callback. The ID token is the store credential, renewed from the issuer's refresh token. NeedsOIDC_ISSUER,OIDC_CLIENT_IDand an explicitBRAIN_CLOUD_API_URL. Token verification is the store's own (store/lib/oidc.js), so the two can never disagree about what a valid token is. An issuer outage answers503and keeps the login; a revocation ends it.
With no provider configured the connector refuses to start in production. When the reverse
proxy is not on loopback (another container, say), name it with CONNECTOR_TRUST_PROXY, for
example uniquelocal; true is refused.
Next
- Account-linking — let one user span several brains at once (recall across them), rather than serving one chosen brain at a time. See Identity & accounts.
- Directory submission — remaining manual steps (test account, MCPB packaging, launch post); see
the submission checklist in
brain-cloud/docs/connector-architecture.md§7.
来源:connector/README.md,提交 0bc6371
工具
0版本历史
2- v0.5.1最新Nov 7, 2026
- v0.4.0Oct 13, 2026
评分
已满足适用检查项的 85%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通必需25 分
- 已声明认证方式必需10 分
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分