MCP 客户端连 Mem0 MCP 服务器报 401 Authentication required 怎么排查-育师

MCP 客户端连 Mem0 MCP 服务器报 401 Authentication required 怎么排查

【免费下载链接】embedchainThe Memory Layer for AI Agents - Drop-in memory infrastructure for AI agents and apps. Context that persists. Built for production.项目地址: https://gitcode.com/GitHub_Trending/em/embedchain

把 Claude、Cursor、Codex、VS Code 等 MCP 客户端指向 Mem0 托管的 MCP 服务器（https://mcp.mem0.ai/mcp）后，如果连接报401或 "Authentication required"，说明客户端已经连通服务器，但还没有完成身份认证。Mem0 MCP 服务器是带认证的：文档明确说明，浏览器登录和 API key 两种方式都没有配置好时，服务器就会返回401 Authentication required，客户端随即把连接标记为失败（见 Mem0 MCP 文档）。

因此这个报错的排查目标很集中：确认客户端走的是哪条认证路径，然后把该路径补完整。前提条件与首次配置相同：Mem0 Platform 账号、从 Mem0 dashboard 获取的 API key（以m0-开头）、Node.js 18+（如果使用npx）、以及一个 MCP 兼容客户端。

先判断你应该走哪条认证路径

Mem0 MCP 支持两种认证方式，官方文档把它们的适用条件写得比较清楚：

客户端内浏览器登录：多数客户端默认走这条路径。第一次调用 Mem0 工具时，客户端会打开一个浏览器窗口请求你授权访问 Mem0 账号，批准一次后客户端会保存并自动刷新 token。如果你是用npx mcp-add快速配置（--type http --url "https://mcp.mem0.ai/mcp"）的，默认就是这条路径。
API key 作为 bearer token：适用于没有浏览器登录能力的客户端，或 CI 这类无头环境。API key 从 Mem0 dashboard 获取，放到哪里取决于具体客户端。

排查 401 时先对照自己的环境：桌面客户端本应弹出浏览器登录窗却报 401，就补浏览器登录这一步；无头环境或没有浏览器登录的客户端，就配置 API key。

路径一：完成浏览器登录

如果你的客户端支持浏览器登录，第一次调用 Mem0 工具时应当出现浏览器授权窗口，批准即可，token 由客户端自行保存和刷新。两个判断点：

首次工具调用应该触发这个登录流程；如果配置了 API key，则不会出现该窗口。
如果客户端一直没有弹出登录窗、也没有配置 key，就会一直停在 401 状态。

对于 Claude Desktop，文档特别提醒它不走mcp-add（会被拒绝为 "not a valid MCP server"），需要手动在 Settings → Connectors → Add custom connector 里填入名称（例如mem0-mcp）和 URLhttps://mcp.mem0.ai/mcp，保存并重启后，首次使用 Mem0 工具时再走浏览器登录。

路径二：配置 API key 作为 bearer token

给客户端配置 API key 后重启，让它在请求中携带 bearer token。key 的具体写法因客户端而异，文档以 Codex 为例：在~/.codex/config.toml中加入

[mcp_servers.mem0] url = "https://mcp.mem0.ai/mcp" bearer_token_env_var = "MEM0_API_KEY"

然后在启动 Codex 的那个 shell 里export MEM0_API_KEY，再重启 Codex。可以用下面命令确认变量在当前 shell 确实有值：

echo $MEM0_API_KEY

如果输出为空，说明环境变量没有导出到启动客户端的 shell 中——这是"key 明明配了还报 401"最常见的位置。Codex 集成文档的 Direct MCP 一节使用的 URL 写作https://mcp.mem0.ai/mcp/（带尾斜杠），两者出自不同文档，配置时以你实际使用的文档为准。

Codex Cloud 的额外限制：如果是在 Codex Cloud 环境中跑任务，文档明确指出mem0MCP 服务器在每次工具调用时都会认证（不只是 setup 阶段），而 Cloud 环境的 Secrets 只提供给 setup 脚本、进入 agent 阶段前会被清空。所以MEM0_API_KEY必须配置为环境变量而不是 Secret，否则 setup 能认证、agent 阶段却拿不到 key，Mem0 MCP 调用会失败。

401 之后的其他现象：按错误信息区分

Mem0 MCP 文档的 Troubleshooting 表把几个相近现象分开了，排查时不要混淆：

现象	文档给出的含义	对应操作
`401`或 "Authentication required"	客户端连通了但未登录	完成浏览器登录，或把 API key 配成 bearer token
"Invalid API key"	key 错误、已吊销或属于其他账号	从 Mem0 dashboard 重新获取一个 key
"Connection refused" / "failed to connect"	客户端连不上服务器	检查网络，并确认 URL 恰好是`https://mcp.mem0.ai/mcp`
客户端里没有 Mem0 工具	配置已写入但客户端未重新加载	重启客户端；工具仍缺失时检查`mcp-add`是否写入了客户端实际读取的配置文件

也就是说：配置 bearer token 后如果 401 变成了 "Invalid API key"，问题就从"没认证"切换成了"key 无效"，处理方式是对应的——去 dashboard 重新生成 key。

验证是否修复

修复后的验证方式文档给出的是一个往返测试：重启客户端，让 agent 存一条记忆，之后再用一条消息读回来：

You: Remember that I prefer TypeScript over JavaScript for new projects. Agent: Saved. You: What language do I prefer for new projects? Agent: You prefer TypeScript over JavaScript.

（以上为文档中的示例对话。）第二次回答只有在记忆真的存进去之后才成立，所以这是一个真实的数据往返验证，而不是模型复述。同时观察两点：