1. 使用 npx 安装 Playwright MCP（或其他 npm 发布的 MCP 服务）
claude mcp add playwright -s user -- npx @playwright/mcp@latest
✅ 原理：
- 利用
npx直接运行一个已发布到 npm 的 MCP 服务器包。 claude mcp add是 Claude CLI 提供的命令，用于注册一个 MCP 服务。
✅ 优点：
- 简单快捷：一行命令即可安装并注册。
- 标准化：适合官方或社区维护的、已打包发布的 MCP 服务（如 Playwright、LangChain 等）。
- 自动依赖管理：npm 自动处理依赖，无需手动配置 Python/Node 环境（假设已有 Node.js）。
❌ 缺点：
- 仅限 npm 生态：只能用于已发布为 npm 包的 MCP 服务。
- 版本控制弱：默认拉取 latest，可能不稳定；需手动指定版本。
- 灵活性低：无法自定义启动参数、环境变量（除非包装脚本）。
📌 适用场景：
快速集成官方支持的工具类 MCP（如浏览器自动化、数据库连接器等）。
2. 使用 SSE（Server-Sent Events）HTTP 传输方式
claude mcp add --transport http <name> <url>
✅ 原理：
- 将远程 HTTP 服务（需符合 MCP over SSE 协议）注册为 MCP 服务器。
- Claude 通过 HTTP + SSE 与该服务通信（非本地进程）。
✅ 优点：
- 远程部署支持：MCP 服务可运行在另一台机器、Docker 容器或云服务上。
- 语言无关：只要实现 MCP/SSE 协议，可用任何语言（Go、Rust、Python 等）编写。
- 资源隔离：不占用本地进程，适合长期运行的服务。
❌ 缺点：
- 协议要求高：必须严格实现 MCP over SSE 规范。
- 网络依赖：需要稳定网络，调试复杂。
- 安全性考量：暴露 HTTP 接口需考虑认证、加密（如 HTTPS、API Key）。
📌 适用场景：
企业内部部署统一 MCP 服务网关、跨团队共享 AI 工具、或使用非 JavaScript/Python 技术栈开发的 MCP。
3. 使用 JSON 配置（本地命令启动）
{
"mcpServers": {
"zen": {
"command": "sh",
"args": ["-c", "exec $(which uvx || echo uvx) ..."],
"env": { "GEMINI_API_KEY": "..." }
}
}
}
✅ 原理：
- 在
claude_desktop_config.json或.mcp.json中声明一个本地可执行命令。 - Claude 启动子进程运行该命令，并通过 stdio 通信（标准 MCP over stdio）。
✅ 优点：
- 最大灵活性：可运行任意命令（Python 脚本、uvx、Docker、shell 脚本等）。
- 完整环境控制：可注入环境变量（如 API keys）、PATH、工作目录等。
- 适合复杂项目：如 Zen MCP 这种多模型、多依赖的项目。
❌ 缺点：
- 配置复杂：需手动编写 JSON，理解命令行和环境变量。
- 平台依赖：
sh、which、uvx等在 Windows 可能不兼容（需 WSL 或 PowerShell 改写）。 - 调试困难：子进程崩溃时日志不易追踪。
📌 适用场景：
高度定制化 MCP 服务（如 Zen MCP）、需要多模型集成、本地开发调试。
4. 从 Claude Desktop 导入（claude mcp add-from-claude-desktop）
✅ 原理：
- 将已在 Claude Desktop 应用 中配置好的 MCP 服务同步到 CLI 环境（或反之）。
- 本质是配置文件的双向同步（读取 Desktop 的 config 并注册到 CLI）。
✅ 优点：
- 无缝切换：Desktop 用户无需重复配置 CLI。
- 用户体验友好：适合非命令行用户先在 GUI 中配置，再导出。
❌ 缺点：
- 依赖 Desktop：必须已安装并配置过 Claude Desktop。
- 功能有限：仅用于“同步”，不能直接安装新服务。
- 平台限制：Desktop 仅支持 macOS/Windows，Linux 用户无法使用。
📌 适用场景：
桌面端用户希望在终端中复用已配置的 MCP 服务。
