目录

• 1. 从 Function Calling 说起
• 2. MCP 是什么
• 3. MCP 核心架构
• 4. 三大核心原语：Tools / Resources / Prompts
  • 4.1 Tools：可执行的动作
  • 4.2 Resources：可读取的上下文
  • 4.3 Prompts：可复用的模板
• 5. MCP 与 Function Calling 对比
• 6. 实战：用 Python 写一个 MCP Server
• 7. AI 工具生态的未来图景
• 8. 总结

1. 从 Function Calling 说起

2023 年，OpenAI 推出 Function Calling，第一次让大语言模型（LLM）从「只会聊天」变成「能调用外部工具」。开发者只需描述函数签名，模型就能在合适的时机生成结构化的调用参数，由应用侧执行后再把结果回传。

这几乎成了 AI 应用的标配：查天气、订机票、操作数据库、调用内部 API，都可以通过几行 JSON Schema 描述完成。

但 Function Calling 更像一个「能力开关」，而不是一套「生态协议」。当工具数量变多、跨应用协作变复杂时，它的短板逐渐暴露出来：

• 一次性描述：每轮请求都要把工具列表塞进上下文，工具多了会撑爆 Token；
• 强绑定厂商：OpenAI 的格式、Anthropic 的格式、国产模型的格式各不相同，迁移成本高；
• 只有「调用」，没有「发现」：模型无法主动了解自己能用什么资源，只能被动接收开发者塞进来的定义；
• 工具即函数：只能表达「执行一个动作」，难以表达「读取一份文档」「订阅一个事件」等更丰富的交互。

2024 年底，Anthropic 发布了 MCP（Model Context Protocol，模型上下文协议），试图用一套开放协议解决这些问题。它的定位很明确：把 Function Calling 从「厂商特性」升级为「行业标准」，让 AI 应用和外部工具、数据源之间的连接像 USB-C 一样即插即用。

2. MCP 是什么

MCP 是一套开放的、模型无关的协议，定义了 AI 应用如何与外部系统交换上下文。它的核心思想可以用一句话概括：

不再为每个模型、每个工具重复写胶水代码，而是用统一协议连接「模型」和「能力」。

官方将 MCP 类比为 AI 世界的「USB-C 接口」——过去的 AI 应用要对接 N 个数据源，需要写 N 套自定义集成；有了 MCP，任何支持 MCP 的客户端都能直接消费任何 MCP 服务端提供的能力。

它的价值体现在三个层面：

• 对模型厂商：无需为每个工具生态单独做适配，只要支持 MCP 客户端协议即可；
• 对工具/数据提供方：一次实现 MCP 服务端，就能被所有主流 AI 应用发现和使用；
• 对开发者：聚焦业务本身，不必反复处理五花八门的调用格式。

3. MCP 核心架构

MCP 采用经典的 Client-Host-Server 架构，三个角色职责分明：

• Host：承载 AI 对话的应用，例如 Claude Desktop、IDE 插件或自研聊天机器人。它负责接收模型意图并驱动工具调用；
• Client：运行在 Host 内部，与 Server 建立一对一的 MCP 连接，负责协议层的收发；
• Server：对外暴露具体能力（读文件、查数据库、调 API 等）的进程。

传输层支持两种方式：stdio（本地标准输入输出，适合本机工具）和 SSE / Streamable HTTP（适合远程服务）。本地工具默认走 stdio，实现简单、零网络配置；远程工具则走 HTTP，便于团队共享和安全管控。

4. 三大核心原语：Tools / Resources / Prompts

MCP 把模型可以消费的东西抽象为三种原语，这是它和 Function Calling 最本质的区别——Function Calling 只有「工具执行」一个维度，而 MCP 提供了更完整的上下文协议。

4.1 Tools：可执行的动作

tools 对应 Function Calling 里的函数，服务端通过 tools/list 暴露工具列表，客户端调用 tools/call 触发执行。每个工具包含名称、描述和输入 Schema：

{
  "name": "get_weather",
  "description": "查询指定城市的实时天气",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "城市名，如 北京" }
    },
    "required": ["city"]
  }
}

模型看到这份 Schema 后，就能决定何时调用、用什么参数。

4.2 Resources：可读取的上下文

resources 用于让模型读取数据，而不是执行动作。服务端通过 resources/list 暴露文档、文件、数据库记录等资源，客户端通过 resources/read 获取内容。它解决了一个常见痛点：把「该给模型看什么」的决策权从应用侧下放给服务端。

例如一个「代码库 Server」可以把仓库里的 README、配置文件声明为资源，模型按需读取，而不需要开发者预先把所有文件内容塞进 Prompt。

4.3 Prompts：可复用的模板

prompts 是服务端预定义的提示词模板，客户端可以拉取并交给用户选择。它让「最佳提问方式」可以在团队内沉淀和复用，尤其适合企业知识库、客服话术等场景。

三者的定位可以简单记忆：

• Tools：模型要求做什么；
• Resources：模型可以读什么；
• Prompts：模型该怎么被引导。

5. MCP 与 Function Calling 对比

维度	Function Calling	MCP
协议性质	厂商私有特性	开放标准协议
工具发现	应用侧硬编码注入	服务端动态暴露，模型可发现
能力维度	仅动作执行	动作 + 资源 + 提示模板
上下文管理	每轮重复传工具定义	工具列表可缓存、按需加载
跨平台	各厂商格式不一	一次实现，多方复用
典型场景	单应用内函数调用	多应用、多数据源的 AI 生态

需要强调的是，两者并非替代关系：MCP 的核心原语之一 tools 本质上就是一种标准化的 Function Calling。MCP 解决的是「连接」问题，Function Calling 解决的是「调用」问题。在实际工程中，很多团队会用 MCP Server 封装内部能力，再由模型通过 Function Calling 触发，二者协同工作。

6. 实战：用 Python 写一个 MCP Server

下面用官方 Python SDK 实现一个最小的 MCP Server，暴露一个「获取当前时间」的工具。

安装依赖：

pip install mcp

服务端代码 server.py：

from datetime import datetime

from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent


# 1. 创建 Server 实例
app = Server("time-server")


# 2. 注册工具列表
@app.list_tools()
async def list_tools() -> list[Tool]:
    return [
        Tool(
            name="get_current_time",
            description="获取服务器当前的日期和时间",
            inputSchema={
                "type": "object",
                "properties": {
                    "timezone": {
                        "type": "string",
                        "description": "时区名称，如 Asia/Shanghai，默认 UTC",
                    }
                },
            },
        )
    ]


# 3. 实现工具调用逻辑
@app.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    if name == "get_current_time":
        timezone = arguments.get("timezone", "UTC")
        # 简化示例：真实场景可接入 zoneinfo 处理时区
        now = datetime.utcnow().isoformat()
        result = f"当前 UTC 时间为：{now}（请求时区：{timezone}）"
        return [TextContent(type="text", text=result)]

    raise ValueError(f"未知工具: {name}")


# 4. 通过 stdio 启动服务
async def main():
    async with stdio_server() as (read_stream, write_stream):
        await app.run(
            read_stream,
            write_stream,
            app.create_initialization_options(),
        )


if __name__ == "__main__":
    import asyncio

    asyncio.run(main())

在客户端接入（以 Claude Desktop 为例）：

在配置文件中注册这个本地 Server：

{
  "mcpServers": {
    "time-server": {
      "command": "python",
      "args": ["/path/to/server.py"]
    }
  }
}

重启客户端后，模型就能自动发现 get_current_time 工具，并在合适的对话场景中主动调用它。整个过程无需关心厂商的调用格式，也无需在每轮对话手动传工具定义。

7. AI 工具生态的未来图景

MCP 的真正价值不在于「又一个协议」，而在于它可能催生一个 AI 工具市场：

几个可以预见的趋势：

• 工具即服务（Tool-as-a-Service）：企业把内部 API 包装成 MCP Server 对外发布，AI 应用像订阅 SaaS 一样订阅能力；
• Agent 协作标准化：多智能体之间通过 MCP 交换工具和资源，形成可组合的 Agent 网络；
• 更轻的上下文注入：模型不再被一次性塞满全部工具定义，而是按需发现、按需读取，显著降低 Token 消耗；
• 安全与权限前置：MCP Server 自带能力边界，结合 OAuth 等授权机制，让模型调用可审计、可管控。

当然，生态成熟还需要时间。目前 MCP 仍处于快速演进阶段，各 SDK 和客户端的实现存在差异，但方向已经非常清晰：让 AI 从「能调用工具」走向「能连接世界」。

8. 总结

Function Calling 教会了模型「如何调用」，而 MCP 正在定义模型「如何连接」。前者是单点能力，后者是生态协议。

对于开发者来说，现在是最好的切入点：把团队高频使用的内部能力封装成 MCP Server，既能立即在 Claude、Cursor 等支持 MCP 的工具中受益，也为未来的 Agent 化改造提前布局。

从「写 JSON Schema 描述函数」到「发布一个可被任意 AI 应用发现的 Server」，这中间隔着的，正是下一个时代的入口。