峰瑞资本最近社区里聊 VSCode 配置 MCP 的朋友明显变多了。MCP 全称是 Model Context Protocol，它解决的是一个很实际的问题：让 AI 编程工具能真正接触到本地文件、Git 仓库、数据库、设计稿这些外部数据，而不是只靠你复制粘贴上下文对话。我自己是 Windows 用户，在 VSCode 里同时试过 Claude Code、Cline、Codex 这几类入口，中间踩得最狠的就是 MCP error -32000: Connection closed 这个报错。这篇文章就把我在 Windows 环境下从零配置 MCP 的过程，以及对 -32000 这个错误的完整排查思路写出来，尽量做到每一步都能直接照着抄。
1. 先画清楚 MCP 在 VSCode 里的运行链路，配置才不会乱
MCP 并不是某个 VSCode 插件，也不是一个捆绑销售的大平台。它就是一套协议，规定了“AI 客户端”和“外部数据/工具服务端”之间怎么建立连接、怎么按 JSON-RPC 消息格式交换数据。把这件事理解成一个“热插拔接口”会更顺：MCP 协议就是 USB，MCP Server 就是各种外设，AI 客户端是主机。你需要显示器就插显示器，需要键盘就插键盘，谁提供能力谁就是 Server。
标准链路通常是这样的：你在 VSCode 里装上支持 Agent 的扩展，比如 Cline、Roo Code，或者在集成终端里跑 Claude Code / Codex 这类 CLI，这个扩展或 CLI 就是 MCP 客户端；需要接入的外部资源由 MCP Server 承担；两者之间通过 MCP 协议持续通信。开发者真正感知最强的是 tools 概念，Server 会把自己能做的操作暴露成一个个工具，比如读取某个目录的文件、抓取某个 URL、执行 SQLite 查询。模型看到用户的请求后，会决定是否调用某个工具，再把工具返回结果作为上下文继续生成。
1.1 MCP 能做什么，适合谁来用
VSCode 原生并不能直接“理解”你的整个工程，传统补全只能基于当前编辑器里打开的文本。MCP 补上了这个缺口：假设你想写一个脚本去批量修改某个目录下所有 markdown 文件的标题，没有 MCP 时，AI 可能只会给你一段需要手动运行的代码；接了 Filesystem MCP Server 之后，AI 可以直接读取文件列表、读取文件内容、修改文件，再告诉你实际改了什么。
这类能力对以下场景特别有价值：
- 写前端时让 AI 参考本地设计稿或者组件库代码。
- 开发后处理脚本时，让 AI 直接读取素材文件并自动生成批处理。
- 接 GitHub 或 GitLab 操作，让 AI 在对话里直接帮你建 issue、看 PR。
- 使用数据库 MCP Server 让 AI 查询表结构和测试数据。
- 游戏开发中接 Unity 或 Cocos Creator 的 MCP Server，让引擎内的场景操作和 AI 对话联动。
很多人问它和普通 API 工具函数有什么区别。最直接的区别是发布形式：API 工具函数需要你为每个客户端单独写适配层，MCP Server 写一次，Claude Code、Cline、Codex 等一堆客户端都能共用一套接口。所以我才建议先理解 MCP 是什么，而不是着急去抄某段配置。
1.2 stdio、SSE 和 Streamable HTTP：三种传输方式怎么选
MCP 配置里最常出现的三个词是 stdio、SSE、Streamable HTTP。新手最容易搞混的是：明明写了一个本地命令，却去填 URL 字段；或者反过来，服务在远程，却硬要塞 command 参数。
stdio是最常用的本地启动模式。客户端直接拉起一个子进程，通过标准输入 stdin 和标准输出 stdout 与 Server 通信。命令行工具类的 MCP Server 基本都走这种方式。配置里就是command+args。SSE是 HTTP 传输的旧版形态，服务端通过 Server-Sent Events 向客户端推送消息。配置里一般是url，比如http://localhost:8080/mcp。Streamable HTTP是较新的 HTTP 传输规范，把请求和响应都统一放到 HTTP 上处理。双方只要找对一个 endpoint，就能完成初始化和工具调用。很多新版 SDK 默认启用这个模式。
从一个用过多个客户端的老用户角度，本地能跑的东西优先选 stdio。它不依赖网络端口，不受防火墙和代理影响，调试起来也更干净。只有在 Server 需要部署在远程机器