xodo pdf
64.07MB · 2025-11-06
想象一下，当你使用 Claude 或 ChatGPT 这样的 AI 助手时，它们只能基于已有的知识来回答问题。但如果能让这些 AI 助手访问你的本地文件、查询数据库、甚至调用各种 API，那会怎样？这就是 Model Context Protocol (MCP) 要解决的问题。
MCP 是 Anthropic 推出的一个开源标准协议，它为 AI 应用提供了一种统一的方式来连接外部系统和数据源。通过 MCP，AI 应用可以轻松地访问本地文件、数据库、API 服务等各种资源，这大大拓展了 AI 的应用边界。
如果用一个比喻来解释，MCP 就像是 AI 应用的 USB-C 端口。就像 USB-C 为各种电子设备提供了统一的连接标准一样，MCP 也为 AI 应用与外部系统的连接提供了统一的规范。
在 MCP 出现之前，AI 应用的集成是一件非常繁琐的事情。每个 AI 应用都需要为不同的数据源和工具开发定制化的接口，这不仅导致了大量重复劳动，还使得切换 AI 应用变得困难。
MCP 的出现带来了三大优势：
统一的接口标准。有了 MCP，开发者只需要实现一次集成，就能让所有支持 MCP 的 AI 应用使用。这大大降低了开发成本和维护难度。
灵活性和可移植性。你可以轻松地在不同的 AI 应用之间切换，而不用担心供应商锁定。不管是 Claude、ChatGPT 还是其他 AI 助手，只要它们支持 MCP，就能使用相同的集成。
更好的安全控制。通过 MCP，数据可以在你自己的基础设施中处理，你对数据流向有完全的控制权。这对于处理敏感数据的企业场景尤其重要。
MCP 的应用场景非常广泛。你可以让 AI 助手访问本地文件系统，帮助你整理文档或分析代码；可以连接企业数据库，让 AI 直接查询和分析数据；还可以集成各种第三方 API，让 AI 获得搜索、翻译、天气查询等能力。
更进一步，你还可以为特定领域开发定制工具，构建复杂的工作流自动化。无论是代码开发、数据分析还是内容创作，MCP 都能为 AI 应用提供强大的扩展能力。
参考资料：
了解了 MCP 的概念后，让我们来实际体验一下。目前已经有不少 AI 应用支持 MCP 协议，包括 Anthropic 的 Claude Desktop、流行的 AI 代码编辑器 Cursor、高性能编辑器 Zed，以及 VS Code 和 JetBrains 系列 IDE（通过扩展支持）。甚至 ChatGPT 也开始提供部分 MCP 支持。
这里我们以 Claude Desktop 为例，演示如何配置一个本地文件系统服务器。这个例子非常实用——配置完成后，Claude 就能直接访问你指定目录下的文件，帮你分析代码、整理文档或执行各种文件操作。
首先，确保你已经安装了 Claude Desktop 应用和 Node.js（v18 或更高版本）。然后通过 npm 安装官方提供的文件系统服务器：
npm install -g @modelcontextprotocol/server-filesystem
接下来，我们需要编辑 Claude Desktop 的配置文件。在 macOS 上，这个文件位于 ~/Library/Application Support/Claude/claude_desktop_config.json；在 Windows 上则是 %APPDATA%Claudeclaude_desktop_config.json。打开配置文件，添加如下内容：
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/path/to/allowed/directory"
]
}
}
}
记得将 /path/to/allowed/directory 替换成你想让 Claude 访问的实际目录路径。出于安全考虑，建议只授权必要的目录。
保存配置文件后，重启 Claude Desktop。现在，Claude 就能浏览你的文件和目录、读取文件内容、创建和修改文件，甚至在整个文件系统中搜索了。你可以尝试让 Claude 帮你分析某个项目的代码结构，或者整理某个文件夹下的文档。
除了文件系统服务器，官方还提供了一系列开箱即用的 MCP 服务器。比如 github 服务器可以让 AI 直接操作 GitHub 仓库，postgres 和 sqlite 服务器支持数据库查询和操作，fetch 服务器允许 AI 发起 HTTP 请求，git 服务器则提供了完整的 Git 操作能力。所有这些服务器都可以通过 npm 轻松安装，包名都是 @modelcontextprotocol/server-* 的格式。
社区也贡献了许多实用的 MCP 服务器。Sentry 服务器提供了错误追踪和监控功能，Brave Search 服务器让 AI 能够进行网络搜索，Google Drive 和 Slack 服务器则分别实现了云端文件访问和团队协作功能。甚至还有 Jira 服务器，可以让 AI 帮助你管理项目任务。这个生态系统正在快速发展，每天都有新的服务器出现。
要真正理解 MCP 的强大之处，我们需要深入了解它的架构设计。MCP 采用了一个经过精心设计的三层架构：主机（Host）-客户端（Client）-服务器（Server）。这种架构不仅保证了灵活性，也确保了安全性。
┌────────────────────────────────────┐
│ 应用主机进程 (Host) │
│ ┌─────────┬─────────┬─────────┐ │
│ │Client 1 │Client 2 │Client 3 │ │
│ └────┬────┴────┬────┴────┬────┘ │
└───────┼─────────┼─────────┼────────┘
│ │ │
↓ ↓ ↓
Server 1 Server 2 Server 3
(本地) (本地) (远程)
在 MCP 架构中，有三个关键角色，它们各司其职却紧密协作。
**Host（主机）**是整个系统的协调者。它就是你正在使用的 AI 应用，比如 Claude Desktop 或 VS Code。Host 负责创建和管理多个客户端实例，控制连接权限，执行安全策略，并且协调 AI 模型的调用。你可以将它看作一个智能管家，统筹着所有资源和服务。
**Client（客户端）**是 Host 与各个 Server 之间的桥梁。每个 Client 由 Host 创建，专门用于维护与一个 Server 的连接。这种 1:1 的对应关系非常重要——它确保了每个服务器的独立性和安全性。Client 负责协议协商、消息路由、订阅管理等具体通信工作。重要的是，不同 Client 之间是完全隔离的，一个服务器的问题不会影响到其他服务器。
**Server（服务器）**是实际提供能力的地方。每个 Server 专注于特定的领域，比如文件系统访问、数据库查询或 Git 操作。Server 通过 MCP 的核心原语（Resources、Tools、Prompts、Sampling）来暴露功能。它可以是本地运行的进程，也可以是远程的云服务，这种灵活性使得 MCP 能够适应各种场景。
MCP 的协议设计非常优雅，它分为两个层次，每个层次都有明确的职责。
数据层基于成熟的 JSON-RPC 2.0 协议，定义了消息的结构和语义。这一层负责所有的业务逻辑，包括连接的初始化、能力协商和终止。它定义了服务器端的功能（Resources、Tools、Prompts）、客户端的能力（Sampling、Logging），以及进度跟踪和实时通知等辅助功能。
传输层则负责具体的通信机制。它支持两种传输方式：Stdio 和 Streamable HTTP。Stdio 适用于本地进程间通信，零网络开销，非常高效；Streamable HTTP 则用于远程服务器，支持标准的 HTTP 认证机制，如 OAuth、Bearer Token 等。这种分层设计的好处在于，你可以根据实际场景选择最合适的传输方式，而不用修改上层的业务逻辑。
一个典型的 MCP 通信流程是这样的：首先，Host 创建一个 Client，然后 Client 与 Server 建立连接。连接建立后，双方会进行初始化和能力协商，确定彼此支持的功能。之后就进入正常的数据交换阶段，可以调用 Resources、Tools、Prompts，甚至进行 Sampling 和实时通知。最后，当不再需要时，优雅地终止连接。
这种架构的扩展性也值得一提。在水平方向，一个 Host 可以连接任意数量的 Server，这意味着你可以同时使用文件系统、数据库、Git 等多个服务。在垂直方向，每个 Server 可以提供多种 Resources、Tools 和 Prompts，功能非常丰富。每个 Server 都是模块化的，专注于特定领域，新的 Server 可以像插件一样轻松集成。
了解了 MCP 的架构设计后，让我们来看看一个 MCP 连接是如何建立和运作的。MCP 定义了一个严格的生命周期，确保每个连接都能正确地初始化、运行和关闭。这个生命周期分为三个阶段。
初始化阶段是整个连接的基础。在这个阶段，Client 和 Server 互相介绍自己，并且协商彼此支持的功能。这个过程就像两个人初次见面时的自我介绍——互相了解对方的能力和限制，从而能够更好地协作。
具体来说，Client 首先发送一个 initialize 请求，告诉 Server 自己支持的协议版本和能力。Server 收到后会响应，同样报告自己的版本和能力。最后，Client 发送一个 initialized 通知，表示初始化完成，可以开始正式工作了。
这里是一个初始化请求的示例：
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2024-11-05",
"capabilities": {
"roots": { "listChanged": true },
"sampling": {},
"elicitation": {}
},
"clientInfo": {
"name": "ExampleClient",
"version": "1.0.0"
}
}
}
Server 的响应也类似，会告诉 Client 自己支持的功能：
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2024-11-05",
"capabilities": {
"logging": {},
"prompts": { "listChanged": true },
"resources": { "subscribe": true, "listChanged": true },
"tools": { "listChanged": true }
},
"serverInfo": {
"name": "ExampleServer",
"version": "1.0.0"
}
}
}
初始化过程中最重要的是版本协商和能力协商。Client 会告诉 Server 自己支持的协议版本（当前是 2024-11-05），Server 如果支持就返回相同版本，如果不支持就返回自己支持的版本。Client 收到响应后决定是继续连接还是放弃。
能力协商则更加细致。Client 可能支持 sampling（调用 LLM）、roots（提供文件系统路径）等能力；Server 可能提供 resources（数据资源）、tools（可执行工具）、prompts（提示模板）等功能。双方通过协商确定彼此都支持哪些功能，从而避免调用不存在的功能。
初始化完成后，就进入了操作阶段。在这个阶段，Client 和 Server 可以自由地通信。Client 可以列出和调用 Server 提供的 Resources、Tools、Prompts；Server 可以发送通知、报告进度，甚至请求 Client 调用 LLM 进行 Sampling。这个阶段就是整个 MCP 连接的核心，所有的实际工作都在这里发生。
当不再需要连接时，双方会优雅地终止连接。这可能是 Client 主动断开（比如用户关闭了 AI 应用），也可能是 Server 主动断开（比如服务停止）。当然，网络错误或超时也会导致连接终止。MCP 设计了完善的生命周期管理，确保连接能够正常关闭，释放资源。
现在我们来看看 MCP 最核心的部分——四个基本原语（Primitives）。这四个组件是 MCP 的灵魂，它们共同构成了 AI 应用与外部世界交互的基础。有趣的是，这四个组件分别由不同的角色控制：
/help 这样的命令这种设计非常巧妙，它让不同角色各司其职，既保证了灵活性，又维持了合理的控制权限。
Resources 是 MCP 中最基础的组件，它们是服务器向 AI 提供的各种数据。你可以把 Resources 想象成 AI 的“参考资料”——比如一个文件的内容、一个数据库表的结构、或者一段 Git 提交历史。每个 Resource 通过一个唯一的 URI 来标识，就像网页的 URL 一样。
Resources 由应用控制，这意味着是 Host 决定什么时候、以什么方式把哪些 Resource 提供给 AI。这种设计让应用可以灵活地管理上下文，比如根据用户的当前任务智能地选择相关文件。
- 文本资源：文件内容、文档、配置文件
- 二进制资源：图片、数据文件
- 动态资源：数据库查询结果、API 响应
- 结构化数据：JSON、XML、数据库模式
文件系统访问
file:///path/to/document.txt
file:///project/src/main.py
数据库内容
db://localhost/schema/users
db://localhost/table/products
远程 API 数据
https://api.example.com/data
git://repo/commits
服务器必须声明 resources 能力：
{
"capabilities": {
"resources": {
"subscribe": true, // 支持订阅单个资源的变化
"listChanged": true // 支持资源列表变化通知
}
}
}
应用可以通过多种方式暴露资源：
客户端可以订阅资源更新：
1. 客户端订阅特定资源 URI
2. 资源内容发生变化
3. 服务器发送更新通知
4. 客户端获取最新内容
Tools 是 MCP 中最强大的组件。如果说 Resources 让 AI 能“看”，Tools 就让 AI 能“做”。通过 Tools，AI 可以执行各种操作：查询数据库、发送 HTTP 请求、写入文件、运行计算，甚至控制外部系统。
与 Resources 不同，Tools 由 AI 模型自主控制。当 LLM 分析用户请求后，它会决定需要调用哪些工具来完成任务。比如，如果你说“查询一下数据库中有多少用户”，LLM 会自动选择执行 SQL 查询的 Tool。这种自主性大大增强了 AI 的实用性。
- 数据库查询：SELECT、INSERT、UPDATE
- API 调用：REST API、GraphQL
- 文件操作：读取、写入、删除
- 计算功能：数学运算、数据处理
- 系统操作：执行命令、调用服务
数据库操作
{
"name": "query_database",
"description": "执行 SQL 查询",
"parameters": {
"query": "SELECT * FROM users"
}
}
API 调用
{
"name": "search_web",
"description": "搜索互联网",
"parameters": {
"query": "MCP protocol"
}
}
文件操作
{
"name": "write_file",
"description": "写入文件",
"parameters": {
"path": "/path/to/file",
"content": "..."
}
}
{
"capabilities": {
"tools": {
"listChanged": true // 支持工具列表变化通知
}
}
}
重要安全原则：
1. Server 注册工具
2. Client 发现可用工具
3. LLM 根据上下文决定调用哪个工具
4. 用户确认工具调用（可选但推荐）
5. Server 执行工具
6. 返回结果给 LLM
7. LLM 处理结果并响应用户
Prompts 是为用户准备的快捷方式。它们是预定义的交互模板，用户可以通过简单的命令或菜单选项来触发。想象一下，当你在聊天软件中输入 /analyze-code 或者点击“生成测试用例”这样的按钮，就会触发一个精心设计的提示词模板。
Prompts 由用户控制，这是它与 Tools 的关键区别。用户主动选择什么时候使用哪个 Prompt，而不是由 AI 自主决定。这种设计保证了用户对交互过程的控制权，同时又通过模板化提供了便利性。
- 命令模板：预定义的操作指令
- 对话模板：特定场景的对话框架
- 分析模板：数据分析的提示结构
- 创作模板：内容生成的指导框架
斜杠命令
/analyze-code - 分析当前代码
/write-tests - 生成测试用例
/explain-error - 解释错误信息
/refactor - 重构代码
菜单选项
- 代码审查
- 文档生成
- Bug 分析
- 性能优化建议
快捷操作
- 总结选中文本
- 翻译内容
- 改进写作
{
"capabilities": {
"prompts": {
"listChanged": true // 支持提示词列表变化通知
}
}
}
提示词可以接受参数进行定制：
{
"name": "analyze_code",
"description": "分析代码质量",
"arguments": [
{
"name": "file_path",
"description": "要分析的文件路径",
"required": true
},
{
"name": "focus_area",
"description": "关注领域（性能/安全/可读性）",
"required": false
}
]
}
典型的用户交互流程：
1. 用户浏览可用提示词
2. 选择特定提示词
3. 提供必要参数（如果需要）
4. 系统应用提示词模板
5. LLM 基于模板生成响应
Sampling 是 MCP 中最高级的组件，它允许服务器请求 Client 调用 LLM。听起来有点绕？让我解释一下：通常情况下，是 AI 调用 Server 的工具；但通过 Sampling，Server 可以反过来请求 Client 调用 AI 模型。
这种设计实现了非常强大的代理功能。比如，一个 Server 可以先读取一些数据，然后请求 LLM 分析这些数据，再根据分析结果决定下一步动作。这就像是嵌套的 AI 调用，让 MCP 能够处理复杂的多步骤任务。重要的是，Server 不需要自己持有 LLM API 密钥，这大大降低了安全风险。
嵌套 AI 调用
工具调用 → 请求 LLM 分析 → 基于分析结果决策
代理行为
服务器可以实现自主决策：
- 分析复杂数据
- 生成中间内容
- 多步骤推理
上下文增强
请求中可以包含 MCP 服务器的上下文：
- Resources 数据
- 其他工具的输出
客户端必须声明支持采样：
{
"capabilities": {
"sampling": {}
}
}
安全最佳实践：
1. Server 执行某个操作
2. Server 需要 LLM 能力（如分析、生成）
3. Server 通过 Client 发起采样请求
4. Client 征求用户同意（可选但推荐）
5. Client 调用 LLM
6. LLM 生成响应
7. Client 返回结果给 Server
8. Server 继续执行逻辑
用户请求：分析并优化代码
1. Tool: read_file → 读取代码
2. Sampling: 请求 LLM 分析代码问题
3. Tool: search_docs → 查找最佳实践
4. Sampling: 请求 LLM 生成优化方案
5. Tool: write_file → 应用优化（需用户确认）
这四个核心组件可以协同工作，创建强大的 AI 集成：
┌─────────────┐
│ 用户请求 │
└──────┬──────┘
↓
┌─────────────────────────────────────┐
│ Prompts: 用户选择特定的提示模板 │
└──────┬──────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Resources: 加载相关上下文数据 │
└──────┬──────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ LLM: 处理并决定需要的操作 │
└──────┬──────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Tools: 执行具体操作 │
└──────┬──────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ Sampling: 需要进一步分析时递归调用 │
└──────┬──────────────────────────────┘
↓
┌─────────────┐
│ 返回结果 │
└─────────────┘
了解了 MCP 的核心组件后，让我们来看看它在实际工作中怎么应用。MCP 的应用场景非常广泛，从代码开发到数据分析，从内容管理到 DevOps，几乎每个领域都能找到用武之地。
在软件开发领域，MCP 能极大提升效率。你可以构建一个代码分析服务器，通过 Resources 提供项目文件和依赖关系，通过 Tools 运行测试和 linter，通过 Prompts 提供代码审查模板。这样 AI 就能成为你的编程助手，帮助你分析代码质量、发现潜在问题、甚至自动重构。
版本控制集成
MCP Server: Git 服务器
- Resources: 提交历史、分支信息
- Tools: git commit, git push, merge
- Prompts: 提交消息模板、PR 描述
对于数据分析师来说，MCP 可以是一个改变游戏规则的工具。通过连接 PostgreSQL 或 SQLite 服务器，你可以让 AI 直接与数据库对话。AI 能够查看表结构、执行复杂查询、导出数据，甚至生成可视化报表。这意味着你可以用自然语言提问，AI 会自动翻译成 SQL 并执行。
API 数据访问
MCP Server: REST API 服务器
- Resources: API 文档、数据模型
- Tools: HTTP GET/POST/PUT/DELETE
- Prompts: API 请求模板
MCP 对内容创作者和知识管理者也非常有用。你可以构建一个文档管理系统，让 AI 访问你的知识库、创建和编辑文档、进行全文搜索。或者集成 Google Drive、Dropbox 等云存储服务，让 AI 帮助你组织文件、生成摘要、甚至自动分类内容。
云存储集成
MCP Server: Google Drive/Dropbox
- Resources: 云端文件列表
- Tools: 上传/下载文件、共享链接
- Prompts: 文件组织建议
日志分析
MCP Server: Sentry/Logging 服务器
- Resources: 错误日志、性能指标
- Tools: 查询日志、创建告警
- Prompts: 问题诊断模板
部署管理
MCP Server: CI/CD 集成
- Resources: 部署状态、构建历史
- Tools: 触发部署、回滚版本
- Prompts: 部署检查清单
项目管理
MCP Server: Jira/Linear 服务器
- Resources: 任务列表、项目状态
- Tools: 创建任务、更新状态
- Prompts: 任务描述模板
通讯集成
MCP Server: Slack/Teams 服务器
- Resources: 频道消息、团队信息
- Tools: 发送消息、创建频道
- Prompts: 通知模板
如果你想为自己的场景开发一个 MCP 服务器，其实并不复杂。Anthropic 提供了完善的 SDK，让开发过程非常简单。这里是一个最小化的 TypeScript 示例，展示如何创建一个简单的 MCP 服务器：
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
// 创建服务器
const server = new Server(
{
name: "example-server",
version: "1.0.0",
},
{
capabilities: {
tools: {},
},
}
);
// 注册工具
server.setRequestHandler("tools/list", async () => {
return {
tools: [
{
name: "hello",
description: "Say hello",
inputSchema: {
type: "object",
properties: {},
},
},
],
};
});
server.setRequestHandler("tools/call", async (request) => {
if (request.params.name === "hello") {
return {
content: [
{
type: "text",
text: "Hello from MCP server!",
},
],
};
}
throw new Error("Unknown tool");
});
// 启动服务器
const transport = new StdioServerTransport();
await server.connect(transport);
MCP 支持多种编程语言，你可以根据自己的喜好选择。官方提供了 TypeScript/JavaScript、Python 和 Rust 的 SDK，安装和使用都非常方便。即使你使用其他语言，也可以直接实现 JSON-RPC 2.0 协议来开发 MCP 服务器。
作为一个开源协议，MCP 已经形成了一个活跃的生态系统。除了协议规范和各种语言的 SDK，还有丰富的开发工具和参考实现。官方维护着几个常用的 MCP 服务器，而社区也不断贡献着新的服务器和工具。
用于开发和调试 MCP 服务器的交互式工具。
安装：
npx @modelcontextprotocol/inspector
功能：
输入验证
权限控制
数据保护
错误处理
在使用 MCP 的过程中，你可能会遇到一些疑问。这里我们整理了几个最常见的问题，帮助你更好地理解和使用 MCP。
很多人会把 MCP 和传统的插件系统混淆。关键区别在于：传统插件紧耦合到特定应用，你需要为每个应用开发不同的插件；而 MCP 是一个标准化协议，一次开发就能让所有支持 MCP 的 AI 应用使用。这就像 USB 与各种专用接口的区别一样。
是的。MCP 支持两种传输方式：
远程服务器支持标准 HTTP 认证（OAuth、Bearer Token 等）。
安全是使用 MCP 时大家最关心的问题之一。好消息是，MCP 在设计之初就充分考虑了安全性。协议内置了能力协商机制，所有操作都由客户端控制，并且强烈建议采用“人工在环”模式，即关键操作需要用户确认。对于远程服务器，MCP 支持 OAuth 等成熟的认证机制。
不过，安全性最终还是取决于具体实现。作为开发者，你需要始终验证用户输入、实施适当的访问控制、并且对敏感操作要求用户确认。
开发 MCP 服务器时，调试是不可避免的。幸运的是，Anthropic 提供了一个非常好用的工具——MCP Inspector。只需运行 npx @modelcontextprotocol/inspector <your-server-command>，就能以交互式的方式测试你的服务器，查看消息交换、测试工具调用、监控日志输出。当然，你也可以使用传统的调试方法，比如查看日志或在 IDE 中设置断点。
MCP 对开发者非常友好，目前官方提供了 TypeScript/JavaScript、Python 和 Rust 三种语言的 SDK。这几乎覆盖了大部分常见的开发场景。社区也正在为 Go、Java、C# 等语言开发 SDK。即使你使用的语言没有现成的 SDK，也不用担心——MCP 基于 JSON-RPC 2.0 协议，任何支持 JSON-RPC 的语言都可以实现 MCP。
从理论上说，没有限制。MCP 的架构设计允许一个 Host 连接任意数量的 Server。每个 Server 都有自己独立的 Client，彼此之间完全隔离。
当然，实际中会受到一些现实因素的限制，比如系统的内存和 CPU 资源、网络连接数限制，以及 Host 应用自身的实现。但对于大多数场景，同时连接几十个 Server 完全不成问题。
协议本身没有规定速率限制。
但是：
对于一些耗时的操作，比如处理大文件或执行复杂计算，MCP 提供了 Progress 机制。Server 可以定期发送进度更新，告诉 Client 当前完成的百分比。Client 则可以将这些信息展示给用户，比如显示一个进度条，或者提供取消按钮。这样用户就不会觉得程序卡死了，体验会好很多。
通过这篇文章，我们深入探讨了 Model Context Protocol (MCP) 的方方面面。从基本概念到实际应用，MCP 为 AI 应用提供了一个标准化、安全且灵活的方式来连接外部系统。无论你是想让 AI 助手访问本地文件、查询数据库，还是集成各种第三方服务，MCP 都能提供一个统一的解决方案。
MCP 的真正价值在于它打破了传统的壁垒——你不再需要为每个 AI 应用重复开发相同的集成。一次开发，处处使用。随着越来越多的 AI 应用和开发者加入这个生态系统，MCP 正在成为连接 AI 与现实世界的标准桥梁。
如果你对 MCP 感兴趣，最好的开始方式就是动手实践。安装 Claude Desktop，配置一个文件系统服务器，亲身体验 MCP 带来的便利。然后，你可以尝试开发自己的 MCP 服务器，为 AI 应用添加独特的能力。
参考资源：
