本地部署与配置 MCP 服务器

MCP 客户端连接服务器时，当前最常见的是两种方式：

• stdio：客户端直接启动本地进程，通过标准输入输出通信，最适合本机工具；
• Streamable HTTP：客户端连接一个 HTTP MCP 地址，适合远程或长期运行的服务。

旧版 SSE 仍可能出现在一些客户端和项目里，但新部署优先看项目是否支持 Streamable HTTP。不要看到“HTTP”就自行假设某个端口一定是 MCP 服务端点。

Sequential Thinking：本地 stdio

Sequential Thinking 已有现成的 MCP Server 包，不需要自己先克隆一个 Python 占位项目。安装 Node.js 后，可以先在终端验证：

npx -y @modelcontextprotocol/server-sequential-thinking

stdio 模式下进程看起来会一直等待输入，这是正常的；实际使用时通常由 Cursor 等 MCP 客户端负责启动和管理它。

Cursor 的配置可写成：

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    }
  }
}

Windows 如果客户端直接调用 npx 有问题，可以按该客户端说明改成通过 cmd /c npx ... 启动。

Context7：优先使用托管 MCP

Context7 现在直接提供托管 MCP，不需要为了普通使用去克隆仓库、用 Bun 构建，再自己猜一个 8080 端口。

最省事的方法是使用它当前提供的安装流程：

npx ctx7 setup

也可以在支持远程 MCP 的客户端中添加其官方 MCP 地址，并按当前文档完成 OAuth 或 API Key 认证。认证信息不要直接写进公开仓库。

如果确实要本地运行 Context7，再按项目当前 README 使用 @upstash/context7-mcp，不要照抄旧版源码目录和构建命令。

Cursor 中怎么选

对于本地工具，优先用 stdio / command；对于已经部署好的远程 MCP，使用 Streamable HTTP URL。Cursor 当前同时支持 stdio、Streamable HTTP，并兼容旧 SSE。

一个配置可以同时包含本地和远程服务器，例如：

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    },
    "context7": {
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

具体配置文件位置和认证字段以 Cursor 当前版本的 MCP 设置页为准；如果 UI 能直接安装或登录，优先使用 UI，不必为了“手工配置”强行编辑 JSON。

WSL 环境注意

如果 Cursor 运行在 Windows，而 MCP 命令实际装在 WSL，需要明确命令到底在哪一侧执行。最简单的是让 MCP 客户端和本地 stdio 服务器处在同一个环境；否则就用 wsl.exe 包一层，或者改用远程 HTTP MCP。

例如 Windows 客户端启动 WSL 内命令时，要使用实际发行版和绝对路径，不要假定 Windows 能直接执行 /home/... 下的程序。

排错

1. stdio 启动失败：先在同一环境的终端直接运行 command + args，确认命令存在；
2. 服务器启动后客户端看不到工具：检查协议/传输方式是否匹配，不要把普通 Web 服务 URL 当 MCP URL；
3. 远程 MCP 401/403：检查 OAuth、API Key 和请求头；
4. WSL 能运行、Windows Cursor 不能运行：重点检查运行环境和路径，而不是重复安装依赖；
5. 配置修改后不生效：重载 MCP Server 或重启客户端，再看客户端自己的 MCP 日志。

Sequential Thinking 与 Context7 提供的是工具能力，正常情况下不需要额外写一段“强制输出完整思维过程”的提示词。实际任务里直接说明目标、约束和期望输出即可。