MCP（Model Context Protocol） ≠ API
但 MCP 是为“大模型”专门设计的一种 新一代协议层，包裹和协调 API 的安全调用、上下文共享与语义控制。

🧩 一句话区别

🧠 二、MCP 与 API 的关系

可以理解成：

MCP 是 AI 世界的“应用层协议”，
它 包装并协调底层 API 的调用，让大模型能理解、推理、授权地使用它们。

🔹传统 API 流程

1

客户端 → 调用接口 /api/v1/data → 返回 JSON

开发者要写清楚：

• URL、参数格式、认证方式
• 处理异常、分页、结构等

AI 模型很难“理解”或“自发使用”这些 API，因为它没有固定 schema 绑定或上下文。

🔹MCP 流程（AI 调用场景）

1
2
3
4
5
6
7

大模型 (AI Client)
   ↓
MCP 协议层（Context Protocol）
   ↓
调用注册好的 Tool（内部封装 API / DB / OS）
   ↓
返回语义化结果（可解释 JSON）

特点：

• 模型只需说：“获取最近 10 个错误日志”

• MCP Adapter 会：

  • 选择正确的 API（/logs?type=error&limit=10）
  • 验证安全范围
  • 格式化结果为模型易解析的结构

✅ 这样模型可以在“自然语言 → 行为执行”之间无缝切换。

🧩 三、MCP 的核心组成（对比 API 架构）

🧰 四、类比理解

⚙️ 五、可视化结构（简化）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

                ┌──────────────────────────────┐
                │         大模型 (LLM)          │
                │   "分析系统性能瓶颈"          │
                └────────────┬─────────────────┘
                             │
                      [MCP Context Layer]
                             │
                             ▼
┌────────────────────────────────────────────┐
│ 注册的工具（Tools）                        │
│ ├─ monitor.cpu (封装 REST API)             │
│ ├─ system.logs (封装 GraphQL 查询)          │
│ └─ deploy.container (封装 Docker API)       │
└────────────────────────────────────────────┘
                             │
                             ▼
┌────────────────────────────────────────────┐
│ 底层资源 / API / 命令 / 数据库              │
└────────────────────────────────────────────┘

MCP 让大模型“语义上”访问这些资源，而不是靠 prompt 胡乱猜 API。

🔒 六、安全与治理层（MCP 独有）

🧩 七、总结核心区别一句话

API 是命令接口，MCP 是语义协议。
API 告诉你“做什么”；
MCP 确保“模型为什么要做、能不能做、如何安全地做”。

非常精准的问题 ⚡

“MCP 为何附带了上下文（context）？”

这个其实是 Model Context Protocol 的根本设计哲学所在，
也是它区别于传统 API、RPC、GraphQL 的灵魂部分。

🧩 一句话回答

因为 AI 模型的行为不是“单次请求”，而是“连续推理”。

MCP 附带上下文，是为了让模型在多轮对话、工具调用、任务链中——
保持语义连续性、安全边界与决策可解释性。

🧠 一、为什么传统 API 没有“上下文”

传统 API 假设：

“调用者知道自己要什么，也能准确描述参数。”

但大模型不同：

• 它在推理中逐步形成意图；
• 可能会调用多个工具；
• 它的“目标”与“中间动作”是动态生成的；
• 而且模型没有持续的“内部记忆”。

所以，如果没有“上下文”，模型就会迷失在自己的调用里。

🧬 二、MCP 附带上下文的核心原因（3个层面）

1️⃣ 语义连续性

模型每一步调用，都建立在之前理解、用户目标、工具反馈之上。
MCP 通过上下文字段让每次调用都能继承这条语义链。

例如：

1
2
3
4
5
6
7
8
9
10

{
  "context": {
    "conversation_id": "abc123",
    "user_goal": "分析系统性能瓶颈",
    "previous_tool": "monitor.cpu",
    "prior_results": { "cpu_usage": 95 }
  },
  "operation": "analyze_memory",
  "params": {}
}

→ MCP Server 能理解：这是一次“同一任务链的下一步”，不是新的随机请求。

2️⃣ 安全与权限跟踪

MCP 的上下文不仅包括语义，也包括：

• 用户身份 / 授权
• 当前会话风险等级
• 操作范围限制（scope）

这样可以做到：

• “AI 调用文件系统”时，知道当前是谁授权的；
• “上一步批准删除 temp 文件”，本步不能突然删除 /root；
• “任务处于高风险态”，需要再次确认。

→ 即 上下文 = 安全护栏。

3️⃣ 可解释性与审计

上下文让整个推理-执行链可追溯：

1

User Intent → AI Reasoning → MCP Tool Calls → Responses → Final Action

每个环节都记录在 context trace 里，
你可以事后回溯模型当时的想法、调用理由、执行内容。
这在 AI 安全和可信执行中极其重要。

⚙️ 三、MCP 上下文的结构（示例）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "context": {
    "session_id": "chat_0721",
    "user_id": "u_1209",
    "intent": "debug webapp error",
    "history": [
      {"role": "user", "msg": "why is my app crashing?"},
      {"role": "model", "msg": "checking logs"},
      {"role": "tool", "msg": "found error 500 at /auth"}
    ],
    "permissions": ["read_logs", "query_db"],
    "sandbox": "container_01",
    "risk_level": "medium"
  },
  "operation": "query_db",
  "params": { "table": "errors", "limit": 10 }
}

MCP Server 收到这个请求，可以：

• 判断是否越权；
• 在正确容器中执行；
• 返回结果并带上审计信息。

🔄 四、上下文如何影响模型行为（实际效果）

🧰 五、上下文的三大类型（在 MCP 中）

🧩 六、类比帮助理解

🧠 七、总结一句话

MCP 附带上下文，是因为 AI 的调用不是一次请求，而是一次“语义任务链”。

上下文让 MCP 能做到：

• 让模型知道自己在哪个任务阶段（连续性）；
• 让系统知道模型能做什么（安全性）；
• 让开发者知道模型为何这样做（可解释性）。

“为了安全，可以考虑在 MCP 里支持 schema”

正是目前 MCP（Model Context Protocol）未来演进的关键方向之一。
我们可以这样理解：

Schema 是 MCP 安全与可信语义的“宪法”。
它不仅描述“能调用什么”，还定义“能怎么调用”“返回什么”“谁能调用”。

🧩 一、为什么 MCP 必须支持 Schema

传统 API 通过 OpenAPI / GraphQL SDL 等 schema
→ 约束人类开发者的调用方式。

但在 MCP 中，调用者是 AI 模型。
模型不会“遵守约定”，它会：

• 自动生成参数；
• 推理目标；
• 有时理解错误（或恶意提示攻击被诱导执行高危操作）。

👉 因此，我们不能只靠接口签名约束，而要靠 schema 层面的强验证 来：

1. 防止模型生成不合规请求；
2. 限定高风险字段、参数范围；
3. 让主机能语义验证调用是否匹配意图。

🧠 二、MCP Schema 的三重作用

⚙️ 三、MCP Schema 的可能结构设计（示例）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

tool: delete_files
description: "Delete temporary files safely"
version: 1.0

schema:
  input:
    type: object
    properties:
      path:
        type: string
        pattern: "^/tmp/"
        description: "File path (must be under /tmp)"
      recursive:
        type: boolean
        default: false
    required: [path]

  output:
    type: object
    properties:
      deleted_count:
        type: integer
      status:
        type: string
        enum: ["ok", "error"]

  security:
    risk_level: "high"
    confirm_required: true
    sandbox: "filesystem"
    permissions: ["delete_temp_files"]

📍 功能说明：

• schema.input：定义输入参数格式与正则约束。
• schema.output：定义返回值结构。
• schema.security：描述安全策略与执行条件。

🧰 四、在执行流程中的作用

1
2
3
4
5
6

大模型 → 生成 MCP 请求
   ↓
MCP Adapter → 校验请求 against Schema
   ↓
[ 通过 ] → 发送至 MCP Server
[ 拒绝 ] → 触发安全提示 / 人类确认

这一步是 “语义级防火墙”：

• 模型说“删除无用文件”，系统检查路径 /home/user ❌ 不在 /tmp/ 内 → 拒绝执行。
• 模型参数不匹配 schema → 拒绝。

🔒 五、MCP Schema 的安全增益

🧩 六、MCP Schema ≠ OpenAPI

区别如下：

🧠 七、MCP Schema 与上下文结合

Schema 可以与 context 配合使用：

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "context": {
    "user_id": "U123",
    "session_id": "S456",
    "sandbox": "container_01"
  },
  "operation": "delete_files",
  "params": {
    "path": "/tmp/logs/",
    "recursive": true
  },
  "schema_ref": "delete_files@1.0"
}

系统自动：

• 依据上下文检查权限；
• 依据 schema 校验参数；
• 审计执行。

最终 → 形成 安全上下文 + schema 双约束机制。

🧭 八、类比理解

💡 九、可视化结构（逻辑层）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

┌─────────────────────────────────────┐
│  大模型 / MCP Client               │
│  - 自然语言意图                    │
│  - 生成调用请求                    │
└──────────────┬──────────────────────┘
               │
         [Schema Validator]
               │
               ▼
┌─────────────────────────────────────┐
│  MCP Protocol Layer                 │
│  - Context 绑定                     │
│  - 权限控制 / 审计                  │
└──────────────┬──────────────────────┘
               │
               ▼
┌─────────────────────────────────────┐
│  MCP Server / Tool                  │
│  - 执行已验证操作                   │
│  - 产出结构化输出                   │
└─────────────────────────────────────┘

🧠 十、总结一句话

Schema 是让 MCP 可验证、可控、可解释的关键机制。

它让大模型的“语义自由”
→ 被约束在安全、透明、可审计的框架之中。