MCP：为什么 Agent 需要一个统一的外部能力协议

Tool Calling 解决了一个很重要的问题：让大模型能够根据用户的目标，决定什么时候调用外部工具，以及应该传入什么参数。

但 Tool Calling 解决的只是模型这一侧的问题。

当一个 Agent 真正进入工程系统之后，很快就会遇到另一个问题：每接入一个新的外部系统，都需要重新定义工具、编写适配代码、处理通信方式、权限认证和返回格式。如果 Claude、ChatGPT、Cursor、VS Code、内部 Agent 平台都需要访问 GitHub、数据库、文件系统、浏览器和企业 API，那么如果没有统一协议，每一个“AI 应用 × 外部系统”的组合都可能需要单独适配。

MCP，也就是 Model Context Protocol，解决的正是这一层问题。

MCP 并不是一种新的 Agent，也不是 Tool Calling 的替代品，而是一套用于连接 AI 应用和外部工具、数据与能力的标准协议。

截至 2026 年 9 月，MCP 当前稳定规范为 2026-07-28。这一版本进一步将 MCP 调整为更适合生产环境的无状态协议核心，并继续围绕 Tools、Resources、Prompts 等能力构建统一的 AI 应用接入方式。

为什么需要 MCP

假设现在要开发一个 Agent，它需要拥有下面这些能力：

查询 GitHub Issue
读取本地文件
搜索 Notion
执行数据库查询
访问浏览器
读取企业内部 API

一种最直接的实现方式，就是分别给每一个系统写 Tool：

search_github()
read_file()
search_notion()
query_database()
browse_web()
call_internal_api()

然后再把这些工具的 Schema 提供给模型。

对于一个小型项目，这完全没有问题。

真正的问题出现在规模扩大之后。

假设我们拥有三个 AI 应用：

Claude
Cursor
内部 Agent 平台

同时拥有五个外部系统：

GitHub
Notion
Database
Browser
Filesystem

如果每一个 AI 应用都直接适配每一个外部系统，就会逐渐形成：

Claude -> GitHub
Claude -> Notion
Claude -> Database
Claude -> Browser
Claude -> Filesystem

Cursor -> GitHub
Cursor -> Notion
Cursor -> Database
Cursor -> Browser
Cursor -> Filesystem

Agent Platform -> GitHub
Agent Platform -> Notion
Agent Platform -> Database
Agent Platform -> Browser
Agent Platform -> Filesystem

每一种连接都可能拥有不同的 Tool Schema、认证方式、通信协议和错误处理逻辑。

随着模型、Agent 平台和外部系统数量增加，集成复杂度会迅速上升。

MCP 希望把这个结构变成：

AI Application
      |
      v
 MCP Client
      |
      v
 MCP Protocol
      |
      v
 MCP Server
      |
      v
External System

外部系统只需要实现一套 MCP Server，支持 MCP 的 AI 应用就可以通过统一协议发现和使用它提供的能力。

因此，MCP 真正解决的问题可以概括为：

把“AI 应用如何接入外部系统”这件事情标准化。

MCP 的核心架构

MCP 中最重要的三个角色是：

Host
Client
Server

它们之间的关系可以表示为：

AI Application / Host
        |
        v
    MCP Client
        |
        v
   MCP Protocol
        |
        v
    MCP Server
        |
        v
External Tools / Data / Services

Host 是真正承载 AI 应用的程序，例如 IDE、桌面客户端、Agent 平台或者其他带有模型能力的软件。

MCP Client 运行在 Host 中，负责按照 MCP 协议与 MCP Server 通信。

MCP Server 则负责把某个外部系统的能力暴露出来，例如文件、数据库、GitHub、浏览器或者企业内部服务。

这里需要注意一个很容易混淆的问题：

并不是大模型直接连接 MCP Server。

真正进行 MCP 通信的是 Host 中的 MCP Client。Host 获取 MCP Server 提供的能力之后，再决定如何将这些信息提供给模型。

因此更准确的链路是：

User
-> Host
-> LLM
-> Tool Calling Decision
-> MCP Client
-> MCP Server
-> External System
-> MCP Server
-> MCP Client
-> Host
-> LLM
-> User

这也是理解 MCP 和 Tool Calling 关系的关键。

MCP Server 到底提供什么

很多人第一次接触 MCP 时，会把 MCP Server 理解成“一个提供 Tool 的服务器”。

这种理解并不完全错误，但并不完整。

当前 MCP Server 可以向 AI 应用暴露三类非常重要的能力：

Tools
Resources
Prompts

官方 TypeScript SDK 当前也直接围绕这三类核心能力构建 Server API。

它们解决的是三个不同的问题。

Tools

Tools 最容易理解，它表示 AI 可以执行的操作。

例如：

search_repository
create_issue
query_database
send_email
create_calendar_event

一个 GitHub MCP Server 可以暴露：

list_issues
get_issue
create_issue
search_code

一个数据库 MCP Server 可以暴露：

list_tables
describe_table
query_database

对于模型来说，这些最终仍然表现为可调用工具。

例如：

{
  "name": "query_database",
  "description": "Execute a read-only database query",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": {
        "type": "string"
      }
    },
    "required": ["sql"]
  }
}

模型可以通过 Tool Calling 判断：

当前任务需要查询数据库

随后 Host 再通过 MCP Client 调用对应 MCP Server 提供的 Tool。

所以：

Tool Calling 决定“调用什么”，MCP 负责“怎么连接到这个工具并调用它”。

Resources

Resources 代表的是 可以被 AI 应用读取的上下文和数据。

例如：

某个文件
数据库 Schema
项目文档
日志
配置文件
GitHub Repository 内容

它与 Tool 最大的区别是：

Tool = 做事情
Resource = 获取信息

例如读取一份配置文件，本质上更加接近 Resource；创建 GitHub Issue，则明显属于 Tool。

一个 MCP Server 可以暴露类似：

file:///project/README.md
database://schema/users
repository://docs/architecture

Host 可以读取这些 Resource，并把其中需要的信息加入模型上下文。

这也是为什么协议叫做 Model Context Protocol，而不是单纯的 Tool Protocol。

MCP 从设计上解决的不只是“模型怎么执行操作”，也包括“模型如何获得外部上下文”。

Prompts

Prompts 是 MCP 中另一个经常被忽略的能力。

它允许 MCP Server 向 Host 暴露可复用的 Prompt 模板。

例如一个代码审查 MCP Server 可以提供：

review_pull_request
explain_bug
generate_test_plan

其中某个 Prompt 可能提前定义：

请根据当前 Repository 的代码规范，
分析 Pull Request 中存在的问题，
重点检查安全性、可维护性和测试覆盖率。

这样，某个外部能力不仅可以告诉 AI：

我有哪些数据
我有哪些工具

还可以告诉 AI：

这些能力通常应该怎样被使用

因此 MCP Server 可以被理解为对一个外部系统的完整 AI 接口：

Resources -> 有什么信息可以读取
Tools -> 有什么操作可以执行
Prompts -> 可以怎样组织和使用这些能力

MCP 和普通 API 有什么区别

看到这里，一个很自然的问题是：

MCP 不就是给 API 套了一层协议吗？

从底层来看，MCP Server 最终当然还是需要调用 API、数据库、文件系统或者其他程序接口。

但两者解决的问题不同。

传统 API 通常是：

Application -> API

API 的消费者是程序员写好的程序。

例如：

github.create_issue(...)

程序员必须提前知道：

API 地址是什么
有哪些 Endpoint
参数是什么
认证怎么做
返回值是什么
什么时候调用

MCP 则在 API 上方增加了一层面向 AI 应用的标准描述和通信机制：

AI Host
-> MCP Client
-> MCP Server
-> API

MCP Server 可以告诉 Client：

我有哪些 Tools
有哪些 Resources
有哪些 Prompts
每个 Tool 需要哪些参数

因此，一个支持 MCP 的 Host 可以动态发现一个 Server 提供的能力，而不需要针对每个服务重新设计一套 AI 集成方式。

MCP 并没有替代 HTTP API、数据库协议或者文件系统接口，它更像是建立在这些能力之上的 AI Integration Layer。

这也是为什么很多 MCP Server 本质上都是适配器：

GitHub MCP Server -> GitHub API

PostgreSQL MCP Server -> PostgreSQL

Filesystem MCP Server -> Operating System

Browser MCP Server -> Browser Automation

Notion MCP Server -> Notion API

它把原本只对传统程序开放的能力，转换成 AI 应用能够统一发现和使用的形式。

MCP 和 Tool Calling 到底是什么关系

这两个概念经常被混在一起。

其实可以非常简单地拆开。

Tool Calling 解决：

LLM 应该调用哪个 Tool？
参数是什么？

MCP 解决：

这个 Tool 从哪里来？
怎么发现它？
怎么连接？
怎么调用？
结果怎么返回？

完整流程可以表示为：

用户：
“帮我看看这个项目最近有没有新的 Bug。”

->

LLM 判断：
需要查询 GitHub Issues

->

Tool Calling：
调用 search_issues

->

Host：
发现这个 Tool 来自 GitHub MCP Server

->

MCP Client：
发送调用请求

->

GitHub MCP Server：
调用 GitHub API

->

GitHub API：
返回 Issues

->

MCP Server：
返回 Tool Result

->

Host：
将结果交给 LLM

->

LLM：
分析并回答用户

因此：

Tool Calling 是模型能力，MCP 是系统协议。

只有 Tool Calling，没有 MCP，同样可以开发 Agent，只不过所有工具都需要自己集成。

只有 MCP，没有模型 Tool Calling，同样可以连接和读取 MCP Server，但模型本身无法根据任务自主选择工具。

两者结合之后：

Tool Calling + MCP
=
模型动态决策 + 外部能力标准化接入

这才是 MCP 在 Agent 生态中真正重要的地方。

MCP Server 本质上是一层 Adapter

从软件工程角度来看，MCP Server 并不神秘。

很多 MCP Server 的结构其实就是：

MCP Protocol
-> Adapter
-> Existing API / Service

例如：

MCP Client
-> GitHub MCP Server
-> GitHub REST / GraphQL API

或者：

MCP Client
-> PostgreSQL MCP Server
-> PostgreSQL Driver
-> Database

所以开发一个 MCP Server 的核心工作通常不是重新实现业务能力，而是：

把已有能力转换成标准化的 AI 接口。

例如原来有：

def get_user(user_id):
    ...

现在可以将它注册成 MCP Tool。

当前官方 TypeScript SDK 中，一个最简单的 Tool Server 可以写成类似下面的结构：

import { McpServer } from "@modelcontextprotocol/server";
import { serveStdio } from "@modelcontextprotocol/server/stdio";
import * as z from "zod/v4";

serveStdio(() => {
    const server = new McpServer({
        name: "user-service",
        version: "1.0.0"
    });

    server.registerTool(
        "get-user",
        {
            description: "Get user information",
            inputSchema: z.object({
                userId: z.string()
            })
        },
        async ({ userId }) => ({
            content: [
                {
                    type: "text",
                    text: JSON.stringify(
                        await getUser(userId)
                    )
                }
            ]
        })
    );

    return server;
});

这里实际上只做了三件事：

定义 Tool
-> 定义 Schema
-> 将 Tool 映射到已有业务函数

接下来，支持 MCP 的 Host 就可以发现并使用这个 Tool。

MCP 为什么比复制一堆 Function Schema 更重要

如果只有几个 Tool，完全可以把 Function Schema 直接写在 Agent 项目里。

例如：

tools = [
    search_web,
    query_database,
    send_email
]

问题是，当 Tool 数量增加、外部系统不断变化之后，这些能力就会和 Agent 本身高度耦合。

例如：

Agent Repository

├── github_tools.py
├── notion_tools.py
├── database_tools.py
├── filesystem_tools.py
├── browser_tools.py
├── slack_tools.py
└── calendar_tools.py

每增加一个系统，都需要修改 Agent。

MCP 可以把它拆开：

Agent
|
├── GitHub MCP Server
├── Notion MCP Server
├── Database MCP Server
├── Browser MCP Server
├── Filesystem MCP Server
└── Calendar MCP Server

Agent 本身只需要具备 MCP Client 能力。

这样，一个 Tool 的生命周期就可以独立于 Agent：

开发
更新
部署
认证
维护
权限控制

都可以由对应 MCP Server 自己负责。

这实际上降低了 Agent 和外部能力之间的耦合。

MCP 并不会自动让 Agent 更智能

MCP 很容易被描述成一种能够“大幅增强 AI 能力”的东西，但从工程角度来看，需要把这个概念说得更准确。

MCP 本身并不会提高模型的推理能力。

如果一个模型原本不会正确选择工具，接入 MCP 之后，它依然可能选择错误。

如果一个 Agent 的 Workflow 设计很差，MCP 也不会自动修复它。

MCP 真正解决的是：

Capability Integration

而不是：

Reasoning
Planning
Decision Making

因此：

LLM
负责理解与推理

Tool Calling
负责选择工具

Workflow
负责控制任务流程

MCP
负责标准化连接外部能力

Runtime
负责真正执行和管理整个任务

这些层次应该分开理解。

MCP 的通信方式

MCP 不规定所有 Server 都必须以完全相同的部署形式存在。

一个 MCP Server 可以是本地进程，也可以是远程服务。

本地工具很常见的形式是：

Host
-> stdio
-> MCP Server Process

例如一个文件系统 MCP Server，可以直接作为本地进程运行。

远程服务则可以通过 HTTP 与 MCP Client 通信。当前官方 SDK 同时提供 stdio 和 HTTP 相关能力。

因此 MCP 可以同时覆盖：

本地工具
企业内部服务
远程 SaaS
云端 Agent 服务

这也是它能够成为通用 AI 接入协议的重要原因。

2026 年的 MCP 已经开始解决生产环境问题

早期 MCP 更容易让人联想到：

Claude Desktop
-> 本地 MCP Server
-> Filesystem / SQLite

但 MCP 现在已经明显不只是本地工具协议。

2026-07-28 规范将协议核心调整为无状态设计，每一个请求可以独立处理，使远程 MCP Server 更容易进行负载均衡和水平扩展；同时加入更明确的缓存、路由、授权与 Extensions 机制。

一个非常明显的变化是：

早期：
MCP = 给桌面 AI 接几个工具

现在：
MCP = Agent Infrastructure 中的 Integration Protocol

这意味着它需要开始处理传统后端系统同样会遇到的问题：

Authentication
Authorization
Scalability
Caching
Observability
Versioning
Gateway
Long-running Tasks

MCP 的发展方向也越来越接近真正的基础设施协议，而不仅仅是一个方便开发 Demo 的工具系统。官方 2026 年路线图也持续将企业级安全、Agent 通信和协议可扩展性作为重点方向。

MCP 最大的问题仍然是权限和安全

当 MCP Server 只提供：

读取文件
查询数据库
搜索文档

风险还比较容易控制。

但如果 MCP Server 开始提供：

删除文件
发送邮件
修改数据库
创建订单
操作服务器
执行 Shell

问题就完全不同了。

从模型角度来看：

delete_file

可能只是一个 Tool。

但从操作系统角度来看，这可能是一次不可逆操作。

因此 MCP 并不意味着：

连接 Server -> 把所有 Tool 全部交给模型

真正的生产系统仍然应该拥有明确的权限边界。

例如：

Read Tools
-> 可以自动执行

Write Tools
-> 需要更严格校验

Destructive Tools
-> 用户确认

Administrative Tools
-> 默认禁止

MCP 解决的是能力如何被标准化暴露，而不是替开发者决定这些能力是否安全。

权限控制、用户授权、最小权限原则、参数验证、审计日志和高风险操作确认，仍然属于 Agent Runtime 和 MCP Server 必须承担的工程责任。

不是什么东西都需要做成 MCP Server

MCP 是一种标准化集成方式，但并不意味着 Agent 内部的每一个函数都应该被 MCP 化。

例如 Agent 内部存在：

format_date()
calculate_score()
parse_json()
normalize_text()

这些只属于应用内部实现细节，没有必要单独建立 MCP Server。

MCP 更适合具有明显独立边界的外部能力，例如：

GitHub
Notion
Database
Filesystem
Browser
Slack
Calendar
Cloud Service
Enterprise API

判断一个能力是否值得 MCP 化，可以考虑一个很简单的问题：

这个能力未来是否可能被多个 AI 应用重复使用？

如果答案是肯定的，那么把它封装成独立 MCP Server 通常会比把 Tool 永久写死在某一个 Agent 中更合理。

MCP 真正改变了什么

传统软件世界已经有大量标准协议。

数据库有自己的访问协议，Web 服务普遍使用 HTTP，身份认证有 OAuth，浏览器与服务器之间也有一整套成熟标准。

但在 AI Agent 出现之后，一个新的集成问题出现了：

模型如何知道一个外部系统能够做什么？

以及：

不同 AI 应用如何以统一方式使用这些能力？

过去的方案是每一个 Agent 自己集成：

Agent
-> 自己写 GitHub Tool
-> 自己写 Database Tool
-> 自己写 Browser Tool
-> 自己写 Notion Tool

MCP 希望变成：

Agent
-> MCP
-> Existing AI Capabilities

因此，MCP 最重要的价值并不是“让模型拥有更多工具”。

真正重要的是：

让工具、数据和 AI 应用之间形成一个可以复用、组合和替换的标准接口。

从这个角度来看，MCP 更像是 Agent 生态中的基础设施层。

Tool Calling 让 LLM 学会说：

“我要调用这个工具。”

而 MCP 解决的是：

“这个工具在哪里、它有什么能力、该如何调用，以及结果如何回来。”

最终，一个更加完整的 Agent 系统可能会形成这样的结构：

User
-> Agent
-> LLM
-> Tool Calling
-> MCP Client
-> MCP Server
-> API / Database / Filesystem / Browser

Tool Calling 给模型行动的意图，MCP 给这些行动提供标准化的接口，而 Agent Runtime 把二者真正组织成一个能够长期运行的软件系统。

这才是 MCP 在 Agent 开发中的真正位置。