MCP 协议入门指南：让 AI 真正连上你的数据和工具

为什么所有人突然都在聊 MCP

2024年底 Anthropic 发布了一个叫 Model Context Protocol 的东西，简称 MCP。半年过去，Cursor、VS Code、Claude Desktop、ChatGPT 都接入了它，GitHub 上冒出上千个 MCP Server，连 HN 的热门榜隔三差五就有相关项目。一个协议能这么快被整个开发者社区接受，不算常见。

原因其实简单。大语言模型很强，但有个硬伤：它接触不到你的实际数据。你的代码仓库、数据库、文件系统、日历、API，模型都看不到。以前要打通这些，每个工具得单独写适配，工作量巨大还容易出 bug。MCP 做的事就是定一个统一标准，让任何 AI 应用都能通过同一套协议连接外部系统。

官方有个比喻我觉得挺到位：MCP 就是 AI 应用的 USB-C 接口。你不用关心连的是硬盘还是显示器，插上就行。

MCP 到底解决什么问题

先说个实际场景。假设你让 Claude Code 帮你改一个项目里的 bug，它需要读代码仓库、查数据库 schema、看 Git 历史。没有 MCP 的话，你得手动把这些信息复制粘贴给模型。如果项目稍微大一点，光是来回粘贴就够你忙活半小时。

有了 MCP，你在 Claude Desktop 的配置文件里加几行 JSON，它就能直接访问本地文件系统、查 Git 日志、连 PostgreSQL 读表结构。模型自己决定什么时候调用什么工具，整个过程你只需要给出需求描述。

这不是什么新概念，Function Calling 和 Tool Use 早就有了。区别在于标准化。Function Calling 每家厂商的格式不一样，OpenAI 一套写法，Anthropic 一套写法，Google 又一套。你写了一个工具适配 OpenAI，换到 Claude 就得重写。MCP 把这个层抽象出来了，写一次，到处跑。

核心概念拆解

MCP 的架构分两端：Client 和 Server。Client 跑在你的 AI 应用里（Claude Desktop、Cursor 等），负责发起请求。Server 是你配置的外部工具，负责响应。通信走的是 JSON-RPC，支持本地 stdio 和远程 HTTP 两种传输方式。

Server 可以提供三种能力：

Tools（工具）：让模型执行操作。比如查数据库、调 API、操作文件。这是最常用的类型，相当于给模型装了一双手。

Resources（资源）：给模型提供只读数据。比如一个配置文件、一段文档、一个 API 响应。模型不会修改它，只是读取作为上下文。

Prompts（提示词模板）：预设好的提示词，让用户一键触发特定任务。比如”审查这段代码的安全性”，背后的 prompt 模板由 Server 定义。

这三者不是必须全有。大部分 Server 只实现 Tools 就够用了。Resources 和 Prompts 是锦上添花。

实操：五分钟搭一个 MCP Server

官方提供了 10 种语言的 SDK，Python 和 TypeScript 用得最多。这里用 Python 做个最简单的例子。

先装依赖：

pip install mcp

然后写一个最小的 Server，暴露一个查天气的工具：

from mcp.server import Server import mcp.server.stdio from mcp.types import Tool, TextContent import asyncio

server = Server("weather-server")

@server.list_tools() async def list_tools(): return [Tool( name="get_weather", description="查询指定城市的天气", inputSchema={ "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"} }, "required": ["city"] } )]

@server.call_tool() async def call_tool(name, arguments): if name == "get_weather": city = arguments.get("city", "") # 这里换成实际的天气 API 调用 return [TextContent(type="text", text=f"{city}今天晴，25°C")]

async def main(): async with mcp.server.stdio.stdio_server() as (r, w): await server.run(r, w)

asyncio.run(main())

然后在 Claude Desktop 的配置文件里（~/Library/Application Support/Claude/claude_desktop_config.json，Windows 路径是 %APPDATA%\Claude\claude_desktop_config.json）加上：

{ "mcpServers": { "weather": { "command": "python", "args": ["/path/to/your/weather_server.py"] } } }

重启 Claude Desktop，它就能回答天气问题了。模型会自动判断什么时候调用这个工具。

整个流程的体验是：从写代码到模型用上工具，中间没有复杂的网络配置、没有 API Gateway、没有认证框架。这是 MCP 最讨喜的地方。

官方参考 Server 有哪些可以直接用

不想自己写的话，官方仓库里已经有不少开箱即用的 Server：

Filesystem：让模型读写本地文件。配置时指定允许访问的目录，模型只能在范围内操作。

Git：读取 Git 仓库的提交历史、分支信息、diff。配合 Claude Code 使用，模型能理解项目的版本控制上下文。

Memory：基于知识图谱的持久记忆。跨对话保存信息，解决”模型记不住上次说了什么”的老问题。

Fetch：抓取网页内容并转换成适合模型阅读的格式。比直接粘贴 URL 链接靠谱得多。

Sequential Thinking：让模型分步骤推理复杂问题。某种程度上是在 prompt 层面做思维链工程。

这些 Server 都能通过 npx 或 uvx 直接启动，不用全局安装。比如 Filesystem：

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

生态现状和我的判断

截至 2026 年中，MCP Registry 里已经收录了大量社区 Server。头部用例集中在几个方向：数据库查询（PostgreSQL、MySQL、SQLite）、代码托管平台（GitHub、GitLab）、项目管理（Linear、Jira）、文档协作（Notion、Google Drive）、消息平台（Slack、Discord）。

几个值得关注的趋势。

远程 Server 成了新的发力点。早期 MCP Server 基本都跑在本地，通过 stdio 通信。现在 Streamable HTTP 传输方式成熟了，Server 可以部署在云端，多个客户端共享。这对企业场景意义重大——IT 团队可以统一部署 MCP Server，员工各自连接。

MCP Registry 上线后，发现和安装 Server 的体验好了很多。以前你得在 GitHub 上手动找，现在类似 npm 的模式，一条命令就能装。当然 registry 的审核和安全管理还在完善中。

也有隐患。安全是最大的问题。给模型工具调用权限，意味着模型可以执行文件操作、数据库查询、API 调用。如果 Server 的权限控制没做好，一次幻觉就可能造成真实破坏。官方文档里反复强调了最小权限原则，但实际使用中多少人认真配置了权限边界，不好说。

另一个问题是性能。多轮工具调用会让对话 token 膨胀很快，尤其涉及大量文件或数据库返回的时候。本地模型的 context window 吃紧，这个问题会更明显。

该不该现在投入精力学 MCP

如果你是独立开发者或小团队，我的建议是：现在就开始。

理由很实在。第一，Claude Code、Cursor、VS Code Copilot 这些你已经用的工具都支持了 MCP，配置成本极低。第二，官方 Server 的覆盖面已经够广，就算不自己写 Server，把现成的接上也够用。第三，对于做 AI 应用的人来说，理解 MCP 架构已经成为基本素养，就像理解 REST API 一样。

如果你是企业 IT 负责人，可以观望一下安全框架和 registry 的成熟度。OAuth 2.1 的支持已经在推进中，企业级权限管理的规范也在讨论。

但有一点是确定的：工具调用协议的标准化已经在发生，MCP 目前是唯一的候选标准。没有竞争者。这意味着哪怕协议后续有变动，早期积累的经验也不会白费。