WSの小屋

MCP 学习笔记:从概念到 VS Code 接入

最近在折腾 MCP,把整个过程整理一下。简单来说,MCP 就是让 AI 助手能对接外部系统的一套标准协议。有了它,AI 就不再只能跟你聊天,还能真正帮你干活。

为啥我要研究 MCP?

说实话,最开始我也觉得这东西有点虚。直到我发现自己总在重复做这些事:

  • 写代码时要不停翻接口文档;
  • 查个数据库记录还要手动写 SQL;
  • 想让 AI 帮我调用个接口,还要把 URL、参数、返回格式全都粘贴一遍;
  • 更别说让它帮我读写文件、调用 GitHub 了。

如果每个工具都要自己写一套对接方式,那太累了。MCP 的好处就是,它提供了一套统一的标准,不管是什么系统,只要按这个标准来,AI 客户端就能自动识别和使用。

大概就是这么个意思:

AI 助手(VS Code / Claude / Cursor)
        ↓ 用 MCP 协议沟通
各种外部能力(你的 API、数据库、文件系统、业务系统)

MCP 到底是啥

不用把它想得太复杂。MCP 主要就三样东西:工具、资源和提示模板。

工具(Tools)

这是 AI 可以主动调用的功能。比如你想让 AI 查文章列表,那就可以暴露一个「查询文章」的工具。

每个工具要说明三件事:叫什么、干什么用、接受什么参数。

我这个博客的 MCP 就暴露了两个工具:

  • 列出所有 API 路由
  • 调用指定的 HTTP API

资源(Resources)

资源更像是给 AI 看的参考资料。AI 可以读它,但它本身不执行什么动作。

比如我把 OpenAPI 文档做成一个资源,AI 就能随时读取整个接口说明,不用我每次粘贴。还有整理好的 API 路由列表,也是一个资源。

提示模板(Prompts)

这个就是预定义好的提示词。比如「生成接口文档」、「分析错误日志」这种固定流程,可以做成 Prompt 复用。

不是每个 MCP 服务都要做 Prompt,很多时候有 Tools 和 Resources 就够用了。

它是怎么通信的

MCP 用的是 JSON-RPC 2.0。你就理解成一种固定格式的 JSON 对话就行了。

比如客户端问有什么工具:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

服务端就回:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": []
  }
}

常用的方法也就那几个:

  • initialize:打招呼,告诉对方我能干什么
  • tools/list:我有哪些工具
  • tools/call:调用某个工具
  • resources/list:我有哪些资料
  • resources/read:读取某份资料

怎么在 VS Code 里用

这个很简单。在项目里建个 .vscode/mcp.json 文件,写上:

{
  "servers": {
    "wsvaio-blog": {
      "type": "http",
      "url": "http://localhost:3000/api/mcp"
    }
  }
}

然后启动你的本地服务,VS Code 就能自动连上。就这么一行配置,剩下的都是自动的。

我这个博客 MCP 能做什么

目前我的 MCP 服务就做了几件事:

  1. 列出所有 API —— AI 能看到整个博客系统有哪些接口
  2. 调用任意 API —— 只要是 OpenAPI 里登记过的,都能调
  3. 提供 OpenAPI 文档 —— 完整的接口说明
  4. 提供整理后的路由列表 —— 方便快速查阅

比如想查文章列表,AI 就会自动调用 call_api 工具,传个 GET 请求到 /api/article/page

需要登录的接口也没问题,MCP 会把 Authorization 头自动转发过去。

MCP 和普通 API 有啥不一样

别搞混了,MCP 不是来替代 HTTP API 的。它更像是给 AI 加的一层「翻译层」。

普通 HTTP API 是给人或者前端页面用的:

前端 → HTTP API → 数据库

MCP 是给 AI 助手用的:

AI → MCP → 你的工具和数据

所以做 MCP 的时候,你要想的不是「这个接口返回什么字段」,而是「AI 能不能理解这个能力」、「参数是不是够简单」、「返回结果会不会太长」。

做 MCP 服务的一点心得

折腾了这几天,总结几个小点:

工具不要太多。一开始我想把每个业务接口都做成单独的工具,后来发现完全没必要。就一个 call_api 通用工具,AI 用得反而更好。

参数要严格。比如 HTTP 方法就只允许 GET、POST、PUT、DELETE 这四个,参数类型写清楚,这样 AI 就不会乱传值。

危险操作要控制。这个很重要,别什么接口都暴露。写操作一定要加鉴权,敏感数据要过滤。我这个 MCP 就只允许调用 OpenAPI 里登记过的接口。

资源适合放稳定内容。那些经常要读但不会变的东西,比如 API 文档、数据库表结构、编码规范,都可以做成 Resource。

学习路线建议

如果你也想试试 MCP,建议按这个顺序来:

  1. 先搞懂 JSON-RPC 2.0 的基本格式
  2. 实现 initializetools/list,先让服务能跑起来
  3. 写一个最简单的工具,比如「返回 Hello World」
  4. 接入 VS Code 试试能不能用
  5. 慢慢加 Resources、错误处理这些
  6. 最后再考虑鉴权、日志这些高级功能

最后说两句

MCP 这个东西,说穿了就是让 AI 能「看见」你的系统,能「操作」你的系统。

现在我这个博客虽然只有简单的 API 调用能力,但已经很有用了——至少不用再手动把接口文档粘贴给 AI。对于个人项目或者内部工具来说,这已经是个很大的提升。

后面打算继续完善,比如加上文章发布的工具,这样 AI 写完文章就能直接发布,不用我手动复制粘贴。想想还挺有意思的。

上一篇

下一篇

留言板

Comments | 0条评论

  • 头像回复发布于 2026/06/20 10:30:00

    写得很详细,MCP 协议这部分终于搞懂了,谢谢!


  • 头像回复发布于 2026/06/21 14:15:00

    有没有考虑过用 SSE 替代 stdio 传输?感觉更适合远程场景