从 Cursor 到 MySQL，MCP如何让 AI 真正“帮你干活”？

1 为什么需要MCP？

眼下，AI浪潮席卷而来，其势头颇有几分当年“互联网+”的影子。那时是互联网连接万物，如今轮到了AI。从医疗到购物，AI正试图与各行各业深度融合。

然而，大语言模型（LLM）的核心能力本质上是“生成文本”。它就像一个聪慧无比的大脑，却缺乏与真实世界交互的“手脚”。我们自然希望它能调用各种工具，去执行具体的任务。

麻烦随之而来：市面上AI模型众多（如ChatGPT、Gemini、Claude等），应用工具更是数不胜数（如MySQL、GitHub、各类IDE）。让AI与应用逐一适配？工程浩大，绝非良策。软件工程里有一句老话：“没有什么问题是加一个中间层解决不了的。”于是，设计一个通用的AI与应用程序交互协议，就成了顺理成章的思路。只要AI和应用都遵循这个协议，它们就能直接对话。这个协议，就是MCP。

2 MCP 是什么？

你可以把MCP想象成一本给AI看的“工具使用说明书”。我们想让AI拥有“手”和“脚”，但工具千差万别，AI必须清楚每个工具能干什么、怎么用。MCP通过三个核心概念解决了这个问题：Tools（工具）、Resources（资源）和Prompts（提示），分别对应“能做什么”、“有什么数据”以及“如何操作”。

这就像你新买了一台专业相机，不会用怎么办？你得先翻看说明书，了解它的功能（Tools）、自带的配件或配置（Resources），以及具体的操作步骤（Prompts）。

更规范地说，MCP解决的是LLM如何安全、标准化地调用外部能力的问题。它相当于为AI打造了一个通用的“USB接口”，是在AI与各类工具之间架起的一座标准化的桥梁。

3 实际使用中 MCP 是如何运行的？

我们以一个最常见的场景——代码生成为例，来拆解MCP的工作流程：

• 假设你正在使用Cursor（或通义灵码等AI编程助手），其背后调用的模型是ChatGPT，并且你已经安装并配置好了MySQL的MCP工具。
• 此时，你向Cursor发出指令：“查询数据库里Student表的结构，并据此创建实体类Student.ja va。”

接下来，整个代码生成流程便启动了：

1. Cursor收到你的指令，将其转发给背后的LLM（即ChatGPT）。
2. ChatGPT开始“思考”，它会拆解这个任务：首先需要获取Student表的结构，然后才能基于此创建Ja va实体类文件。
3. 虽然LLM自身不能直接执行这些动作，但它能做出判断：“查询表结构”需要调用外部数据库工具（SQL），“创建实体类文件”则需要操作文件系统或IDE工具。
4. 于是，ChatGPT开始执行流程。第一步，它会生成一个标准的MCP工具调用请求。这个请求本质上是一个结构化的JSON数据，包含了函数名和参数，类似于你直接调用API：MySQL.run_sql("DESCRIBE Student")。
5. ChatGPT将这个JSON请求发回给Cursor。Cursor内部集成了MCP Client（客户端），Client会找到对应的MCP Server（服务器，此处是MySQL服务），进行通信并执行SQL，然后将查询结果返回给ChatGPT。
6. ChatGPT拿到表结构后，就能生成对应的Ja va代码了。之后，它还可以继续调用其他工具，例如write_file，来最终完成文件的创建。

4 MCP 中各参与者的介绍

理清了流程，我们再来认识一下这场协作中的各位“角色”：

• Host（宿主，如Cursor）
  ：它是整个交互的承载环境，集成了LLM、MCP Client以及用户界面。

• LLM（如ChatGPT）
  ：核心的“决策者”，负责理解指令、规划步骤，并决定在何时调用哪个工具。

• MCP Client（客户端，集成在Host内）
  ：关键的“调度者”，它的职责包括：
  • 接收来自LLM的工具调用请求。
  • 找到与之对应的MCP Server。
  • 转发调用请求。
  • 将Server返回的结果传回给LLM。

• MCP Server（服务器，如MySQL服务）
  ：具体“能力提供方”，负责执行实际的操作（如运行SQL查询）。

• Tools / Resources
  ：由Server暴露出来的具体能力接口，例如前面提到的run_sql。