MCP and API（二者区别）

序言

在大概了解MCP是什么之后，有人可能会想MCP与API的区别🤔

先看图：

再看表：

方面	传统 API（REST/GraphQL）	模型上下文协议（MCP）
它是什么	具有可选规范格式（OpenAPI、GraphQL SDL）的接口样式（REST、GraphQL）	具有强制消息结构的标准化协议
设计用于	人类开发人员编写代码	人工智能代理做出决策
数据位置	REST：路径、标题、查询参数、正文（多种格式）	每个工具单个 JSON 输入/输出
发现	静态文档，为变更重新生成 SDK 1 2	运行时自省（`tools/list`）
执行	LLM 生成 HTTP 请求（容易出错）	LLM 选择工具，确定性代码运行
方向	通常由客户端发起；服务器推送存在但尚未标准化	双向作为首要特性
本地访问	需要端口、授权、CORS 设置	桌面工具的原生 stdio 支持
训练目标	由于异质性，规模不切实际	单一协议支持模型微调

HTTP API 问题

HTTP API 容易出现组合混乱的情况。要将数据发送到端点，您可能需要将其编码为：

URL 路径 ( /users/123)
请求标头（X-User-Id: 123）
查询参数（?userId=123）
请求正文（JSON、XML、表单编码、CSV）

OpenAPI/Swagger 记录了这些变化，但作为一种规范格式，它描述的是现有模式，而不是强制一致性。构建能够可靠地使用任意 API 的自动化工具仍然很困难，因为 HTTP 并非为此而设计的------它是唯一一种跨平台、防火墙友好的、可在浏览器中通用的传输协议。

MCP：有线协议，而非文档

模型上下文协议 (MCP) 并非另一种 API 标准，而是一种强制一致性的线路协议。OpenAPI 记录了现有接口及其变体，而 MCP 则要求特定的模式：JSON-RPC 2.0 传输、每个工具的单一输入模式以及确定性执行。关键架构：

传输：stdio（本地）或可流式传输的 HTTP
发现：在tools/list运行resources/list时公开功能
原语：工具（操作）、资源（只读数据）、提示（模板）

为什么不直接使用 OpenAPI？

最常见的问题是："为什么不使用特定于 AI 的功能来扩展 OpenAPI？"

三个原因：

OpenAPI 负责描述；MCP 负责规定。你无法通过完善文档来解决不一致的问题------你需要在协议层面进行强制执行。
改造在规模化的情况下会失败。OpenAPI 需要标准化传输，强制单一位置输入，要求特定的模式，添加双向原语------本质上会成为一种不同的协议。
生态系统问题。即使 OpenAPI 明天添加了这些功能，数百万现有 API 也不会采用它们。MCP 以 AI 优先的原则重新出发。

五个根本区别

1. 运行时发现 vs 静态规范

API：当端点发生变化时发送新的客户端代码

MCP：代理动态查询功能并自动适应

sql 复制代码

// MCP discovery - works with any server
client.request('tools/list')
// Returns all available tools with schemas

2. 确定性执行 vs LLM 生成的调用

API：LLM 编写 HTTP 请求 → 幻觉路径，错误参数

MCP：LLM 选择哪个工具 → 包装的代码确定性地执行

这种区别对于生产安全至关重要。使用 MCP，您可以在实际代码中测试、过滤输入并处理错误，而不必指望 LLM 能够正确格式化请求。

3.双向通信

API：存在服务器推送（WebSockets、SSE、GraphQL 订阅）但缺乏标准化

MCP：双向通信作为一流功能：

向服务器请求法学硕士完成情况
询问用户输入（引出）
推送进度通知

4. 单一请求人工任务

REST API 将人工任务分散到各个端点。创建日历事件可能需要：

POST /events（创造）
GET /conflicts（查看）
POST /invitations（通知）

MCP 工具映射到完整的工作流程。一个工具，一个人工任务。

5. 本地优先的设计

API：需要 HTTP 服务器（端口绑定、CORS、身份验证标头）

MCP：可以通过 stdio 作为本地进程运行 - 无需网络层

为什么这很重要：当 MCP 服务器通过 stdio 在本地运行时，它们会继承主机进程的权限。

这使得：

直接文件系统访问（读/写文件）
终端命令执行
系统级操作

注意：

本地 HTTP 服务器可以提供相同的功能。然而，我认为 MCP 以传输为主导的事实，stdio植入了这样一种观念：MCP 服务器应该作为本地服务，这与我们通常对 API 的理解不同。

培训优势

MCP 的标准化创造了一个未来机遇：模型可以在单一、一致的协议上进行训练，而无需使用成千上万个 API 变体。虽然目前的模型是通过现有的函数调用功能来使用 MCP，但该协议的统一性带来了直接的实际好处：

所有服务器的一致模式：

发现：tools/list，，resources/list``prompts/list
执行：tools/call使用单个 JSON 参数对象
错误：带有数字代码的标准 JSON-RPC 格式

减少模型的认知负荷：

sql 复制代码

// Every MCP tool follows the same pattern:
{
  "method": "tools/call",
  "params": {
    "name": "github.search_prs",
    "arguments": {"query": "security", "state": "open"}
  }
}

// Versus REST APIs with endless variations:
// GET /api/v2/search?q=security&type=pr
// POST /graphql {"query": "{ search(query: "security") { ... } }"}
// GET /repos/owner/repo/pulls?state=open&search=security

这种标准化意味着模型需要学习一种调用约定，而不是从文档中推断模式。随着 MCP 的普及，未来的模型可以针对该协议进行专门优化，类似于目前针对函数调用格式进行训练的模型。

他们是层级，而不是竞争对手

大多数 MCP 服务器包装了现有的 API：

arduino 复制代码

[AI Agent] ⟷ MCP Client ⟷ MCP Server ⟷ REST API ⟷ Service

服务器mcp-github转换repository/list为 GitHub REST 调用。您可以保留久经考验的基础架构，同时添加 AI 友好的人体工程学设计。

真实世界的例子

考虑一项任务："查找所有提及安全问题的拉取请求并创建一份摘要报告。"

使用 OpenAPI/REST：

LLM 读取 API 文档，生成：GET /repos/{owner}/{repo}/pulls?state=all
希望它正确格式化了请求
解析响应，生成：GET /repos/{owner}/{repo}/pulls/{number}
对每个 PR 重复（速率限制问题）
生成评论的搜索查询
汇编报告

使用 MCP：

LLM 要求：github.search_issues_and_prs({query: "security", type: "pr"})
确定性代码处理分页、速率限制、错误重试
返回结构化数据
LLM 侧重于分析，而不是 API 机制

总结

HTTP API 的发展是为了服务人类开发者和基于浏览器的应用程序，而不是 AI 代理。MCP 从头开始满足 AI 特定的需求：运行时发现、确定性执行和双向通信。

对于 AI 优先的应用，MCP 提供了结构性优势------本地执行、服务器启动的流程以及有保障的工具可靠性------而这些优势在传统的 API 架构中需要进行大量的改进。实际的方案是两者兼顾：维护面向人类开发者的 API，同时添加 MCP 以集成 AI 代理。