在USB-C出现之前，我的背包里永远躺着四根线：一根Micro USB给充电宝，一根Lightning给手机，一根方口给相机，还有一根圆头给电动牙刷。每次出门都像一场“线缆大联欢”，丢了一根等于一个设备变砖。直到USB-C普及，我才换成一根线走天下——新买的设备只要说“我支持USB-C”，我就能直接接上。AI的工具接入世界，正在经历同样的重组。 MCP（Model Context Protocol，模型上下文协议）就是AI领域的“USB-C“。在MCP之前，想让AI助手调用一个工具，需要为每个工具专门写一套”定制接线”：从API鉴权、参数拼装，到结果解析，全部手动实现。工具一多，代码量爆炸。MCP由Anthropic于2024年11月开源，定义了一套统一协议：AI应用只需实现一次客户端连接，就能发现并调用任何实现了MCP Server的工具。

岗位关联

学会MCP，你就掌握了AI应用开发中“工具接入”的标准答案。无论未来出现多少新工具，都能用同一套方法快速打通，让AI真正“动手做事”成为工程现实。

目录
  1. 可视化演示
  2. 概念本质
  3. 架构角色
  4. 核心原语
  5. 通信流程
  6. 关键设计
  7. 工程实践
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示MCP工具标准化协议核心机制：三阶段通信流程演示握手初始化/工具发现/工具调用；Server分类展示数据源/API/工具类Server；动态发现展示Agent自动发现并调用工具的过程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

MCP三阶段通信 Init→Find→Call工具调用流程 3-Phase 握手初始化发现工具并执行调用

概念本质

在USB-C出现之前，我的背包里永远躺着四根线：一根Micro USB给充电宝，一根Lightning给手机，一根方口给相机，还有一根圆头给电动牙刷。每次出门都像一场“线缆大联欢”，丢了一根等于一个设备变砖。直到USB-C普及，我才换成一根线走天下——新买的设备只要说“我支持USB-C”，我就能直接接上。AI的工具接入世界，正在经历同样的重组。

MCP（Model Context Protocol，模型上下文协议）就是AI领域的“USB-C“。在MCP之前，想让AI助手调用一个工具，需要为每个工具专门写一套”定制接线”：从API鉴权、参数拼装，到结果解析，全部手动实现。工具一多，代码量爆炸。MCP由Anthropic于2024年11月开源，定义了一套统一的协议：AI应用只需实现一次客户端连接，就能发现并调用任何实现了MCP Server的工具。

从工程视角看，MCP的价值可以提炼为一个成本公式：传统方式的集成成本与工具数量线性增长——每接入一个工具都要付出一份定制的兼容层成本；而MCP将兼容层“归一化”，成本变成一次性投入。换句话说，生态里已有的MCP Server，你的AI应用直接“插上就能用”。

回到比喻：今天买设备只问“支不支持USB-C”，明天接工具只问“有没有MCP Server”。当年背包里的四根线变成了一根线，连接方式彻底统一，这就是工具标准化协议的最大意义。

集成成本∝N工具×C定制→MCPC一次\text{集成成本} \propto N_{\text{工具}} \times C_{\text{定制}} \xrightarrow{\text{MCP}} C_{\text{一次}}
$N_{\text{工具}}$ 是工具数量，$C_{\text{定制}}$ 是每个工具的定制成本，$C_{\text{一次}}$ 是一次性接入成本。MCP 把“乘上一个很大的数”变成了“加一个常数”。
  1. 工具数量 $N_{\text{工具}}$指要接入的外部工具总数，比如数据库、文件系统、邮件服务。没有标准化时，每多一个工具就多一份工作量。
    N工具N_{\text{工具}}
  2. 定制成本 $C_{\text{定制}}$为单个工具编写的连接代码与维护成本，包含鉴权、参数转换、错误处理等琐碎工作。
    C定制C_{\text{定制}}
  3. 传统总成本 $N_{\text{工具}} \times C_{\text{定制}}$总成本等于工具数量乘单个定制成本，工具越多成本线性膨胀。
    N工具×C定制N_{\text{工具}} \times C_{\text{定制}}
  4. MCP的一次性成本 $C_{\text{一次}}$实现一次MCP Client后，所有兼容Server都能接入，成本从“每个工具一次”变成“总共一次”。
    C一次C_{\text{一次}}

架构角色

USB-C线缆本身并不神奇，神奇的是接口内部的分工：负责识别设备的协议芯片、负责供电的引脚、负责数据传输的通道，各司其职，才让“一根线通吃”成为可能。MCP的架构也有类似的角色划分。

MCP将一个连接拆成四个角色。Host（主机）是AI应用本身，比如Claude Desktop或你正在开发的智能客服应用，它是用户体验的载体，也是用户授权的边界。Client（客户端）运行在Host内部，负责与Server建立一对一的连接，维护会话状态。Server（服务端）是独立的进程，它把真实工具——文件系统、数据库、外部API——包装成标准的MCP能力，供AI调用。传输层（Transport）则规定了消息在Client与Server之间怎么流动：本地常用stdio标准输入输出，远程可以用Streamable HTTP或SSE。

这四个角色共同构成一次MCP会话。Host可以同时持有多个Client，每个Client连接一个Server；换句话说，一个AI应用可以同时插上多个“USB-C设备”，每个设备对应一套独立的Server进程。

理解了这些角色，再看整个架构就像看一台笔记本连着扩展坞：Host是笔记本，Client是扩展坞上的每个插口，Server是插在外设上的设备，传输层是线缆。每个角色都清楚自己的位置，这正是协议能标准化的前提。

会话={Host,Client,Server,Transport}\text{会话} = \{\text{Host}, \text{Client}, \text{Server}, \text{Transport}\}
一次MCP会话由四个基本元素组成：应用层的主机、连接层的客户端、能力层的服务端，以及物理通道上的传输方式。
  1. Host主机用户直接面对的AI应用，负责整体流程编排、UI展示、用户授权提示。它像笔记本电脑，是所有外设（工具）服务的中心。
    Host\text{Host}
  2. Client客户端在Host内部为每个Server维持一个专用连接对象，负责发送请求、接收响应。像USB控制器，管理着每个端口的通信。
    Client\text{Client}
  3. Server服务端包装具体工具逻辑的进程，暴露工具、资源、提示等能力。像充电宝、显示器这样的外设本体，自带能力描述。
    Server\text{Server}
  4. Transport传输层定义消息传输的通道标准，本地用stdio，远程用HTTP或SSE。像USB-C线缆本身，只负责把信号送达。
    Transport\text{Transport}

核心原语

当USB-C设备插入电脑，电脑会自动读到一份“能力描述”：这个显示器支持视频传输，那个硬盘支持供电回充。MCP Server也向AI应用提供类似的“能力描述”，称为原语（Primitive）。MCP定义了四种核心原语，它们共同构成AI与工具交互的词汇表。

工具（Tools）是最常用的原语，它对应一个可执行的函数，比如“搜索文件”“发送邮件”。AI通过模型自主决定何时调用工具，工具可以返回结构化数据。资源（Resources）是只读数据，比如一份CSV文件、一篇文章内容，AI按URI定位并读取，不需要执行任何东西。提示（Prompts）是预定义的提示词模板，例如“分析这段日志”，供用户在合适时机复用。采样（Sampling）则允许Server反过来请求模型生成本文，实现模型与模型之间的协作。

其中，工具原语的定义结构尤为关键。每个工具必须通过JSON Schema描述自己的名称、用途和参数结构，这样AI才能正确地决定“要不要用、怎么传参”。一个工具的定义，本质上是一份写给AI看的“使用说明书”。

这四种原语就像USB-C设备的能力描述：工具是“供电输出”，资源是“只读数据通道”，提示是“预设显示模式”，采样是“双向数据传输”。它们的共同点是不需要双方预先约定，而是由Server主动暴露、Client动态发现。

Tool={name,description,input_schema}\text{Tool} = \{\text{name}, \text{description}, \text{input\_schema}\}
一个工具由三个字段定义：名称是它的唯一标识，描述告诉AI它做什么，input_schema用JSON Schema格式规定参数长什么样。
  1. 名称 name工具的唯一ID，比如 search_files。AI通过这个字符串在对话中引用工具，命名必须清晰、无歧义。
    name\text{name}
  2. 描述 description用自然语言说明工具的用途和适用场景。这条文本会直接注入模型上下文，描述质量决定AI选工具的准确率。
    description\text{description}
  3. 参数结构 input_schema用JSON Schema声明参数类型、必填项与约束。AI根据它生成合法的参数对象，比“让AI猜”可靠得多。
    input_schema\text{input\_schema}

通信流程

你每次插入USB-C线，设备并不会立即通电，而是先发生一次“带外握手”：双方交换身份、协商供电能力和传输协议，然后才进入正常工作状态。MCP的通信流程同样遵循“先握手、再干活”的节奏。

一次完整的MCP交互包含四个阶段。初始化握手（initialize）：Client向Server发送客户端信息和协议版本，Server回复自己的能力列表，双方达成一致后，连接进入可用状态。工具发现（tools/list）：Client请求Server返回所有可用工具的定义列表，这就好比USB-C设备上报自己的能力描述。工具调用（tools/call）：AI决定使用某个工具后，Client向Server发起带参数的方法调用请求。结果返回（result）：Server执行工具函数，将结果——可能是文本、JSON或图片——返回给Client，最终呈现在用户面前。

这四个阶段构成一个严谨的生命周期：先建立信任和约定，再暴露能力清单，然后精准调用，最后返回成果。任何一步失败，都可以在对应的阶段中止并恢复。

把这个流程对应回USB-C场景：握手是“检测到设备”，发现是“识别设备型号”，调用是“发起数据传输”，返回是“展示传输结果”。正是这样一套标准化的序列，让双方即使从未见过对方，也能可靠地协作。

生命周期=⟨initialize,list,call,result⟩\text{生命周期} = \langle \text{initialize}, \text{list}, \text{call}, \text{result} \rangle
这个有序序列描述了MCP连接从建立到执行一次工具调用的完整路径：初始化、发现、调用、返回。每一步都遵循协议规定的消息格式。
  1. 初始化握手 initializeClient发送 initialize 请求，携带协议版本和客户端能力；Server回复 capabilities 字段，声明自己支持哪些原语。
    initialize\text{initialize}
  2. 工具发现 listClient调用 tools/list 获取全部工具定义，这些定义会作为上下文被注入模型，辅助AI规划下一步动作。
    list\text{list}
  3. 工具调用 callAI根据上下文选出工具后，Client发送 tools/call 请求，包含工具名和符合schema的参数。
    call\text{call}
  4. 结果返回 resultServer返回执行结果，并附带 isError 字段标记是否出错；结果可以是纯文本、JSON，也可以是带MIME类型的资源内容。
    result\text{result}

关键设计

USB-C协议之所以强大，不仅因为接口形状统一，更因为它对每个引脚的功能、电压的范围、数据的格式都做了精确规定。MCP同样有一系列关键设计，保证协议在真实世界的复杂环境中仍然可靠。

首先是消息格式。MCP底层基于 JSON-RPC 2.0，每条消息是一个JSON对象，包含协议版本、请求ID、方法名和参数四部分。请求ID让一对请求和响应能够精确匹配，这是维持长连接会话的基础。其次是会话管理：Client与Server之间保持持久连接，所有工具调用共享一个会话上下文，服务器可以维持状态或记录日志。第三是安全边界：MCP要求工具调用前必须经过用户授权，特别是涉及高危操作时，Host必须弹出确认提示；同时Server可配置允许调用的工具范围，形成最小权限原则。最后是错误处理：协议定义了标准错误码（如 -32700 解析错误、-32601 方法不存在），并支持部分失败——一次调用多个工具时，单个失败不影响其他结果返回。

这四项设计构成MCP的“可靠性底座”。没有统一消息格式，双方就没法通信；没有会话管理，请求就会互相串线；没有安全边界，恶意工具可能被悄悄调用；没有错误处理，一个异常就能拖垮整个AI应用。

就像USB-C的引脚定义决定了一切兼容性，JSON-RPC的字段规范决定了MCP对话的秩序。有了统一的“语法”，任何语言实现的服务端和客户端才能实现真正的互联互通。

Message={jsonrpc,id,method,params}\text{Message} = \{\text{jsonrpc}, \text{id}, \text{method}, \text{params}\}
MCP的每条请求消息都遵循JSON-RPC 2.0结构：声明协议版本、携带唯一ID、指定方法名、附上参数对象。响应消息则通过相同的ID与请求配对。
  1. 协议版本 jsonrpc固定为 "2.0"，表示使用JSON-RPC 2.0规范，保证收发双方对消息结构理解一致。
    jsonrpc\text{jsonrpc}
  2. 请求ID id一个数字或字符串，Client生成后原样带回，用于把响应与请求配对，避免多路复用时的混乱。
    id\text{id}
  3. 方法名 method字符串，如 "tools/call"、"resources/read"。它决定Server执行什么操作。
    method\text{method}
  4. 参数对象 params一个结构化对象，携带方法所需的参数，例如工具名称和参数集合。
    params\text{params}

工程实践

理解了协议原理，就像读完了USB-C的技术白皮书——但把一个个接口焊到产品上，才是工程师真正的工作。MCP的工程实践同样遵循一套成熟的SOP。

第一步是开发步骤：先用官方参考Server模板初始化项目，定义好要暴露的工具函数，再实现对应的处理逻辑，最后注册到MCP Server实例上。第二步是SDK辅助：官方提供Python、TypeScript等语言的SDK，屏蔽了底层JSON-RPC和传输层细节，开发者只需用装饰器或注册函数声明工具。第三步是测试调试：可以用MCP Inspector这类可视化工具，模拟Client行为，逐条查看请求与响应报文；也可以写单元测试直接调用工具函数，再写集成测试走完整协议链路。第四步是关注演进方向：MCP社区正在推进OAuth认证、远程服务器标准、更细粒度权限控制，HTTP传输也逐渐成为主流。

工程实践中有一条经验法则：可靠性取决于两个动作的配合。网络请求不稳定，就要设计重试和退避；上游工具异常，就要准备降级方案——不能因一个问题工具而让整个AI任务失败。

回到比喻：重试是“重新插一次线”，降级是“这根线坏了就换另一根接口”。真正的工程师不会只靠一根线——他们会在包里备好冗余、备好预案，让系统在任何情况下都稳稳运行。

可靠性=重试次数+降级策略\text{可靠性} = \text{重试}^{\text{次数}} + \text{降级策略}
可靠性工程的两大支柱：对可恢复的失败进行重试（指数退避），对不可恢复的失败准备降级策略（返回兜底结果或跳过工具）。
  1. 重试 $\text{重试}$当网络抖动或Server短暂不可用时，按指数退避策略重新发送请求，防止瞬时故障直接导致任务失败。
    重试\text{重试}
  2. 次数 $\text{次数}$限制重试上限（如3-5次），避免无限重试耗尽资源或放大系统压力。
    次数{\text{次数}}
  3. 降级策略 $\text{降级策略}$当工具持续失败时，返回缓存结果、给出友好提示或跳过该工具，保证核心功能不受影响。
    降级策略\text{降级策略}
  4. 可靠性 $\text{可靠性}$重试与降级共同决定了AI应用在真实环境中的稳定性，两者缺一不可。
    可靠性\text{可靠性}

AI 应用场景

智能桌面助手接入办公套件

阶段：工具接入与工具调用

解决的问题：传统方式中，Claude Desktop每接入一个办公工具（如日历、邮件、待办列表）都要单独开发集成模块，每个模块的鉴权和数据格式各不相同，维护成本极高。通过MCP，只需为每个办公工具运行一个标准Server，AI助手通过统一的tools/list发现它们、通过tools/call调用它们。

具体案例：一位产品经理在Claude Desktop中说“查看明天上午的会议提醒，并把项目周报发给团队”。Claude通过MCP同时调用日历Server（查会议）和邮件Server（发周报），整个过程只发出一串标准化JSON-RPC消息，无需关心底层API差异。

企业知识库问答系统的统一检索

阶段：数据接入与上下文检索

解决的问题：企业知识库往往分散在Wiki、数据库、共享网盘等多个系统。传统做法是为每个数据源写一段检索代码，再拼接成上下文。用MCP统一封装后，每个数据源只要实现Resources原语，AI就能用统一的方式读取内容。

具体案例：某金融公司构建内部问答机器人。工程师将合规文档库、客户数据库、产品手册各自包装为MCP Server。员工提问“最近的退汇率是多少”，机器人自动从数据库Server读取实时指标，从文档Server检索规则说明，再综合生成回答。

IDE插件中的代码能力扩展

阶段：工具发现与动态调用

解决的问题：AI编程助手需要调用代码搜索、git操作、构建命令等多样工具。MCP的Prompts与Tools原语让IDE插件可以在运行时动态发现新工具，用户自定义一种工具，AI即学即用，无需重新发布插件。

具体案例：开发者在VS Code插件中注册了一个“一键生成数据库迁移脚本”的MCP工具，包含参数schema和提示词模板。AI在对话中感知到用户想做数据库变更时，自动调用该工具并生成迁移SQL文件。

Python 演示

python23 行
"""MCP 服务器最小示例: 通过标准协议暴露两个数学工具.""" from mcp.server.fastmcp import FastMCP # 创建 MCP 服务器实例, 客户端初始化时会看到名称mcp = FastMCP("math-tools")  @mcp.tool()def add(a: int, b: int) -> int:    """两数相加"""    return a + b  @mcp.tool()def multiply(a: int, b: int) -> int:    """两数相乘"""    return a * b  if __name__ == "__main__":    # 通过标准输入输出传输运行, 供 Host 进程调用    mcp.run(transport="stdio")
目的：用官方Python SDK实现一个最简MCP Server，暴露两个数学工具。任何MCP客户端（如Claude Desktop）只需配置文件即可发现并调用这两个工具。
  1. from mcp.server.fastmcp import FastMCP导入官方高阶SDK，底层JSON-RPC和传输细节都被封装。
  2. mcp = FastMCP("math-tools")实例化一个名为math-tools的Server，该名称会在初始化握手阶段提供给客户端。
  3. @mcp.tool()装饰器把普通函数注册为MCP工具，自动生成name、description及input_schema。
  4. def add(a: int, b: int) -> int:函数签名与类型注解被SDK解析为JSON Schema，AI据此构造合法的调用参数。
  5. mcp.run(transport="stdio")以stdio方式启动服务，等待父进程（Host）通过标准输入输出发送JSON-RPC消息。

常见误区

误区我一直把MCP和函数调用当成一回事。看到AI能调用工具，就觉得这已经是在用MCP了，不需要再学什么新概念。实际上函数调用只是让模型输出一个JSON参数块，MCP则是完整的标准化连接协议。

正解函数调用解决的是“模型如何决定调哪个函数、参数怎么写”的问题；MCP解决的是“AI应用如何发现、连接、调用、管理远程工具”的全流程问题。MCP包含了初始化握手、工具发现、会话管理、安全审批、错误处理等完整机制。就像USB-C不只是“一个充电协议”，而是覆盖供电、数据传输、协商的整套标准。函数调用只是整个旅程中很小的一段。

为何常见：大多数初学者第一次接触工具调用时，都是从“让大模型输出一段JSON”开始的，容易把最早的接触点误当成全部拼图。

误区我担心一旦引入MCP，现有的工具代码全都要推倒重写，改造成本巨大。所以一直不敢在我的项目里尝试。

正解MCP Server本质是给现有工具套一层标准外壳。内部业务逻辑完全不用动，只需在SDK里注册函数名和参数签名，几十行代码就能完成包装。你的数据库查询函数、文件处理函数可以原样保留，外面包一层MCP的“适配壳”就实现了标准接入。这就像给旧手机装一个USB-C转接头，核心硬件没有变化。

为何常见：人们容易把“协议层标准化”误解为“业务层重写”，没有意识到协议只是边界处的约定。

误区我听说MCP用stdio传输，就觉得它只能跑在本机命令行里，做不了真正的远程服务。结果把很多需要在远程服务器上执行工具的场景都排除在外了。

正解stdio只是MCP支持的传输方式之一，适合本地进程间通信。MCP同样支持Streamable HTTP和SSE传输，Server完全可以部署在远程服务器上，客户端通过URL远程连接。这就像USB-C既可以插在笔记本的本地充电口，也可以插在桌面扩展坞上，扩展坞是远程的还是本地的不影响接口本身的便捷性。

为何常见：初学者往往以最初看到的官方示例（stdio）作为对协议的全貌判断，没有细看规范的完整传输层定义。

误区既然MCP是标准协议，设计它的人肯定已经把安全问题都考虑好了吧？那我就不需要再做什么安全配置了。直接给AI挂上所有工具权限就行。

正解MCP提供了用户授权、作用域限制这些安全机制，但协议不等于免疫。如果你的Server实现了“删除文件”工具，用户在点击“批准”时并没有真正理解潜在后果，风险依然存在。工程实践要求：高危工具加二次确认、按最小权限原则配置允许列表、对工具执行做审计日志。安全带只是保护机制之一，真正让你安全的是驾驶习惯。

为何常见：人类容易把“标准”与“安全”划等号，而忽略协议只是在规范交互行为，并非在替你作安全决策。

面试题

Q1. MCP协议最贴切的生活类比是？

单选题 · easy

  • A.通用USB-C接口← 正确答案
  • B.企业资源计划系统
  • C.数据库查询语言
  • D.图形化开发工具

答案：A。MCP的核心思想是标准化的“即插即用”，与之最贴切的是USB-C统一了充电和数据接口；其他选项是具体系统或语言，不体现“统一标准”的本质。

Q2. MCP Server的主要职责是？

单选题 · easy

  • A.向AI暴露工具和资源← 正确答案
  • B.负责训练神经网络
  • C.渲染前端用户界面
  • D.存储模型权重大小

答案：A。MCP Server将真实工具包装为标准能力，通过列表暴露给AI调用；训练、渲染、存储权重都不属于MCP Server的职责范围。

Q3. 在MCP架构中，Client的角色是？

单选题 · easy

  • A.在主机发起的请求方← 正确答案
  • B.负责存储对话记录
  • C.直接运行大语言模型
  • D.管理网络路由协议

答案：A。Client运行在Host内部，为每个Server维持连接并发送JSON-RPC请求；它不负责存储、模型运行或路由。

Q4. MCP初始化握手的核心目的是？

单选题 · mid

  • A.协商协议版本与能力← 正确答案
  • B.给工具自动分配内存
  • C.对模型权重做剪枝
  • D.建立数据库表结构

答案：A。initialize请求把客户端能力和协议版本发给Server，Server返回自己的能力列表，双方确认一致后才进入正式交互。类似USB-C设备插入后的身份识别。

Q5. tools/call请求必须包含内容是？

单选题 · mid

  • A.工具名称与参数集合← 正确答案
  • B.用户的个人身份信息
  • C.模型的超参数设置
  • D.操作系统的版本号

答案：A。tools/call需要两个核心字段：选择哪个工具（name）以及传给它的参数（arguments），与JSON Schema保持一致。其他选项与工具调用无关。

Q6. MCP中Resources原语表示？

单选题 · mid

  • A.可访问的只读数据← 正确答案
  • B.可修改的系统内核
  • C.可执行的外部脚本
  • D.可压缩的模型权重

答案：A。Resources是只读数据资源，AI按URI定位并读取其内容，不执行任何操作；这使它与可执行的Tools原语形成明确区分。

Q7. 以下哪些属于MCP核心原语？

多选题 · mid

  • A.工具Tools← 正确答案
  • B.资源Resources← 正确答案
  • C.提示Prompts← 正确答案
  • D.组件Components

答案：ABC。MCP四种核心原语为工具、资源、提示、采样。组件（Components）不是协议定义的原语，属于干扰项。

Q8. MCP与普通REST API调用相比，最大区别是？

单选题 · hard

  • A.提供完整协议与生命周期← 正确答案
  • B.传输速度比HTTP更快
  • C.完全取代所有数据库
  • D.只能使用一种编程语言

答案：A。MCP不止是一种调用接口，而是覆盖初始化、发现、调用、返回的完整生命周期标准；它也不限定语言，可以在stdio或HTTP上运行。

Q9. 关于MCP安全机制描述正确的有？

多选题 · hard

  • A.调用工具需用户批准← 正确答案
  • B.可限制服务器的权限← 正确答案
  • C.无需授权自动执行
  • D.所有数据明文传输

答案：AB。MCP要求工具调用前获得用户授权，并支持配置作用域实现最小权限；它并非无授权自动执行，传输环节也需要通过合理配置保障安全。

Q10. 关于MCP演进方向描述正确的有？

多选题 · extreme

  • A.支持HTTP远程连接← 正确答案
  • B.本地stdio更低延迟← 正确答案
  • C.完全取代所有API
  • D.OAuth认证正在推进← 正确答案

答案：ABD。MCP支持Streamable HTTP实现远程连接，本地stdio适合低延迟场景，社区正在推进OAuth认证。“完全取代所有API”是一厢情愿的夸大，MCP标准化的是工具接入方式，不排斥其他API的存在。