MCP 火了之后，AI 编程工具的插件支持差在哪
本文要点
- MCP 支持度不是一个「有没有」的问题，它同时决定三件事：你的插件生态有多大、每次请求要为插件付多少上下文、以及哪些目录从此挡不住 Agent。只比「支持不支持」，等于什么都没比。
- Claude Code 官方文档写得很明确：「MCP tool definitions are deferred by default, so only tool names and server instructions enter context until Claude uses a specific tool.」——挂了 20 个 MCP 服务器，不等于每次请求都吃掉 20 份完整工具定义
- MCP 规范当前的协议版本是 2026-07-28，标准传输绑定只有两种：stdio 与 Streamable HTTP。SSE 在最新规范里已不是标准传输，而 Claude Code 官方直接写「The SSE (Server-Sent Events) transport is deprecated.」
- Cursor 官方文档承认了一个安全边界：「The terminal and MCP server tools used by Agent cannot block access to code governed by
.cursorignore」——忽略文件挡的是索引与 @ 引用，不是终端和 MCP - 团队级插件分发是 Cursor 明确写进档位表的能力：Teams 给 1 个 team marketplace，Enterprise 给 unlimited，而且只有 Enterprise 能按身份组做分发与访问门控
MCP 火了以后，AI 编程工具的对比表里多了一列「是否支持 MCP」。这一列几乎每家都打勾——因为 MCP 是一个开放协议，接进来不难。于是它变成了一个没有信息量的对比维度。
真正拉开差距的是勾之后的三个问题。第一，生态：协议是同一个，但插件从哪来、谁能分发、团队怎么统一管理，各家做法差别很大。第二，成本：工具能力可以外挂之后，外挂的东西要不要占上下文？挂得越多是不是越贵？第三，安全：你原本用忽略文件挡住的敏感目录，在 Agent 能调终端和 MCP 之后还挡得住吗？
这篇把 MCP 规范本身（modelcontextprotocol.io）、Claude Code、Cursor、GitHub Copilot、Devin 四家的官方文档对齐，重点讲透一条最容易被忽略的官方事实——工具定义默认延迟加载。这条同时是成本机制和架构选择。数据于 2026 年 9 月 24 日重新核对各厂商官方文档。
本文方法：官方公开数据交叉核对，未做本地实测。所有数字均标注来源，核对日期见文末。
一、先把 MCP 规范本身讲清楚
讨论「支持度」之前，得先知道被支持的那个东西到底是什么。MCP 官方介绍页给的定义是：「MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.」官方还用一个类比来解释它：「Think of MCP like a USB-C port for AI applications.」
这句话解释了为什么「支持 MCP」这件事本身不值钱：它被设计成一个通用接口，接进来是标准动作。真正有差别的是接口之外的东西。先看规范层面的几个硬事实。
| 规范要素 | 官方表述 |
|---|---|
| 当前协议版本 | 2026-07-28，官方标注为 Current；版本号采用 YYYY-MM-DD，表示「最后一次向后不兼容改动的日期」 |
| 标准传输绑定 | 两种：stdio（客户端拉起的子进程，按行分隔的消息）与 Streamable HTTP（每条消息是一次 HTTP POST，回复为 JSON 或请求级 SSE 流） |
| 自定义传输 | 允许，但「MUST preserve the JSON-RPC message format, the message patterns, and the per-request metadata model」 |
| 语义一致性 | 「Protocol semantics are identical on every transport.」传输只决定消息怎么封装与投递，不决定消息的含义 |
| 服务端提供的能力 | Resources（上下文与数据）、Prompts（模板化消息与工作流）、Tools（供模型执行的函数） |
| 官方扩展 | Tasks（长任务异步执行）、Skills over MCP、MCP Apps（对话内渲染图表、表单等交互 UI），均为可选、需双方协商 |
| 旧版兼容 | 2025-11-25 及更早的版本使用 initialize 握手与会话模型，最新规范改用「每条请求自带协议版本」的协商方式 |
这张表里最容易被忽略的是第一行和第二行的组合。协议版本号是日期，不是语义化版本号；官方明确说「The protocol version will not be incremented when the protocol is updated, as long as the changes maintain backwards compatibility.」也就是说，看到两个工具都写「支持 MCP」，你无法从版本号上判断它们实现的是哪一代行为——只有「不兼容改动」才会推新日期。要判断实际行为，只能去读每个工具自己的文档。
传输这一行更具体。最新规范里标准绑定只有 stdio 和 Streamable HTTP，SSE 已经不在其中；而在客户端一侧，Claude Code 官方对 SSE 的表述是「The SSE (Server-Sent Events) transport is deprecated. Use HTTP servers instead, where available.」同一个协议名，客户端支持的是「老的那一代」，规范已经换了一代——这就是为什么「都支持 MCP」这句话需要拆开看。
二、最关键的一条：工具定义默认延迟加载
接下来是这一篇的技术核心，也是「MCP 支持度」里最值钱的一条官方事实。Claude Code 的成本文档里写着一句很短的说明：
「MCP tool definitions are deferred by default, so only tool names and server instructions enter context until Claude uses a specific tool.」
翻译成一句人话：你挂上去的 MCP 服务器，默认只把「工具的名字」和「服务器的说明」放进上下文；完整的工具定义要等 Claude 真的去用某个工具时才会被读进来。
这句话为什么重要，要连着另一段官方说明一起看。Claude Code 的上下文文档里列了「你还没输入任何内容之前」就已经进上下文的东西：「CLAUDE.md, auto memory, MCP tool names, and skill descriptions all load into context.」注意措辞——进上下文的是 MCP tool names，不是 MCP tool definitions。两份文档互相印证了同一件事。
于是这里出现了对比文章里最常见的错误：把「挂了几个 MCP 服务器」当成「每次请求的上下文开销」。挂 20 个服务器，开销并不是 20 份完整工具定义，而是 20 组工具名加服务器说明。官方的另一条建议也从侧面确认了这一点：「Prefer CLI tools when available」——官方说 gh、aws、gcloud、sentry-cli 这类 CLI 比 MCP 服务器更省上下文，理由是「they don’t add any per-tool listing」。反过来说，MCP 的固定开销正是那份 per-tool listing——也就是工具清单，而这份清单在延迟加载下只包含名字。
这张图要连着看两行：在同样的挂载数量下，两种注入方式的上下文占用差了约 25 倍。按 200K 窗口算，全量注入的 40,000 token 会先占掉约五分之一，然后你才开始问问题；而延迟加载的那 1,600 token 基本可以忽略。这就是「按需注入」在工具层的一个具体实现，也是为什么这件事同时是架构问题和成本问题。
需要说明的是，延迟加载不是免费的。它的代价是第一次调用某个工具时多一次读取和一次往返，以及官方在 MCP 文档里提到的一个细节：如果你需要的工具所在的服务器还在后台连接中，「Claude waits for that server before continuing」。官方为此提供了两种等待机制——「With tool search, the default: the wait happens inside the ToolSearch call.」没有 tool search 时则改用 WaitForMcpServers 工具。另外，一个之前用过的远程服务器可能显示 cached 状态（例如「cached 2h ago · connects on first use · 5 tools」），此时工具列表来自上一次会话的发现缓存，「The tools are available from your first message」。
三、四家的 MCP 挂载方式差在哪
延迟加载是 Claude Code 的实现。其他家怎么做、有没有对应的机制，官方文档的披露程度差别很大。下面这张表只写官方文档里真正写出来的内容，没写的一律标注为未披露。
| 工具 | 挂载与作用域 | 官方声明的传输 | 团队分发 |
|---|---|---|---|
| Claude Code | claude mcp add，三种作用域：local（默认，存 ~/.claude.json）、project（.mcp.json，随版本库共享）、user（跨项目）；优先级 local > project > user > 插件提供的服务器 > claude.ai 连接器 |
HTTP（官方推荐）、SSE（官方称已弃用）、stdio、WebSocket；type 字段接受 streamable-http 作为 http 的别名 |
project 作用域通过 .mcp.json 共享；官方提示交互式会话中会先要求批准 |
| Cursor | 项目级 .cursor/mcp.json、全局 ~/.cursor/mcp.json；也支持从 Customize 页面或 Marketplace 一键安装，以及用 vscode.cursor.mcp.registerServer() 动态注册 |
官方对照表列出 stdio、SSE、Streamable HTTP 三种；stdio 为本地单用户、手动认证，远程两种为多用户、OAuth |
Teams 给 1 个 team marketplace，Enterprise 给 unlimited；仅 Enterprise 支持按 SCIM 身份组分发与访问门控 |
| GitHub Copilot | 官方定价页把「Integrates with MCP servers」列为 Agent mode 的能力，个人四档（Free/Pro/Pro+/Max）均已包含；云端 Agent 下的 MCP 则从 Pro 档起 | 官方定价页未逐项列出传输方式 | 组织/企业档把 MCP 列在 Agents 与 Customization 两项能力下；官方说明这些设置「depend on the Copilot plan and the client」 |
| Devin | 官方提供 Devin MCP Server（https://mcp.devin.ai/），需 API key；自定义 MCP 需 Manage MCP Servers 权限，普通成员只能用「Suggest MCP Integration」申请；作用域分 personal / organization / enterprise |
仅 Streamable HTTP（/mcp）；官方明确「The legacy SSE (/sse) endpoint has been deprecated」 |
有插件市场（Customize → MCPs 的 Browse marketplace），旧版 MCP marketplace 仍在；官方称 MCP 让 Devin 可用「hundreds of external tools and data sources」，但未给精确数量 |
这张表能读出三个不在「支持/不支持」这一列里的差别。
第一，作用域的粒度不同，团队协作的成本就不同。Claude Code 把 .mcp.json 放进项目根目录，团队共享是「提交到版本库」这一个动作；Cursor 用项目级 .cursor/mcp.json 做同样的事，同时额外提供全局配置和一键安装。Devin 则把权限写进了角色：加自定义 MCP 服务器需要 Manage MCP Servers 权限，没有权限的成员只能提交申请。这三种做法的差别不是功能多少，而是「谁来定团队用哪些插件」这个决定被放在了哪一层。
第二，SSE 正在被集体淘汰，但淘汰进度不一致。MCP 最新规范的标准绑定里已经没有 SSE；Claude Code 官方称它 deprecated；Devin 官方称旧 SSE 端点已弃用，只支持 Streamable HTTP；Cursor 的官方对照表里仍然把 SSE 和 Streamable HTTP 并列为两种远程方式。如果你在选 MCP 服务器，按 Streamable HTTP 挑是最安全的；按 SSE 挑，可能刚上线就落在被弃用的一侧。
第三，团队级分发是 Cursor 明确写进档位表的能力，其他三家没有给出同样的量化。Cursor 的档位对照表里，「Team marketplaces」这一行写得非常具体：Teams 是 1 个，Enterprise 是 unlimited；「Community plugin import」Teams 默认开、Enterprise 默认关；「Marketplace edits」Teams 是「All teams can edit」、Enterprise 是「Only admin edits」。这三条合起来说明一件事——Cursor 把「插件从哪里来、谁能改、谁能看」当成了档位差异的一部分，而不是一个功能开关。Claude Code 这一侧的对应机制是 project 作用域加批准提示，Devin 是权限加申请流程。三种思路，取舍不同。
四、MCP 带来的安全边界问题
插件能力可以外挂之后，一个原本很干净的假设失效了：「我把敏感目录写进忽略文件，模型就看不到」。
坑一：忽略文件挡得住索引，挡不住终端和 MCP
Cursor 官方忽略文件文档写得很清楚。.cursorignore 会挡住两类访问：Agent、Tab、Inline Edit 能看到的代码，以及通过 @ 引用能看到的代码。紧接着是那条关键句：「The terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore」。
也就是说，Agent 一旦能跑终端命令、能调 MCP 工具，忽略文件对这两条路径就不再生效。一条 cat ~/.aws/credentials，或者一个能读本地文件系统的 MCP 服务器，都可以绕过你在 .cursorignore 里写下的规则。
官方在「为什么需要忽略文件」一节里也留了余地：即使 Cursor 会挡住被忽略的文件，「complete protection isn’t guaranteed due to LLM unpredictability」。真正要收紧，靠的是终端沙箱、网络控制与 MCP 允许列表这类机制，而不是一个忽略文件。
这条事实把「MCP 支持度」的第三个维度推到了台面上：支持 MCP 的同时，有没有配套的企业管控。Cursor 在这方面写得比较细，它的 MCP 文档里列了企业管理员控制：MCP Allowlist——命令条目审批本地 stdio 服务器，URL 条目审批远程 HTTP/SSE 服务器，工具允许列表限制哪些工具可以自动运行；网络控制——远程 MCP URL 受配置的 URL 模式限制，本地命令型服务器按服务器设置网络模式（允许全部、允许列表、拒绝全部、无沙箱）；以及 User MCP extensions 控制，管理员可以用 denylist 阻止匹配的网络目标。Devin 那一侧的对应物是 Manage MCP Servers 权限与组织级共享 MCP 的连接权限。这两家的共同点是：把 MCP 从「个人偏好」提到了「管理员可管的对象」。
坑二：安装一个 MCP 插件，不等于授权它访问你的账号
Devin 的 MCP 文档把这两步拆开讲：「Plugin installation alone does not authorize access to the external service.」紧接着一句是「Installation and authorization are separate steps.」。官方还补了一个容易被忽略的分支——如果某个 MCP 用的是 Personal OAuth 访问方式，「each member must connect their own account」。
这解释了团队部署 MCP 时最常见的一种困惑：管理员把服务器配好了，所有人都「装上了」，但只有一部分人能用。装上和授权是两件事，共享的组织级 MCP 和个人级 MCP 也是两件事。
Cursor 的 MCP 文档也给了同方向的安装建议：验证来源、审核权限、用最小权限的受限 API key、对关键集成审查服务器源码，并提醒「MCP servers can access external services and execute code on your behalf」。
坑三：MCP 的「输出上限」和你以为的「上下文」不是一回事
Claude Code 官方文档写明：「Claude Code displays a warning when MCP tool output exceeds 10,000 tokens and limits output to 25,000 tokens by default.」想放宽，要设 MAX_MCP_OUTPUT_TOKENS 环境变量（例如 MAX_MCP_OUTPUT_TOKENS=50000），而且「the warning threshold is fixed」——告警线是固定的，只有上限能调。
注意这里的措辞是 output，不是「工具定义」。所以 Claude Code 其实有两条独立的闸门：一条管工具定义怎么进上下文（默认延迟加载），一条管工具输出能有多长（默认 25,000 token）。把这两条混在一起，就会得出错误的容量结论——以为挂了很多服务器很省，却忘了某次查询一下拉回来几万 token 的结果。
MCP 规范本身也承认这个风险面：「Tools represent arbitrary code execution and must be treated with appropriate caution.」规范还特别提醒，工具的行为描述（annotations）应当被视为不可信，除非它来自受信任的服务器——「unless obtained from a trusted server」。
五、按场景怎么选
- 个人开发者，只是想把几个工具接进来：四家都够用，重点看传输方式。优先挑支持 Streamable HTTP 的 MCP 服务器——Claude Code 和 Devin 都已经把 SSE 标为弃用，MCP 最新规范的标准绑定里也没有 SSE。
- 关心上下文成本、打算挂很多服务器：先确认目标工具是否有「延迟加载」这类按需注入机制。Claude Code 官方明确默认延迟加载，只有工具名和服务器指令进上下文；如果某个工具没有同类机制，挂载数量会直接变成每次请求的固定开销。这条差别比「支持不支持 MCP」重要得多。
- 团队要统一管理插件：Cursor 把这件事做成了档位差异——Teams 1 个 team marketplace、Enterprise 不限量，且只有 Enterprise 能按 SCIM 身份组做分发与访问门控。如果团队超过一个、或者需要按身份控制谁能看到哪个市场，这个差异会先于价格生效。
- 代码里有不能外泄的目录：不要只靠
.cursorignore。官方明确终端与 MCP 工具不受它约束。要收紧就去看终端沙箱、网络控制、MCP 允许列表这些机制——Cursor 的 MCP Allowlist 与网络模式、Devin 的 Manage MCP Servers 权限都是官方写出来的入口。 - 在评估一个 MCP 服务器值不值得装：先分清它是共享的组织级服务器，还是需要每人各自授权的个人级服务器。Devin 官方把这两类写成了不同的连接路径，后者意味着「管理员配好了」不等于「团队能用了」。
- 准备接一个长查询型工具（日志、代码库问答、数据查询）：盯住输出上限。Claude Code 默认在输出超过 10,000 token 时告警、把输出限制在 25,000 token，且告警线不可调。这类工具的价值往往就在长输出，所以要么调大
MAX_MCP_OUTPUT_TOKENS，要么换成分页式的 CLI 工具。
回到方法上。这一篇和本站前几篇做的是同一件事——把订阅价格拉平、把上下文窗口拉平。这一篇拉平的是「插件支持度」：先确认它到底把什么放进了上下文，再确认谁能管、谁能装，最后确认挡不挡得住不该看的东西。「支持 MCP」这四个字里，只有最后这三层是有信息量的。
数据来源与核实说明
文中 MCP 规范版本与各工具 MCP 支持情况于 2026 年 9 月 24 日复核更新，来源为各厂商官方文档。本文未做本地实测，所有数字来自公开官方来源。发现错误欢迎联系我们。
- 正文 SVG 中的 40,000 与 1,600 token 是本文的折算，不是官方数字。假设条件是：20 个 MCP 服务器、每台暴露 10 个工具、完整工具定义按 200 token 计、工具名按 8 token 计。官方只声明了「工具定义默认延迟加载」这一机制，未公布任何工具定义的具体 token 数。不同服务器暴露的工具数量与定义长度差异极大，实际值会明显偏离本文假设。
- 「按需注入」的直接依据是官方原文，不是本文的推断。Claude Code 成本文档原文：「MCP tool definitions are deferred by default, so only tool names and server instructions enter context until Claude uses a specific tool.」上下文文档的对应表述是「MCP tool names, and skill descriptions all load into context」。
- 其他三家是否也有「工具定义延迟加载」的同类机制，官方文档未声明。本文不做推测。Cursor、GitHub Copilot、Devin 的公开文档中，本文只找到挂载方式、传输方式与管控能力的说明。
- GitHub Copilot 与 Devin 的 MCP 传输方式披露程度不同。Copilot 官方定价页把「Integrates with MCP servers」列为能力项，但未逐项列出传输方式；Devin 官方文档明确只支持 Streamable HTTP，并声明旧 SSE 端点已弃用。Devin 官方称 MCP 让其可用「hundreds of external tools and data sources」，未给出精确数量，本文不引用具体数字。
MCP 规范与各厂商文档更新频繁，协议版本与支持情况可能随时调整，请以官网文档为准。发现数据错误欢迎联系我们。
- MCP 官方介绍（定义、USB-C 类比、生态支持列表）：modelcontextprotocol.io — What is the Model Context Protocol
- MCP 规范当前版本（协议要点、能力、安全原则、扩展）：modelcontextprotocol.io — Specification 2026-07-28
- MCP 传输绑定（stdio 与 Streamable HTTP、自定义传输）：modelcontextprotocol.io — Transports
- MCP 版本策略（版本号格式、Current 状态、协商方式）：modelcontextprotocol.io — Versioning
- Claude Code 成本文档（工具定义延迟加载、CLI 替代建议、MCP 输出上限）：code.claude.com — Manage costs effectively
- Claude Code MCP 文档（添加方式、作用域、传输方式、发现缓存）：code.claude.com — Connect Claude Code to tools via MCP
- Claude Code 上下文文档（启动前载入的内容）：code.claude.com — Explore the context window
- Cursor MCP 文档（配置文件位置、传输方式、安全注意事项、企业管控）：cursor.com/docs/mcp
- Cursor 忽略文件文档（终端与 MCP 不受 .cursorignore 约束）：cursor.com — Ignore file
- Cursor 企业与团队档位对照（team marketplace 数量、审计日志等）：cursor.com/docs/enterprise
- GitHub Copilot 计划对照（Integrates with MCP servers 的档位分布）：github.com — Copilot plans & pricing
- Devin MCP Server 文档（Streamable HTTP、认证、可用工具、客户端字段差异）：docs.devin.ai — Devin MCP
- Devin MCP 市场文档（插件市场、权限、安装与授权分离）：docs.devin.ai — MCP Marketplace