← 返回文章列表

什么是 MCP

MCP（Model Context Protocol，模型上下文协议）是一种开放协议，用于标准化 AI 助手与外部数据和工具的连接方式。不必为每个服务（GitHub、数据库、CRM、文件系统）单独写集成，只需运行 MCP 服务器，客户端 - Cursor、Claude Desktop、Zed 等 - 即可通过统一契约连接。下文介绍 MCP 是什么、架构如何工作，以及该协议在生产环境中的价值。

通俗定义

Model Context Protocol 是 AI 应用（host）与外部上下文源（server）之间交换的规范。服务器可暴露：

  • Resources - 可读数据：文件、数据库行、API 文档
  • Tools - 模型可调用的操作：API 请求、SQL、索引搜索
  • Prompts - 面向常见场景的现成提示模板

协议开放，不绑定单一 LLM 厂商。host 选择模型；MCP 服务器选择提供哪些数据和工具。通信使用 JSON-RPC 2.0，传输方式为 stdio、HTTP 或 SSE。

Anthropic 的设想（2024 年 11 月）：用统一方式为智能体接入上下文，取代五花八门的自定义插件。

架构：host、client、server

典型的三角色结构：

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  MCP Host   │────▶│ MCP Client  │────▶│ MCP Server  │
│ (Cursor、   │     │ (应用内部)  │     │ (GitHub、   │
│  Claude 等) │     │             │     │  Postgres…) │
└─────────────┘     └─────────────┘     └─────────────┘
  • MCP Host - 带 LLM 的应用：IDE、聊天客户端、智能体平台。管理会话、调用模型，并决定何时调用 tool。
  • MCP Client - host 内通过 MCP 与一个或多个服务器通信的组件。
  • MCP Server - 暴露 resources、tools 和 prompts 的进程或服务。可本地（磁盘文件）或远程（企业 API）。

一个 host 可持有多个 client - 每个 MCP 服务器一个。例如在 Cursor 中，文件系统、浏览器、GitHub 及配置中的自定义 MCP 服务器可同时运行。

MCP 的实际价值

一份契约替代 N 套集成

MCP 之前，每个产品各自写连接器：各自的「读文件」「调 API」格式。MCP 统一规定：

  • 如何声明工具（名称、参数 schema、描述）
  • 如何返回结果
  • 如何请求 resources 及变更订阅

同一 PostgreSQL MCP 服务器可在支持该协议的 Claude Desktop 与其他 host 上复用。

安全与访问边界

服务器在独立进程或容器中运行。host 无法直接访问整个系统 - 只能访问服务器显式暴露的内容。对企业很重要：可给智能体只读访问数据集市，而不开放生产库全权限。

本地与云端场景

  • 本地 - stdio 传输：host 将服务器二进制作为子进程启动（常见于 IDE 与桌面客户端）。
  • 远程 - HTTP/SSE：团队共享的 VPN 或云端 MCP 服务器。

二者均在规范中；选择取决于安全策略与数据存放位置。

MCP 与 function calling

Function calling（tool use）是 LLM 侧机制：模型返回结构化请求「用参数 Y 调用函数 X」。MCP 是更底层、更广的层：标准化这些函数与数据的来源、注册方式，以及 host 如何与它们通信。

交互流程：

  1. host 连接 MCP 服务器并获取 tool 列表。
  2. 列表以提供商理解的格式传给模型（OpenAI tools、Anthropic tools 等）。
  3. 模型选择 tool；host 经 MCP client → server 执行调用。
  4. 结果回到模型上下文，进入下一步。

MCP 不替代模型推理 - 它统一智能体与外部世界之间的「接线」。

MCP 的应用场景

环境 MCP 角色
Cursor 内置与用户自定义 MCP 服务器：文件、终端、浏览器、第三方 API
Claude Desktop 通过 claude_desktop_config.json 的官方与社区服务器
Zed、Continue、Cline 编辑器中扩展上下文的 MCP 支持
企业智能体 基于内部 API、工单系统、wiki 的自有服务器

社区提供现成服务器：GitHub、Google Drive、Slack、Puppeteer、SQLite、Postgres、Brave Search 等，GitHub 上如 modelcontextprotocol/servers 等注册库中有数百个。

如何编写或连接 MCP 服务器

开发者最小路径：

  1. 选择 SDK：官方库支持 TypeScript、Python、C#、Java 等。
  2. 在服务器代码中描述 tools 与 resources（名称、inputSchema、handler）。
  3. 以 stdio 或 HTTP 传输启动服务器。
  4. 在 host 中添加配置（Cursor 中为 .cursor/mcp.json 或 IDE 设置）。

Python tool 逻辑示例（简化）：

@server.tool()
async def get_weather(city: str) -> str:
    """某城市当前天气。"""
    return await weather_api.fetch(city)

会话开始时 host 请求服务器 capabilities；模型看到带描述与 city 参数 JSON schema 的 get_weather。

无自研开发的团队通常使用注册库中的现成服务器，加上配置与密钥（API key 通过 env，勿写入仓库）。

局限与注意事项

MCP 解决的是连接标准化，而非：

  • 模型推理质量
  • 复杂多步工作流的编排（属智能体框架范畴）
  • 用户间授权（需在服务器上另建 OAuth/RBAC 层）

实践中需考虑：

  • 延迟 - 每次 tool call 都是往返；10+ 次调用链需时间与 token 预算。
  • 版本 - 服务器与 host 应对齐规范版本（2025-03 及更新版在持续演进）。
  • 可靠性 - MCP 服务器宕机会切断数据访问；生产环境需要健康检查与降级方案。

MCP 与 RAG、自定义 API 对比

方式 优势 劣势
MCP 面向任意 host 的标准 tools/resources 客户端须支持 MCP
RAG 在大语料中检索而无需全部载入上下文 无法执行任意操作（写入、API 变更）
自定义 API 完全控制 每个 AI 客户端重复开发

成熟系统常采用 MCP + RAG：RAG 处理文档知识，MCP tools 处理数据库、工单、部署等实时查询。

总结

MCP 是面向 AI 智能体的开放上下文协议：host 连接服务器，获取 resources 与 tools，模型通过统一契约调用它们。这可降低集成成本，便于在 Cursor、Claude Desktop 等客户端间迁移场景，并明确数据访问边界。

对开发者的实用顺序：先用社区服务器覆盖技术栈，当同一套 tools 需在多个 host 应用中使用時，再将内部 API 封装为自有 MCP 服务器。

常见问题

MCP 与普通 REST API 有何不同？

REST API 是某一服务面向 HTTP 调用的接口。MCP 是 AI host 与这类服务「适配器」之间的协议：规定 host 如何发现 tools、调用它们并以智能体友好格式读取 resources。一个 MCP 服务器可包装 GitHub 或 Jira 的 REST API；host 无需为每个产品单独写集成。

若只用一个聊天产品（如 ChatGPT），还需要 MCP 吗？

若全流程都在带内置插件的封闭产品内 - 不一定需要。MCP 在以下情况更有价值：使用多个 host（IDE + 桌面 + 自研智能体）、希望复用同一套 tools，或在自有服务器上以明确访问控制保管敏感数据。

将 MCP 服务器连接到工作数据是否安全？

取决于服务器与配置。可信的开源社区服务器、只读访问、通过环境变量管理密钥是基本底线。生产环境：独立进程、最小权限、审计 tool 调用，智能体写入须经人工确认。

能否与本地模型（Ollama、LM Studio）一起使用 MCP？

可以，前提是 host 同时支持 MCP 与本地提供商。MCP 不绑定云端 API - 它提供上下文与 tools；模型可以是本地的。限制在 host 侧：并非所有客户端都能同样好地结合本地 LLM 与完整 MCP tools。

如何在 Cursor 中开始配置 MCP？

  1. 打开 Cursor 的 MCP 设置（或项目中的 .cursor/mcp.json）。
  2. 按文档添加现成服务器（如 filesystem、GitHub），配置启动命令与 token 环境变量。
  3. 重启 Cursor，确认服务器状态为 connected。
  4. 在智能体聊天中明确要求使用某个 tool - 确认调用成功且结果出现在回复中。

下一步可为内部 API 添加一个自定义服务器 - 这样可理解完整循环，而无需为每个工具重写集成逻辑。

联系方式