如果你做过 AI 应用，一定经历过这样的痛苦：想让模型读取数据库，得自己写一套对接代码；想让它操作文件系统，又得写一套；接 GitHub、接 Slack、接内部 API……每接一个工具，都要从头定制一遍接口、处理一遍鉴权、维护一份脱节的文档。N 个模型 × M 个工具，最终演变成 N×M 的集成噩梦。MCP（Model Context Protocol，模型上下文协议） 正是为了终结这种重复劳动而生——它被广泛比喻为”AI 世界的 USB-C”：定义一套标准接口，让任何模型都能用同一种方式连接任何工具与数据源。本文带你从”它是什么、为什么出现”一路讲到”如何用现成的 Server、如何写一个自己的 Server、如何在 Claude Desktop / Cursor / Claude Code 里配置”，并覆盖安全与生态现状，让你真正具备 MCP 开发的入门能力。
一、MCP 是什么
MCP 是由 Anthropic 在 2024 年底提出、并迅速被整个行业采纳的一个开放标准。它的底层是 JSON-RPC 2.0 协议，目标只有一个：给”大模型应用”和”外部能力（工具、数据、提示模板）”之间，定义一套统一的通信规范。在它出现之前，每个 AI 应用都在用自己私有的方式去”喂”上下文、去”接”工具；MCP 出现之后，只要工具方实现了一个符合 MCP 规范的服务，任何支持 MCP 的 AI 应用都能即插即用地连上它。
2025 年 11 月的新版规范进一步引入了 Streamable HTTP 传输，使 MCP Server 可以作为远程服务运行；而在 2025 年 12 月，Anthropic 将 MCP 捐赠给 Linux 基金会旗下的 Agentic AI Foundation，使其成为真正厂商中立的行业标准。到 2026 年，社区数据显示 SDK 累计下载量已超 9700 万次，GitHub 上的 MCP Server 超过 1.3 万个，连 Gartner 都预测年底将有 75% 的 API 网关厂商内建 MCP 支持。这意味着学 MCP 不再是”尝鲜”，而是一项实打实的工程技能。
二、为什么需要 MCP：从 N×M 到 N+M
理解 MCP 的价值，关键在于看清它解决的”组合爆炸”问题。假设你有 N 个 AI 应用（不同的客户端、不同的模型），要接 M 个工具（数据库、文件系统、各种 API）。在没有标准的世界里，每个应用都要为每个工具单独写适配代码，总工作量是 N×M，而且每次工具升级、每个应用各自维护，难以收敛。
MCP 把这件事拆成两半：工具方只需实现”一个 MCP Server”（成本是 M），应用方只需实现”一个 MCP Client”（成本是 N），两边在中间用统一协议握手。集成的总复杂度从 N×M 降到了 N+M。这正是 USB-C 类比的精髓——你不必为每个设备配一根专用线，只要大家都遵守同一个接口标准，任意两端就能互通。对开发者而言，这带来三个直接好处：复用（一个 Server 服务所有客户端）、解耦（工具实现与模型实现互不依赖）、生态（你可以直接拿别人写好的 Server 用，而不必重造轮子）。
三、核心架构：Host、Client、Server
MCP 采用经典的客户端-服务器架构，但区分了三个角色，初学者最容易混淆，务必理清：
- Host（宿主）：你直接交互的 AI 应用本身，比如 Claude Desktop、Cursor、VS Code、Claude Code。它负责管理与用户的对话，并决定连接哪些 MCP Server。
- Client（客户端）：Host 内部的”连接器”组件。每个 Client 只负责管理与一个 Server 的连接——包括能力协商、工具发现、请求转发。当 Host 启动时，会为每个配置好的 Server 各创建一个 Client。所以一个 Host 可以同时连接几十个 Server。
- Server（服务端）：一个轻量程序，对外暴露具体的能力（工具、资源、提示）。比如”文件系统 Server”暴露读写文件的能力，”GitHub Server”暴露查 issue、提 PR 的能力。它是你作为开发者最常要去写的部分。
它们的关系可以这样理解：Host 是整台电脑，Client 是电脑上的一个个 USB 端口，Server 则是插上去的各种外设。一个端口对一个外设，互不干扰；而所有外设都遵守同一个 USB 标准，所以电脑不必为每个外设装专用驱动。
四、三类核心能力：Tools、Resources、Prompts
MCP 规范只定义了三种”原语”（primitive），刻意保持精简。理解这三者的区别，是用好 MCP 的关键：
- Tools（工具）：模型可以主动调用的函数，会产生动作或副作用。比如”查询数据库””发送邮件””调用某个 API””执行一段计算”。这是最常用的能力，本质上是把”模型能做什么”标准化。
- Resources（资源）：模型可以读取的只读数据源，用 URI 标识。比如某个文件的内容、某条数据库记录、某个配置。它提供的是”上下文”，而不是动作。资源由应用决定如何使用，通常不会被模型自动触发。
- Prompts（提示模板）：预定义的、可复用的提示词模板，通常由用户主动选用，用来引导某类工作流。比如一个”代码审查”模板、一个”总结会议记录”模板。它让常用的提示工程沉淀下来、可被一键调用。
一个常见的判断方法：要让模型”做事”，用 Tools；要给模型”看数据”，用 Resources；要给用户”一键套用的提示”，用 Prompts。绝大多数入门项目，先把 Tools 写明白就够了。
五、传输方式：stdio 与 HTTP
Host 和 Server 之间靠”传输层”通信，MCP 主要支持两种，承载的都是同样的 JSON-RPC 消息：
- stdio（标准输入输出）：Server 作为一个本地子进程运行，Host 通过它的标准输入/输出来收发消息。这是本地开发和桌面应用的默认选择，配置简单、延迟低、无需网络，适合”Server 跑在用户自己机器上”的场景（如访问本地文件、本地数据库）。
- Streamable HTTP：Server 作为一个远程 HTTP 服务运行，Host 通过 HTTP 请求连接。它是 2025 年 11 月新规范引入的，取代了早期的 SSE 传输，适合把 Server 部署成云端服务、供多个用户/团队共享，需要配合鉴权与权限控制。
选择原则很直接：自己电脑上用、访问本地资源，选 stdio；要做成给多人用的远程服务，选 HTTP。入门阶段，建议从 stdio 起步，调通后再考虑远程化。
六、直接用现成的 MCP Server
MCP 最大的红利之一，是有大量现成 Server 可以拿来即用，你不必自己实现。官方与社区维护了文件系统、GitHub、PostgreSQL、SQLite、Google Drive、Slack 等大量 Server。使用它们通常只需要在 Host 的配置文件里加几行。以”文件系统 Server”为例，常见的配置长这样（以 Claude Desktop 为例，配置文件 claude_desktop_config.json）：
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/you/Documents",
"/Users/you/Projects"
]
}
}
}这段配置的含义是：让 Host 用 npx 启动官方文件系统 Server，并把它的访问范围限定在 Documents 和 Projects 两个目录。重启 Host 后，模型就能读写这两个目录里的文件了。连数据库、连 GitHub 也是类似套路——换成对应的 Server 包名，再通过环境变量传入连接串或令牌。例如 GitHub Server 通常需要在配置里通过 env 注入一个 GITHUB_TOKEN。先学会”用别人的 Server”，能让你最快感受到 MCP 的威力。
七、动手：写一个属于自己的 MCP Server
当现成 Server 满足不了需求时，就该自己写。官方提供了多语言 SDK，Python 生态里最流行的是 FastMCP（FastMCP 3.0 于 2026 年 1 月发布，仅 3.0 beta 阶段下载量就超过 10 万次）。它的核心理念非常优雅：用一个装饰器把普通 Python 函数变成 MCP 工具，类型注解会自动转换成 JSON Schema，参数校验和协议合规全自动处理。先安装：
pip install "mcp[cli]"
# 或用 uv：uv add "mcp[cli]"下面是一个最小可用的 Server，暴露一个”加法”工具和一个”天气查询”工具：
from mcp.server.fastmcp import FastMCP
# 给 Server 起个名字
mcp = FastMCP("我的第一个 MCP Server")
@mcp.tool()
def add(a: int, b: int) -> int:
"""把两个整数相加并返回结果。"""
return a + b
@mcp.tool()
def get_weather(city: str) -> str:
"""查询指定城市的当前天气（示例：实际可在此调用真实天气 API）。"""
# 真实场景里，这里应当请求一个天气服务并返回结构化结果
return f"{city} 当前晴，气温 22℃"
if __name__ == "__main__":
# 以 stdio 方式运行，供本地 Host 连接
mcp.run(transport="stdio")这段代码值得逐点拆解，因为它体现了 MCP 开发的精髓：
- 函数即工具：
@mcp.tool()装饰器把普通函数注册为 MCP 工具，模型可以调用它。 - 类型注解即 Schema：参数的类型标注（如
a: int）会被自动转成 JSON Schema，模型据此知道该传什么参数、什么类型。 - 文档字符串即说明：函数下方的 docstring 会变成工具的描述，模型靠它判断”什么时候该调用这个工具”。写清楚 docstring 极其重要——它直接决定模型能否正确选用工具。
- 运行即服务：
mcp.run(transport="stdio")把它启动为一个 stdio Server。
写完后，把它接进 Host 的方式和用现成 Server 一样——在配置里用 command 指向 python、args 指向你的脚本路径即可：
{
"mcpServers": {
"my-server": {
"command": "python",
"args": ["/绝对路径/my_server.py"]
}
}
}调试阶段，强烈建议用官方的 MCP Inspector 工具单独连上你的 Server，逐个测试工具能否被正确发现和调用，再接进真实 Host，能省下大量排错时间。
八、MCP 与 Function Calling 的关系
很多人会问：模型本来就有 Function Calling（函数调用 / Tool Use）能力，为什么还要 MCP？两者并不冲突，而是不同层次的东西。
Function Calling 是”模型层”的能力：模型在生成时输出一个”我要调用某函数、参数是这些”的结构化意图，但函数是谁定义的、怎么执行、执行环境在哪，完全由你的应用代码自己处理，每个应用各写各的。MCP 是”集成层”的标准：它规定了工具如何被描述、发现、调用、传输，让工具的定义和执行可以从应用里抽离出来，变成可复用、可共享的独立 Server。
打个比方：Function Calling 是模型”会用工具”这件事本身，MCP 则是”工具该长什么样、插在哪、怎么对接”的统一规范。实际运行时，Host 从各个 MCP Server 发现工具清单，把它翻译成模型能理解的工具定义，模型用 Function Calling 决定调哪个、传什么参数，Host 再通过 MCP 把调用转发给对应 Server 执行，结果回传给模型。可以说 MCP 站在 Function Calling 的肩膀上，把”工具从哪来”这件事标准化了。
九、在主流工具里配置 MCP
不同 Host 的配置位置略有差异，但思路一致——都是声明”用什么命令启动哪个 Server”：
- Claude Desktop：编辑
claude_desktop_config.json（macOS 在~/Library/Application Support/Claude/下），在mcpServers字段里添加 Server，重启应用生效。 - Cursor：在设置里找到 MCP 配置，或在项目根目录放
.cursor/mcp.json，格式与上面基本一致。 - Claude Code：用命令行添加，例如
claude mcp add这类命令，或编辑其配置文件；它支持把 Server 配置在用户级或项目级，团队可把项目级配置提交进仓库共享。
无论哪个 Host，配置完成后都建议先在界面里确认”工具已被识别”（通常会显示已连接的 Server 与可用工具列表），再让模型实际去调用，确保链路通畅。
十、安全注意事项
MCP 让模型获得了操作真实世界的能力，安全因此变得格外重要。开发和使用时务必注意：
- 最小权限原则：给 Server 的访问范围越小越好。比如文件系统 Server 只开放必要目录，数据库账号只给只读或受限权限，避免模型误操作或被诱导造成破坏。
- 谨慎对待第三方 Server：装一个 MCP Server 等于在你机器上运行别人的代码。只用可信来源的 Server，安装前看清它要什么权限、连什么外部地址，警惕”工具投毒”（恶意 Server 在工具描述里夹带诱导指令）。
- 密钥与令牌管理：连数据库、连 GitHub 用到的密钥应通过环境变量注入，绝不硬编码进代码或提交进仓库。
- 人工确认高危操作：删除文件、发送消息、改动生产数据等不可逆操作，应保留人工审批环节，而非让模型全自动执行。
- 远程 Server 要鉴权：用 HTTP 传输对外提供服务时，必须加上身份认证与授权，不要裸奔暴露在公网。
十一、生态现状与展望
到 2026 年，MCP 已从一个公司的提案成长为厂商中立的开放标准：被捐给 Linux 基金会，主流 AI 编程工具（Claude Desktop、Cursor、VS Code、Claude Code 等）普遍支持，社区 Server 数量过万，覆盖数据库、云服务、协作工具、浏览器自动化等方方面面。它正在成为”AI 应用接入外部世界”的事实基础设施。对开发者来说，这意味着两个机会：一是把你已有的系统包成 MCP Server，让它能被各种 AI 应用调用；二是构建以 MCP 为核心的 Agent 应用，把多个 Server 组合起来完成复杂任务。
十二、常见问题（FAQ）
Q：MCP 会取代 API 吗？不会。MCP 不是要替代 REST/HTTP API，而是在 API 之上加一层”面向 AI 的标准适配”。很多 MCP Server 内部其实就是在调用现有 API，只是把它包成了模型友好的工具。
Q：必须用 Python 才能写 Server 吗？不是。官方提供了 Python、TypeScript 等多语言 SDK，选你最熟的即可，本文用 Python 只是因为它入门最快。
Q：模型没有调用我写的工具怎么办？最常见原因是工具的 docstring/描述写得不清楚，模型不知道何时该用。把描述写得更具体、说明适用场景，往往就能解决。其次检查 Server 是否被 Host 正确识别。
Q：stdio 和 HTTP 能混用吗？一个 Host 可以同时连多个 Server，有的走 stdio（本地），有的走 HTTP（远程），互不影响。
总结来说，MCP 用一套精简的标准（三类能力、两种传输、三个角色），把”AI 与工具对接”这件原本一团乱麻的事变得像插 USB-C 一样简单。入门路径也很清晰：先用现成 Server 体会价值，再用 FastMCP 写一个自己的工具，最后接进 Claude Desktop / Cursor / Claude Code 跑通全链路，并始终把安全放在心上。掌握了 MCP，你就给自己的 AI 应用装上了一个能不断扩展的”标准化工具插座”。延伸阅读可参考 MCP 官方文档 与 MCP Python SDK。
相关文章
