MCP 到底是什么?一个全栈开发者的实战理解
最近在折腾各种 AI Agent 工具的时候,老是看到一个词:MCP。Hermes Agent 全面指南:从入门到精通的开源 AI 智能体 文档里提它,Claude Code 配置里有它,Cursor 也说支持了。一开始我也没太在意,以为又是什么花里胡哨的概念。直到有一天我需要让 AI 帮我操作数据库、调 API、读本地文件,发现每个工具的集成方式都不一样,配置文件写了一堆,才意识到——MCP 这东西,可能真的是来解决问题的。
建站快一个月了,一直在搞各种 AI 工具的集成,踩了不少坑。今天把我对 MCP 的理解整理一下,不求面面俱到,但求说清楚它到底是个啥、为什么需要它、以及怎么实际用起来。
先说问题:AI 工具的碎片化地狱
在没有 MCP 之前,如果你想让一个 AI 编程助手帮你做点"实事"(不只是聊天),你会发现每个工具都有自己的扩展方式:
- Claude Code:用 Skills,写 Markdown 文件定义行为
- Cursor:用
.cursorrules,也是一种自定义配置 - Hermes Agent:有自己的工具系统和插件机制
- VS Code 插件:各自为政,API 调用方式千差万别
问题来了:假设你写了一个"查天气"的工具,想让它同时在 Claude Code 和 Cursor 里都能用。对不起,你得写两份适配代码。格式不同、协议不同、甚至连接方式都不同。
这就好比每个手机品牌都用自己的充电口——Lightning、Micro USB、USB-C 各来一个,你出门得带三根线。
MCP 就是那个 USB-C。
MCP 是什么
MCP,全称 Model Context Protocol,是 Anthropic 在 2024 年底提出的一个开放协议。简单来说,它定义了一套标准,让 AI 模型(或 AI 工具)能够以统一的方式连接外部数据源和工具。
用大白话说就是:
MCP 让 AI 能用同一种"语言"跟各种外部工具对话。
不管你是要查数据库、读文件、调 API、还是操控浏览器,只要这些工具实现了 MCP 协议,AI 就能直接用,不用每个工具单独写一套集成代码。
核心概念
MCP 里有几个关键角色,不复杂:
MCP Server(服务端):提供能力的一方。比如一个"文件系统 MCP Server"就提供了读写文件的能力,一个"数据库 MCP Server"就提供了查询数据库的能力。
MCP Client(客户端):使用能力的一方。通常是 AI 工具本身,比如 Claude Code、Hermes Agent 等。
Transport(传输层):客户端和服务端之间的通信方式。主要有两种:
- stdio:通过标准输入输出通信,适合本地工具
- HTTP/SSE:通过网络通信,适合远程服务
就这么简单。Server 提供工具,Client 调用工具,中间用标准协议通信。
为什么要搞 MCP
回到最开始的问题:没有 MCP 的时候,每个 AI 工具都有自己的扩展机制,开发者要重复适配。
MCP 解决的核心问题就是标准化。一次实现,到处可用。
打个比方,以前你想让 AI 能查天气:
| 1 | |
| 2 | |
| 3 | |
三套代码,三个配置,三份维护。
有了 MCP 之后:
| 1 | |
一次开发,所有支持 MCP 的客户端都能接入。
这对开发者来说意味着什么?你写一个 MCP Server,你的工具就能被所有支持 MCP 的 AI 产品使用。生态效应一下子就起来了。
MCP Server 长什么样
说一千道一万不如看看代码。MCP Server 其实挺简单的,我用 Python 给你写一个最基础的例子。
先装依赖:
| 1 | |
然后写一个最简单的 MCP Server,提供一个"加法计算"的工具:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
| 15 | |
| 16 | |
| 17 | |
| 18 | |
| 19 | |
| 20 | |
| 21 | |
| 22 | |
| 23 | |
| 24 | |
| 25 | |
| 26 | |
| 27 | |
| 28 | |
| 29 | |
| 30 | |
| 31 | |
| 32 | |
| 33 | |
| 34 | |
| 35 | |
| 36 | |
| 37 | |
就这么几行代码,一个 MCP Server 就写好了。它提供了一个 add 工具,接收两个数字,返回它们的和。
当然这只是个 demo。实际场景中你可以对接任何东西:数据库、文件系统、API、甚至硬件设备。
配置文件怎么写
写好了 Server,怎么让 AI 工具找到它?通过配置文件。不同的客户端配置方式略有不同,但核心都是一样的:告诉客户端去哪里启动这个 Server。
以 Claude Code 为例,在项目根目录创建 .mcp.json:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
Hermes Agent 的配置在 config.yaml 里:
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
Cursor 的话在 .cursor/mcp.json 里配置,格式大同小异。
核心就一句话:告诉客户端用什么命令启动 Server。之后客户端会自动管理 Server 的生命周期——启动、通信、关闭,你都不用操心。
现成的 MCP Server 有哪些
自己写 Server 当然好,但更爽的是别人已经写好了。MCP 生态发展得很快,GitHub 上已经有大量现成的 MCP Server 可以直接用。
挑几个我觉得实用的:
文件系统(filesystem)
这个是最常用的。让 AI 能读写你本地的文件。
| 1 | |
一行命令启动,AI 就能访问指定目录下的文件了。注意它有路径限制,不会让你随便访问整个硬盘,这点安全设计还是到位的。
数据库查询
有好几个数据库 MCP Server:
- PostgreSQL:
@modelcontextprotocol/server-postgres - SQLite:
@modelcontextprotocol/server-sqlite - MySQL:社区实现的也有
配置好连接字符串,AI 就能直接帮你写 SQL、查数据、做分析。对于后端开发者来说这个太实用了。
Web 搜索
| 1 | |
接上 Brave Search API,AI 就能搜索互联网了。不用再靠 AI 的"记忆"来回答问题,直接搜实时信息。
GitHub
| 1 | |
让 AI 能操作 GitHub:查看仓库、创建 Issue、提 PR、读代码。配合 AI 的代码理解能力,做 Code Review 特别方便。
浏览器自动化
Playwright MCP Server 可以让 AI 操控浏览器:打开网页、点击按钮、填表单、截图。做自动化测试或者爬虫场景下很有用。
更多
还有 Slack、Google Drive、Notion、Docker、Kubernetes 等各种 MCP Server。社区的创造力是惊人的,基本上你能想到的工具都有人做了 MCP 适配。
去 GitHub 搜 mcp server 或者看 MCP 官方仓库 的列表,能找到更多。
我踩过的坑
讲到这里一切看起来很美好,但实际用起来还是有些坑的,我来吐槽几个。
坑一:文档和版本不匹配
MCP 协议还在快速迭代,Python SDK 的版本更新也很快。网上很多教程用的是旧版 API,直接复制粘贴跑不通。我就踩了这个坑——照着一篇博客写代码,结果 mcp 包的 API 已经变了,报了一堆 ImportError。
解决办法:看官方文档,看 GitHub 仓库的 README,别看二手博客。
坑二:stdio 和 HTTP 搞混
MCP 有两种传输方式,有些 Server 只支持其中一种。如果你的客户端期望用 stdio 连接,但 Server 只提供了 HTTP,那就连不上。
我第一次配置的时候就犯了这个错,折腾了半天才发现是传输方式不对。
坑三:权限问题
文件系统 MCP Server 有路径限制,但有些 Server 的安全设计没那么完善。如果你配了一个数据库 MCP Server,AI 就有了执行 SQL 的能力——包括 DROP TABLE。
所以在生产环境用的时候,一定要注意权限控制。读写分离、最小权限原则,该设的都得设。
坑四:调试困难
MCP 通信走的是 JSON-RPC,出错的时候报错信息有时候不太直观。特别是 stdio 模式,你看不到通信内容,只能靠客户端的日志来排查。
建议开发的时候开 verbose 日志,或者用 MCP Inspector(官方的调试工具)来查看通信内容。
MCP 和 Function Calling 有什么区别
这个问题我一开始也搞不清楚。Function Calling 是 OpenAI 提出的,让 GPT 能调用函数。MCP 也是让 AI 能调用工具。那它们有啥区别?
简单来说:
- 定义方式:在 API 请求里定义工具。缺点是独立的 Server 进程
- 复用性:绑定在特定 API 调用里。缺点是独立进程,任何客户端都能用
- 运行时:AI 直接返回调用参数,由你的代码执行。缺点是Server 独立运行,客户端通过协议调用
- 生态:各家 API 格式不统一。缺点是统一标准,跨平台
Function Calling 更像是"AI 告诉你想调什么函数、传什么参数",具体执行还是你的代码来做。而 MCP 是一个独立的服务进程,AI 通过标准协议直接跟它通信。
两者不是替代关系,更像是不同层次的东西。Function Calling 是模型层的能力,MCP 是应用层的协议。
实际用起来是什么体验
说了这么多理论,实际用起来是什么感觉?
我目前在用的 MCP Server 组合:
- 文件系统:让 AI 能读写项目文件
- GitHub:查看 Issue、做 Code Review
- Brave Search:搜索技术文档
日常开发流程大概是这样的:
- 我告诉 AI:"帮我看一下这个 Issue,分析一下问题出在哪"
- AI 通过 GitHub MCP Server 读取 Issue 内容
- 通过文件系统 MCP Server 读取相关代码
- 分析完给出修改建议,甚至直接改代码
- 我确认后,AI 可以通过 GitHub MCP Server 提交 PR
整个过程我只需要用自然语言描述需求,AI 自己决定调用哪些工具。这比手动一个个去操作效率高太多了。
当然,现在还不完美。有时候 AI 会搞不清该用哪个工具,或者调用参数填错。但整体方向是对的,而且随着模型能力的提升,这些问题会越来越少。
要不要现在就上 MCP
我的建议是:如果你在用 AI编程工具深度实战对比(Claude Code、Cursor、Hermes 之类的),现在就可以开始玩 MCP 了。不需要一口气配很多,先从文件系统和搜索这两个最实用的开始。
如果你是工具开发者,考虑给你的工具做个 MCP Server。现在 MCP 生态还在早期,先入场的工具更容易被发现和使用。
如果你只是偶尔用 AI 聊聊天、写写文章,MCP 对你来说可能没那么紧迫。它主要解决的是 AI 和外部工具集成的问题,纯聊天场景用不上。
后面打算折腾的
我后面打算写一篇更实战的文章,手把手教怎么从零写一个有用的 MCP Server,比如对接一个常用的第三方 API。到时候再聊。
另外 MCP 的安全机制也值得深入研究,毕竟让 AI 有能力操作外部系统,安全问题不能忽视。这个坑先挖着,后面填。
有啥问题评论区聊,如果你也在玩 MCP,欢迎分享你的配置和踩坑经历 😄