MCP 深度拆解：当 AI Agent 学会「插拔」——Model Context Protocol 如何用 JSON-RPC 2.0 重写 AI 工具调用的心智模型

一、引言：AI Agent 为什么需要一把「万能插头」

2024年11月，Anthropic 发布了一个开源协议，名叫 Model Context Protocol（MCP）。当时很多人觉得这就是又一个「Function Calling 的替代品」，并没有太当回事。

但到了2026年的今天，MCP 已经被捐赠给 Linux 基金会的 Agentic AI Foundation，OpenAI、Google、Microsoft、阿里云相继宣布兼容支持。一个协议用不到两年时间，从一家公司的实验性项目，变成整个 AI 行业的事实标准——这件事本身就很值得深挖。

本文从工程师视角出发，系统性地拆解 MCP 的设计哲学、协议规范、SDK 实现、传输层机制、生产落地实践，以及它对 AI 应用架构的深远影响。如果你正在构建 AI Agent，或者在思考如何让 AI 模型真正「行动」起来，这篇文章会给你一个完整的技术地图。

二、背景：工具调用的「战国时代」

在聊 MCP 之前，必须先理解它解决的问题。

2.1 碎片化：每个 AI 厂商都在「造轮子」

2023-2024年，AI 应用开发领域最热的话题是 Function Calling（函数调用）。OpenAI 推出了 Function Calling，Anthropic 推出了 Tool Use，Google 有 function_declarations，Meta 的 Llama Stack 也有自己的方案。表面上它们都在解决「让 AI 调用外部工具」的问题，但实际上：

• 接口设计完全不同：OpenAI 用 functions 数组，Anthropic 用 tools 数组，参数格式各异
• 一次开发，无法复用：为 Claude 写的工具集，直接拿到 GPT-4 里用不了
• 安全边界模糊：每个厂商的权限控制模型都不一样，没有统一标准
• 生态锁定：用了某家 AI 平台的工具系统，就很难迁移

这就好比 USB 出现之前的各种专用接口——每个设备厂商都说自己的接口最好，但消费者手里需要一堆转接头。

2.2 MCP 的核心定位

MCP 要做的事一句话就能说清楚：给 AI 模型和外部世界之间，定义一套标准化的「插座」协议。

┌─────────────────────────────────────────────────┐
│  MCP Host (Claude Desktop / Cursor / VS Code)   │
│  ┌──────────────┐  ┌──────────────┐            │
│  │ MCP Client A │  │ MCP Client B │  ...        │
│  └──────┬───────┘  └──────┬───────┘            │
│         │                 │                     │
│  ┌──────▼───────┐  ┌──────▼───────┐            │
│  │ MCP Server   │  │ MCP Server   │            │
│  │ (Filesystem) │  │ (Database)   │            │
│  └──────────────┘  └──────────────┘            │
└─────────────────────────────────────────────────┘

MCP 采用 客户端-服务器（Client-Server）架构：

• MCP Host：运行 AI 模型的应用程序，如 Claude Desktop、Cursor IDE、各类 AI 编程工具
• MCP Client：内置于 Host 中，负责与各个 MCP Server 维持一对一连接
• MCP Server：暴露特定工具和数据访问能力的服务程序

核心逻辑是：开发者只需要写一次 MCP Server，就可以被所有支持 MCP 的 AI 应用调用。这从根本上解决了工具碎片化的问题。

三、协议规范深度解析：MCP 不是什么新东西，但它组合得很好

3.1 协议基础：JSON-RPC 2.0

MCP 的传输层基于 JSON-RPC 2.0 规范，这是一个轻量级的远程过程调用（RPC）协议，用 JSON 作为数据格式。JSON-RPC 的优势在于：

• 无状态：每个请求独立，服务器不需要维护会话状态
• 跨语言：任何能序列化 JSON 的语言都可以实现
• 简单透明：协议本身没有复杂的状态机

MCP 在 JSON-RPC 2.0 之上定义了三个核心原语（Primitive），覆盖 AI 与外部世界交互的主要场景。

3.2 三大核心原语

3.2.1 Resources（资源）——让 AI 读取数据

Resources 是服务器向客户端提供的只读数据，类似于文件系统中的读操作。当 AI 模型需要访问外部数据时（如读取文件、查询数据库），Resources 提供了标准化的接口。

一个典型的 Resources 定义：

{
  "uri": "file:///project/README.md",
  "name": "项目说明文档",
  "mimeType": "text/markdown",
  "description": "项目的 README 文件，描述了项目架构和用法",
  "size": 4096
}

客户端通过 resources/list 请求获取可用资源列表，通过 resources/read 读取具体内容。MCP Server 负责管理这些资源的生命周期和安全边界——模型只能访问 Server 明确暴露的资源，不能越界。

3.2.2 Tools（工具）——让 AI 执行操作

Tools 是 MCP 最核心的能力：让 AI 模型真正「动手」做事。一个 Tool 的定义包含：

{
  "name": "send_email",
  "description": "发送一封邮件给指定收件人，包含主题和正文",
  "inputSchema": {
    "type": "object",
    "properties": {
      "to": {
        "type": "string",
        "description": "收件人邮箱地址"
      },
      "subject": {
        "type": "string",
        "description": "邮件主题，不超过100字符"
      },
      "body": {
        "type": "string",
        "description": "邮件正文内容"
      }
    },
    "required": ["to", "subject", "body"]
  }
}

当 MCP Client 收到 Host 的 tools/list 请求后，会返回所有可用工具的列表及签名。AI 模型根据用户意图，从中选择合适的工具和参数，然后通过 tools/call 发起调用。MCP Server 负责验证参数、执行操作、返回结果。

这里有一个关键的设计决策值得注意：MCP 的 Tool 描述使用 JSON Schema 来定义输入参数。这是一个经过大量工程实践验证的标准，几乎所有主流编程语言都有成熟的 JSON Schema 解析库。相比于各家 AI 厂商自定义的 Function Calling 格式，JSON Schema 的表达能力更强，工具之间可以互相引用、组合、生成动态表单。

3.2.3 Prompts（提示模板）——让 AI 复用结构化指令

Prompts 允许 MCP Server 暴露可复用的提示模板，供 AI 模型在特定场景下直接使用：

{
  "name": "code_review",
  "description": "执行标准化的代码审查流程",
  "arguments": [
    {
      "name": "language",
      "description": "代码语言",
      "required": true
    },
    {
      "name": "focus_area",
      "description": "审查重点",
      "required": false
    }
  ]
}

这个能力常被用于将企业内部的最佳实践标准化——不同团队可以维护自己领域的 Prompt Server，新人问 AI 时会自动带上团队的标准审查流程。

3.3 消息流：一次完整的工具调用

理解 MCP 最直观的方式是看一次完整的消息流。假设用户对 Claude Desktop 说：「帮我把这个项目的 README 发给我女朋友的邮箱。」

Step 1：初始化握手

Client → Server: initialize (protocolVersion, capabilities)
Server → Client: initialized (serverInfo, capabilities, protocolVersion)

这是标准的 Capability Negotiation（能力协商）模式。MCP Client 告知 Server 自己支持哪些能力（如 Streaming、采样等），Server 也报告自己的能力。MCP 的设计哲学是增量能力：Server 不需要实现所有功能，Client 也不会强制要求不支持的特性。

Step 2：列出可用工具

Client → Server: tools/list
Server → Client: tools/list + [send_email, read_file, search_web, ...]

Step 3：AI 选择并调用工具

AI 模型经过推理，决定调用 send_email，并生成参数：

Client → Server: tools/call {
  name: "send_email",
  arguments: {
    to: "girlfriend@example.com",
    subject: "项目 README",
    body: "# My Project\n\n这是我的项目说明..."
  }
}
Server → Client: tools/call result {
  success: true,
  message: "邮件已发送至 girlfriend@example.com"
}

整个过程对用户完全透明——用户不需要知道 AI 调用了什么工具，就像用户不需要知道 USB 设备内部怎么通信一样。

四、传输层：两种部署模式与 SSE 的精妙设计

4.1 stdio 模式：本地进程通信

stdio（Standard Input/Output） 是 MCP 最常用的传输模式，适用于本地工具集成场景。MCP Client 通过子进程的方式启动 Server，通过标准输入输出流进行通信：

import asyncio
from mcp.server.stdio import stdio_server

async def main():
    async with stdio_server() as (read_stream, write_stream):
        # Server 在 stdio 上接收请求并发送响应
        pass

if __name__ == "__main__":
    asyncio.run(main())

这种模式的优势是简单、隔离、安全：

• Server 是一个独立的进程，有独立的文件系统视图
• 通信数据不会经过网络，无法被窃听
• 启动和销毁的开销很低，适合工具量少、调用不频繁的场景

Claude Desktop 使用的就是 stdio 模式。每个 MCP Server 是一个独立进程，通过进程间通信与 Client 交互。

4.2 SSE + HTTP 模式：服务端部署

对于需要多个客户端共享同一个 Server 的场景（如企业内部知识库 API），MCP 支持基于 Server-Sent Events (SSE) 的 HTTP 长连接模式：

Client ←─HTTP POST─→ Server (发送请求)
Client ←─SSE──────→ Server (接收响应/通知)

MCP 的 SSE 模式设计了一个巧妙的双向通道：

• HTTP POST：客户端发起请求（工具调用、列表查询等）
• SSE 流：服务器主动推送通知（文件变更、Webhook 回调等）

这样既保留了 HTTP 请求-响应模型的简单性，又获得了服务器主动推送的能力。对比 WebSocket，SSE 的优势是轻量、单向、重连简单——对于 AI 工具调用这个场景，服务器主动发起的通知场景相对有限，SSE 是更合适的选择。

4.3 传输层的安全模型

MCP 在传输层设计了严格的安全边界：

1. 进程隔离：stdio 模式下每个 Server 是独立进程，资源访问受 OS 权限控制
2. 参数验证：Server 对每个工具调用进行输入验证，防止注入攻击
3. 权限分层：Server 可以声明自己需要的权限（如只读文件系统 vs 可写文件系统）
4. 审计日志：所有工具调用都会被 Client 记录，支持事后审计

这是一个纵深防御的设计：即使某一层被攻破，还有其他层提供保护。

五、SDK 实战：从零搭建一个 MCP Server

5.1 Python SDK：FastMCP 的简洁之道

MCP 官方提供了 Python SDK，其中 fastmcp 库是最主流的选择。它的设计理念是：让开发者用最少的代码，暴露最丰富的工具。

环境准备：

# 推荐使用 uv 管理虚拟环境（启动速度比 pip 快约10倍）
curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv mcp-project && source .venv/bin/activate
uv add "mcp[cli]" fastmcp

最小可运行 Server：

from fastmcp import FastMCP

# 初始化 Server，起一个有描述性的名字
mcp = FastMCP("我的工具集")

@mcp.tool()
def get_weather(city: str, country: str = "中国") -> dict:
    """
    查询指定城市的天气信息
    
    Args:
        city: 城市名称，如"北京"
        country: 国家名称，默认"中国"
    
    Returns:
        包含温度、湿度、天气的字典
    """
    # 这里可以是真实 API 调用、数据库查询等
    return {
        "city": city,
        "temperature": 28,
        "humidity": 65,
        "weather": "晴转多云",
        "timestamp": "2026-07-15T10:30:00+08:00"
    }

@mcp.resource("info://app")
def get_app_info() -> str:
    """返回应用的基本信息"""
    return "# 应用信息\n这是一个演示 MCP Server。"

if __name__ == "__main__":
    mcp.run()

运行这个脚本后，就得到了一个完整的 MCP Server。它暴露了：

• 一个 get_weather 工具，Claude Desktop、Cursor 等客户端可以直接调用
• 一个 info://app 资源，AI 模型可以读取应用信息

进阶：暴露数据库查询工具

import asyncpg
from fastmcp import FastMCP

mcp = FastMCP("数据查询助手")

@mcp.tool()
async def query_orders(
    customer_id: int,
    status: str = "completed",
    limit: int = 100
) -> list[dict]:
    """
    查询指定客户的订单记录
    
    Args:
        customer_id: 客户ID
        status: 订单状态筛选，默认"completed"
        limit: 最大返回条数，默认100
    
    Returns:
        订单列表，每条包含订单ID、金额、创建时间等
    """
    conn = await asyncpg.connect(
        "postgresql://user:pass@localhost:5432/shop"
    )
    try:
        rows = await conn.fetch("""
            SELECT order_id, amount, created_at, status
            FROM orders
            WHERE customer_id = $1 AND status = $2
            ORDER BY created_at DESC
            LIMIT $3
        """, customer_id, status, limit)
        return [dict(r) for r in rows]
    finally:
        await conn.close()

# 启动时初始化数据库连接池
@mcp.on_start
async def initialize_db():
    mcp.settings.database_pool = await asyncpg.create_pool(
        "postgresql://user:pass@localhost:5432/shop",
        min_size=5, max_size=20
    )

这段代码展示了一个生产级的 MCP Server 实现：使用异步数据库连接池防止连接泄露，支持参数化查询防止 SQL 注入，通过 @mcp.tool() 装饰器将任意 Python 函数暴露为 MCP 工具。

5.2 TypeScript SDK：前端工程化的选择

对于前端团队或有 Node.js 背景的开发者，MCP 的 TypeScript SDK 提供了另一种选择：

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { 
  CallToolRequestSchema,
  ListToolsRequestSchema
} from "@modelcontextprotocol/sdk/types.js";

// 初始化 Server
const server = new Server(
  { name: "filesystem-tools", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

// 注册工具列表处理器
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "read_directory",
        description: "读取目录内容",
        inputSchema: {
          type: "object",
          properties: {
            path: { type: "string", description: "目录路径" },
            recursive: { type: "boolean", default: false }
          },
          required: ["path"]
        }
      },
      {
        name: "search_files",
        description: "在文件中搜索内容",
        inputSchema: {
          type: "object",
          properties: {
            pattern: { type: "string", description: "搜索正则表达式" },
            path: { type: "string", description: "搜索根目录" },
            maxResults: { type: "number", default: 50 }
          },
          required: ["pattern", "path"]
        }
      }
    ]
  };
});

// 注册工具调用处理器
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;
  
  switch (name) {
    case "read_directory":
      return await handleReadDirectory(args.path, args.recursive);
    case "search_files":
      return await handleSearchFiles(args.pattern, args.path, args.maxResults);
    default:
      throw new Error(`Unknown tool: ${name}`);
  }
});

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("MCP Server 已启动，等待请求...");
}

main().catch(console.error);

TypeScript SDK 的优势在于类型安全和IDE 支持。通过 JSON Schema 定义的 inputSchema，TypeScript 编译器可以在编译时捕获类型不匹配的问题。相比 Python 的动态类型，TypeScript 更适合大型团队协作开发复杂的 MCP Server。

六、生产实践：MCP 在企业级场景的落地架构

6.1 MCP Server 的注册与发现机制

在企业内部，MCP Server 往往不是孤立的，而是一个服务生态。这带来了一个问题：Host 怎么知道有哪些 Server 可用？

当前 MCP 生态有两种主流方案：

方案 A：配置文件（Claude Desktop 方式）

// ~/.config/claude-desktop/claude_desktop_config.json
{
  "mcpServers": {
    "filesystem-tools": {
      "command": "node",
      "args": ["/path/to/filesystem-server/dist/index.js"],
      "env": {
        "ALLOWED_PATHS": "/home/user/projects"
      }
    },
    "data-query": {
      "command": "python",
      "args": ["/opt/mcp/data-query-server/main.py"],
      "env": {
        "DB_HOST": "internal-db.company.com",
        "DB_NAME": "analytics"
      }
    }
  }
}

优点：简单直观，适合少量 Server
缺点：配置分散在每个客户端，无集中管理

方案 B：MCP Registry（企业推荐）

┌─────────────────┐
│ MCP Registry    │  集中管理 Server 元信息
│ (配置中心)       │  - Server 地址
└────────┬────────┘  - 版本号
         │            - 权限声明
┌────────▼────────┐  - 健康状态
│  MCP Gateway    │  统一的入口代理
│  (反向代理)      │  - 路由转发
└────────┬────────┘  - 流量控制
         │            - 鉴权
┌────────▼────────┐
│  MCP Server Pool │  多个 Server 实例
│  (水平扩展)       │  - 负载均衡
└─────────────────┘

Gateway 模式下，Client 只需配置一个 Registry 地址，Registry 动态返回可用 Server 列表。这个方案适合 Server 数量多、版本更新频繁的企业场景。

6.2 MCP 在 AI 编程助手中的落地

MCP 最早也是最成功的应用场景是 AI 编程助手。以 Cursor 为例，它内置了 MCP Client，支持连接各种开发工具 Server：

• 文件系统 Server：读写项目文件
• Git Server：执行 git 操作、查看 diff
• 终端 Server：执行命令行操作
• 数据库 Server：查询和修改数据库
• API Server：发送 HTTP 请求、测试接口

这种架构的优势是关注点分离：

• AI 模型的推理能力（MCP Client 侧）与具体工具的实现（Server 侧）完全解耦
• 工具开发者不需要了解 AI 模型的内部机制
• AI 应用开发者不需要为每个工具单独集成

6.3 权限控制：MCP 的安全边界

MCP 的权限控制是一个容易被忽视但极其重要的设计维度。当 AI 模型可以调用文件系统、数据库、API 等外部资源时，权限边界直接决定了系统的安全级别。

MCP 的权限模型分为三层：

第一层：传输层隔离

stdio 模式下，每个 Server 是独立进程，OS 进程权限天然提供隔离。HTTP(SSE) 模式下，需要在 Gateway 层实现认证（如 mTLS、JWT）。

第二层：Server 声明式权限

Server 在初始化时声明自己需要的权限：

@mcp.server(
    required_capabilities=["filesystem.read", "network.http"],
    max_concurrent_calls=10,
    timeout_seconds=30
)
class ProductionServer:
    pass

Client 在连接 Server 时会收到权限声明，用户（或管理员）可以选择拒绝连接危险的操作。

第三层：运行时参数校验

Server 对每次工具调用的输入参数进行严格校验：

@mcp.tool()
def delete_file(path: str) -> bool:
    # 路径白名单校验：只允许删除 /tmp 目录下的文件
    if not path.startswith("/tmp/"):
        raise ValueError("禁止删除 /tmp 目录之外的文件")
    
    # 类型校验：确保是字符串
    if not isinstance(path, str):
        raise TypeError("path 必须是字符串")
    
    return os.remove(path) is None

这个三层防御体系确保了即使 AI 模型被恶意 Prompt 注入攻击，攻击者也无法越过 Server 的安全边界。

6.4 性能优化：批量调用与流式响应

MCP 的性能瓶颈主要来自进程启动开销（stdio 模式）和网络延迟（SSE 模式）。针对这些问题，有几个成熟的优化策略：

策略 1：连接池复用

# 不推荐：每次调用都启动新进程
subprocess.run(["python", "slow-startup-server.py", ...])  # 慢！

# 推荐：启动后保持长连接
async with stdio_server() as (reader, writer):
    async for message in read_messages(reader):
        await process_and_respond(message, writer)

策略 2：批量工具调用

MCP 1.5+ 引入了 tools/batch 端点，允许客户端一次性发起多个工具调用，Server 可以并行处理：

@mcp.tool()
async def batch_search(queries: list[str]) -> list[SearchResult]:
    """并行执行多个搜索查询"""
    tasks = [search_engine.query(q) for q in queries]
    results = await asyncio.gather(*tasks, return_exceptions=True)
    return results

策略 3：流式响应

对于耗时较长的操作（如大规模文件分析），Server 可以通过 SSE 推送增量结果，避免客户端长时间等待：

async def analyze_large_codebase(root_path: str):
    for file in walk_files(root_path):
        result = await analyze_file(file)
        yield {  # Server-Sent Event 推送
            "event": "progress",
            "data": {
                "file": file,
                "findings": result,
                "progress": f"{processed}/{total}"
            }
        }

七、生态全景：MCP 周边工具与框架

7.1 官方与社区 MCP Server 生态

截至2026年中，MCP 的生态已经相当丰富：

官方维护的 MCP Server 列表在 GitHub 上持续更新，涵盖了主流开发场景的 90% 需求。

7.2 MCP 与 OpenAI Function Calling 的对比

这是很多开发者关心的问题：MCP 和 OpenAI 的 Function Calling 是什么关系？

两者并非简单的「替代关系」，而是互补：

• 在单一 AI 平台内，Function Calling 足够用
• 在多 Agent 协作或跨平台场景，MCP 是更好的选择

7.3 MCP 与 LangChain Tools 的关系

LangChain 是 AI 应用开发领域最流行的框架之一，它的 Tools 接口与 MCP 有大量重叠。那么用 LangChain 还需不需要 MCP？

答案是：MCP 是更底层的协议，LangChain 可以作为 MCP 的上层抽象。

┌─────────────────────────┐
│  AI Application         │  LangChain Agent / LlamaIndex
├─────────────────────────┤
│  Tool Abstraction Layer │  LangChain Tools / LlamaIndex Tools
├─────────────────────────┤
│  Standard Protocol      │  MCP Client (或 Function Calling)
├─────────────────────────┤
│  Tool Implementation    │  MCP Server / Native Tool
└─────────────────────────┘

LangChain 已经引入了对 MCP 的官方支持，开发者可以用 LangChain 的统一 Agent 接口，对接底层的 MCP Server。这种分层让框架层和协议层各司其职。

八、MCP 的局限性与未来演进

8.1 当前的技术局限

MCP 远非完美，以下几个问题在实际生产中值得关注：

1. 工具结果的 LLM 理解能力瓶颈

MCP 只负责「传递」工具调用和结果，但最终的「调用哪个工具、怎么组合」取决于 AI 模型的推理能力。当工具数量超过 50 个时，模型往往难以做出正确选择。这催生了工具编排层（Tool Orchestrator）的需求——在 MCP 之上加一层路由逻辑，根据用户意图分发到合适的工具。

2. 版本兼容性问题

MCP 协议版本仍在快速演进，不同 SDK 版本之间的兼容性偶尔会出现问题。协议层面的 breaking change 对已有 Server 的影响比想象中大。建议生产环境锁定 SDK 版本，并建立版本回归测试机制。

3. Server 的监控与可观测性

当前 MCP 生态缺乏统一的监控标准。Server 调用了多少次？平均响应时间是多少？有没有异常拒绝？这些问题目前没有开箱即用的答案。企业需要自行搭建 Prometheus + Grafana 监控体系，或者依赖商业 MCP Gateway 产品。

8.2 演进方向：MCP 2.0 的路线图

根据 Linux 基金会 Agentic AI Foundation 的公开讨论，MCP 的演进方向包括：

多模态工具：从文本扩展到图像、音频、视频处理工具。模型可以调用「图像生成工具」并直接将结果传给「图像识别工具」，实现多模态流水线。

Agent-to-Agent 协议：当前 MCP 是「AI 到工具」的协议，未来会扩展「AI Agent 到 AI Agent」的通信标准。想象两个 AI Agent 通过 MCP 协商任务分工、共享中间结果——这是多 Agent 协作的基础设施。

去中心化发现：从中心化 Registry 向去中心化的服务发现演进，使用分布式哈希表（DHT）在 Agent 网络中动态查找可用工具。

九、总结：MCP 为什么重要

回顾这两年 AI Agent 的发展历程，MCP 的出现是一个标志性事件。

在 MCP 之前，AI 应用开发者的处境是：每换一个 AI 模型，就要重新适配一套工具系统。Function Calling 看起来是标准，但实际上每家实现都不同，你写的每一个 Tool Adapter 都绑定了特定的模型。

MCP 的核心贡献是把「工具的定义」和「工具的使用者」彻底解耦。Server 声明自己的能力，Client 按需调用，两端独立演进。这种设计在软件工程领域被称为接口与实现分离，是构建可扩展系统的基本原则。

更重要的是，MCP 代表了一种生态思维：与其让每个 AI 厂商各自为战，不如在协议层面达成共识，让整个行业受益。这种开放协作的模式，才是 AI Agent 走向成熟的关键一步。

对于工程师来说，MCP 不是一个需要立即投入生产的前沿技术——但它是一个必须理解其原理、关注其发展的技术趋势。未来的 AI 应用架构中，MCP 很可能会像 USB 一样，成为连接 AI 与真实世界的基础设施。

理解它，就是理解 AI 应用架构下一个十年的方向。

参考资源：

• MCP 官方文档：https://modelcontextprotocol.io
• MCP Python SDK：https://github.com/modelcontextprotocol/python-sdk
• MCP TypeScript SDK：https://github.com/modelcontextprotocol/typescript-sdk
• MCP Server 示例集：https://github.com/modelcontextprotocol/servers
• Linux Foundation Agentic AI Foundation：https://lfai.foundation

本文系程序员茄子原创，深度解析技术趋势背后的工程原理。