$catMANUAL||~17 min

MCP 到底是什么?一个全栈开发者的实战理解

advertisement

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 能查天气:

code
1
Claude Code → 写一个 Skills 配置 → 调天气 API
2
Cursor → 写一个 .cursorrules → 调天气 API
3
Hermes → 写一个插件 → 调天气 API

三套代码,三个配置,三份维护。

有了 MCP 之后:

code
1
写一个天气 MCP Server → Claude Code / Cursor / Hermes 都能直接用

一次开发,所有支持 MCP 的客户端都能接入。

这对开发者来说意味着什么?你写一个 MCP Server,你的工具就能被所有支持 MCP 的 AI 产品使用。生态效应一下子就起来了。

MCP Server 长什么样

说一千道一万不如看看代码。MCP Server 其实挺简单的,我用 Python 给你写一个最基础的例子。

先装依赖:

bash
1
pip install mcp

然后写一个最简单的 MCP Server,提供一个"加法计算"的工具:

python
1
# mcp_demo.py
2
from mcp.server import Server
3
from mcp.server.stdio import stdio_server
4
from mcp.types import Tool, TextContent
5
 
6
app = Server("demo-calculator")
7
 
8
@app.list_tools()
9
async def list_tools():
10
    return [
11
        Tool(
12
            name="add",
13
            description="计算两个数的和",
14
            inputSchema={
15
                "type": "object",
16
                "properties": {
17
                    "a": {"type": "number", "description": "第一个数"},
18
                    "b": {"type": "number", "description": "第二个数"},
19
                },
20
                "required": ["a", "b"],
21
            },
22
        )
23
    ]
24
 
25
@app.call_tool()
26
async def call_tool(name, arguments):
27
    if name == "add":
28
        result = arguments["a"] + arguments["b"]
29
        return [TextContent(type="text", text=str(result))]
30
 
31
async def main():
32
    async with stdio_server() as (read_stream, write_stream):
33
        await app.run(read_stream, write_stream, app.create_initialization_options())
34
 
35
if __name__ == "__main__":
36
    import asyncio
37
    asyncio.run(main())

就这么几行代码,一个 MCP Server 就写好了。它提供了一个 add 工具,接收两个数字,返回它们的和。

当然这只是个 demo。实际场景中你可以对接任何东西:数据库、文件系统、API、甚至硬件设备。

配置文件怎么写

写好了 Server,怎么让 AI 工具找到它?通过配置文件。不同的客户端配置方式略有不同,但核心都是一样的:告诉客户端去哪里启动这个 Server。

以 Claude Code 为例,在项目根目录创建 .mcp.json

json
1
{
2
  "mcpServers": {
3
    "calculator": {
4
      "command": "python",
5
      "args": ["mcp_demo.py"]
6
    }
7
  }
8
}

Hermes Agent 的配置在 config.yaml 里:

yaml
1
mcp:
2
  servers:
3
    calculator:
4
      command: python
5
      args: [mcp_demo.py]

Cursor 的话在 .cursor/mcp.json 里配置,格式大同小异。

核心就一句话:告诉客户端用什么命令启动 Server。之后客户端会自动管理 Server 的生命周期——启动、通信、关闭,你都不用操心。

现成的 MCP Server 有哪些

自己写 Server 当然好,但更爽的是别人已经写好了。MCP 生态发展得很快,GitHub 上已经有大量现成的 MCP Server 可以直接用。

挑几个我觉得实用的:

文件系统(filesystem)

这个是最常用的。让 AI 能读写你本地的文件。

bash
1
npx -y @modelcontextprotocol/server-filesystem /path/to/allowed/dir

一行命令启动,AI 就能访问指定目录下的文件了。注意它有路径限制,不会让你随便访问整个硬盘,这点安全设计还是到位的。

数据库查询

有好几个数据库 MCP Server:

  • PostgreSQL@modelcontextprotocol/server-postgres
  • SQLite@modelcontextprotocol/server-sqlite
  • MySQL:社区实现的也有

配置好连接字符串,AI 就能直接帮你写 SQL、查数据、做分析。对于后端开发者来说这个太实用了。

Web 搜索

bash
1
npx -y @anthropic/server-brave-search

接上 Brave Search API,AI 就能搜索互联网了。不用再靠 AI 的"记忆"来回答问题,直接搜实时信息。

GitHub

bash
1
npx -y @modelcontextprotocol/server-github

让 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:搜索技术文档

日常开发流程大概是这样的:

  1. 我告诉 AI:"帮我看一下这个 Issue,分析一下问题出在哪"
  2. AI 通过 GitHub MCP Server 读取 Issue 内容
  3. 通过文件系统 MCP Server 读取相关代码
  4. 分析完给出修改建议,甚至直接改代码
  5. 我确认后,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,欢迎分享你的配置和踩坑经历 😄

advertisement

MCP 到底是什么?一个全栈开发者的实战理解 — AI Hub