MCP（Model Context Protocol，模型上下文协议）不是某个模型的插件，也不是 Function Calling 的同义词。它更像 AI 时代的 USB-C 接口：AI 应用不用为 GitHub、数据库、文件系统、Slack、企业内部 API 各写一套私有适配，只要这些能力按 MCP 规范做成 MCP Server，支持 MCP 的客户端就能统一发现、连接和调用。

AI 工具调用的本质是三件事：模型知道有哪些能力、模型能表达要用哪个能力、宿主程序能安全执行这个能力。Function Calling 主要解决第二件事；MCP 主要解决第一件和第三件事的标准化。

核心判断：如果只是一个应用里内置几个函数，用 Function Calling 就够；如果一个工具要被 Claude、Cursor、VS Code、自研 Agent 等多个客户端复用，就应该考虑 MCP。

一、没有 MCP 之前，AI 接工具为什么麻烦？

假设你要让 AI 助手访问 GitHub、Postgres、文件系统和企业工单系统。没有统一协议时，每个客户端都要分别适配每个工具：工具描述怎么写、参数怎么校验、认证怎么传、错误怎么返回、执行结果怎么交给模型，全部都要重复设计。

这不是写几个 HTTP 接口那么简单。AI 工具调用还多了一个不稳定因素：模型会根据自然语言自己选择工具。工具名称写得不清楚，模型可能误调用；权限边界做得不严，模型可能越权写入；返回结果太乱，模型又可能理解错。

MCP 的价值就在这里：工具提供方不再围绕某一个模型做私有适配，而是实现一个 MCP Server；AI 应用侧实现 MCP Client；双方通过统一协议交换工具、资源和提示词能力。工具实现一次，就可以被多个 MCP Host 使用。

二、MCP 和 Function Calling 到底差在哪？

很多人会说：“Function Calling 不是已经能调工具了吗，为什么还要 MCP？”这个问题的关键在于：Function Calling 和 MCP 不是同一层。

Function Calling 更靠近模型层。它告诉模型：当你需要某个能力时，请按 JSON Schema 输出工具名和参数。至于这个工具在哪里、谁来执行、怎么鉴权、结果怎么返回、工具列表怎么动态更新，Function Calling 本身并不负责。

MCP 更靠近协议层。它定义 Host、Client、Server 之间怎么连接，Server 如何暴露 Tools、Resources、Prompts，Client 如何发现能力，双方如何用 JSON-RPC 交互，传输层用 STDIO 还是 Streamable HTTP。

可以这样理解：Function Calling 让模型“会喊工具”，MCP 让工具“能被统一接进来”。真正的工程系统里，两者经常一起出现：MCP Client 先从 MCP Server 拿到工具定义，再把这些工具转换成模型可理解的 function/tool schema，模型决定调用后，再由 MCP Client 把请求路由到对应 Server。

三、MCP 的架构：Host、Client、Server

MCP 采用 Client-Server 架构。这里最容易混淆的是 Host 和 Client。Host 是用户真正打开的 AI 应用，比如 Claude Desktop、Cursor、VS Code 插件或公司自研 Agent。Client 是 Host 内部用于连接某个 MCP Server 的组件。Server 是封装外部系统能力的程序，比如 GitHub MCP Server、Filesystem MCP Server、Postgres MCP Server。

一个 Host 可以同时连接多个 MCP Server。连接方式通常是一对一：Host 内部为每个 Server 维护一个 Client，这样每个连接都有独立能力、独立鉴权和独立生命周期。

这里的 Server 不等于云端服务器，它只是“提供 MCP 能力的程序”。它可以运行在本地，比如文件系统 Server；也可以运行在远程，比如企业数据库 Server 或 SaaS Connector。

四、MCP Server 的三类核心能力

MCP Server 可以暴露三类核心能力：Tools、Resources、Prompts。它们的区别非常重要，因为很多初学者会把所有东西都做成 Tool，最后导致权限难控、上下文混乱、模型误调用。

Tools 是可执行动作。比如“创建 GitHub Issue”“发送 Slack 消息”“查询天气”“执行数据库查询”。只要调用后可能改变外部世界，或者会消耗资源、触发副作用，就应该按工具治理，必要时加入用户确认。

Resources 是只读上下文。比如文件内容、数据库 schema、API 文档、项目配置。它更像“给模型看的资料”，通常由应用决定什么时候读，而不是模型想改就改。

Prompts 是可复用提示词模板。比如代码审查模板、SQL 生成模板、周报模板。Prompts 通常是用户主动选择的能力，用来把团队经验沉淀成标准交互。

五、一次 MCP 调用是怎么发生的？

MCP 的一次调用可以拆成六步：初始化、发现能力、模型选择、执行工具、返回结果、生成回答。真正落地时，不要跳过前两步，因为工具发现和能力协商决定了后面的调用是否可靠。

第一步是 initialize。Client 和 Server 协商协议版本、能力和身份信息。第二步是 tools/list、resources/list、prompts/list 等能力发现。Server 返回工具名称、描述、输入 schema，Client 再把这些信息整理进工具注册表。第三步，模型根据用户问题和工具说明决定是否调用。第四步，Client 通过 tools/call 调 Server。第五步，Server 返回结构化结果。最后，模型把结果写成自然语言回复。

下面是 JSON-RPC 层的简化示意：

1. 初始化连接

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
        "protocolVersion": "2025-06-18",
        "capabilities": {

        },
        "clientInfo": {
            "name": "demo-client",
            "version": "1.0.0"
        }
    }
}

2. 发现工具

{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/list"
}

3. 调用工具

{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/call",
    "params": {
        "name": "weather_current",
        "arguments": {
            "location": "Shanghai",
            "units": "metric"
        }
    }
}

这个例子说明：MCP 的底层不是“随便传一段字符串”，而是有明确请求 id、method、params 的 RPC 协议。这样才能做到请求响应可追踪、工具调用可审计、能力变更可通知。

六、数据层和传输层：为什么 MCP 能本地也能远程？

MCP 可以拆成两层：数据层和传输层。数据层规定消息语义，比如 initialize、tools/list、tools/call；传输层规定消息怎么送，比如本地 STDIO，或者远程 Streamable HTTP / SSE。

STDIO 适合本地能力，比如 Claude Desktop 启动一个本地文件系统 MCP Server。它不需要暴露公网端口，延迟低，适合个人开发和 IDE 场景。Streamable HTTP 适合远程服务，比如公司内部知识库、数据库、SaaS 工具、统一网关。远程模式一定要重视认证、授权、日志和数据脱敏。

七、写一个最小 MCP Server

MCP Server 本质是把你已有的函数、数据和模板包装成标准能力。下面用 Python SDK 的风格写一个简化示例：一个工具、一个资源、一个提示词。实际项目要以你使用的 SDK 版本为准。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Demo Server")

@mcp.tool()
def add(a: int, b: int) -> int:
"""Add two numbers."""
return a + b

@mcp.resource("user://{user_id}")
def get_user_profile(user_id: str) -> str:
"""Read a user profile as context."""
return f"User profile for {user_id}"

@mcp.prompt()
def review_code(code: str) -> str:
"""Create a reusable code review prompt."""
return f"请从可读性、安全性、性能三个角度审查代码：\n{code}"

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

这段代码背后的关键不是“装饰器很方便”，而是它把函数签名、类型注解、docstring 转成 MCP 能力描述。Client 发现这个 Server 时，就知道有哪些工具、需要什么参数、如何把结果放回模型上下文。

注意：Tool 的描述要写清楚“什么时候用、输入是什么、有什么副作用”。不要只写 search、query、run 这种泛名。工具名和描述越模糊，模型误调率越高。

八、MCP 适合哪些场景？

MCP 最适合“工具多、客户端多、上下文多、权限复杂”的场景。比如 AI IDE 要读代码仓库、企业问数要连数据库、客服助手要读知识库和工单系统、运营助手要调用 CRM 和消息系统。

反过来，如果你的系统只是一个简单聊天机器人，只有两个内部函数，而且不会给别的客户端复用，那没必要为了 MCP 上复杂度。直接 Function Calling + 后端函数路由就够了。

九、上线 MCP 最重要的不是“能调”，而是“能控”

MCP 会让工具接入变简单，但简单不等于安全。模型会根据自然语言自动选择工具，这意味着你的 Server 一旦暴露了危险能力，就可能被错误调用、被提示词注入诱导调用，甚至被越权调用。

生产环境要坚持最小权限原则：只暴露必要工具；写操作必须确认；工具参数要做 schema 校验和业务校验；每次调用要记录用户、工具、参数摘要、结果摘要、耗时和失败原因；敏感字段要脱敏；远程 Server 必须做认证和授权。

还有一个容易忽略的问题：MCP Server 不是“模型的玩具”，而是高权限后端服务。你给它文件系统权限，它就能读文件；给它数据库写权限，它就能改数据。模型只是发起调用，真正承担后果的是 Server 和宿主应用。

十、面试里怎么讲 MCP？

如果要在面试或技术文章中一句话讲清 MCP，可以这样说：

MCP 是一个开放协议，用来标准化 AI 应用与外部工具、数据源、提示词模板之间的连接。它采用 Host-Client-Server 架构，Server 暴露 Tools、Resources、Prompts，Client 通过 JSON-RPC 发现和调用这些能力。Function Calling 解决的是模型如何输出调用意图，MCP 解决的是工具如何被统一接入和复用。

再展开一点，可以补充三点：第一，MCP 的核心价值是把碎片化工具接入标准化，降低重复适配成本；第二，MCP 的核心抽象是 Host、Client、Server 以及 Tools、Resources、Prompts；第三，真正生产落地要重点处理权限、审批、日志、异常、限流和数据泄露风险。

十一、总结

MCP 的出现，不是因为 Function Calling 不够用，而是因为工具生态太碎片化。Function Calling 让模型能够表达“我要调用什么”；MCP 让外部系统能够以统一方式被 AI 应用发现、连接和调用。

如果说 RAG 解决的是“模型怎么读知识”，Function Calling 解决的是“模型怎么喊工具”，那么 MCP 解决的是“工具怎么标准化接入 AI 生态”。这就是它为什么会被称为 AI 应用的 USB-C。

真正把 MCP 用好，关键不是追概念，而是把三件事做好：工具边界清晰、权限治理可靠、调用链路可观测。只要这三件事稳，MCP 就不只是一个面试名词，而是可以落到企业 Agent 平台里的基础设施。