基于权威评测数据,全面解析Codex、Cursor、Claude Code、Grok与OpenCode在MCP协议核心功能上的实际表现,揭示协议成熟度与生态差距。
引言:MCP协议距离"好用"还有多远\n\n模型上下文协议(MCP)在人工智能开发工具领域已经走过了近两年的发展历程,从2024年11月正式发布,到2026年7月推出无状态核心规范,这项旨在统一大语言模型与外部工具交互的技术始终面临着落地碎片化的困境。根据权威评测网站"ismcpgoodyet.com"的最新数据,目前市场上五大主流编码代理 - - Codex、Cursor、Claude Code、Grok与OpenCode - - 对MCP核心功能的支持度仅达到56%,这一数字直观地揭示了协议生态的成熟度仍存在显著缺口。\n\n对于开发者与企业技术决策者而言,理解不同工具对MCP协议各项扩展功能的实际支持情况,是选择技术栈、规划集成方案的关键依据。本文将基于该评测站点的详细功能矩阵,从无状态规范、任务系统、代码模式、工具描述延迟加载、OAuth认证等关键维度,深入剖析当前MCP生态的真实状态。\n\n核心发现:评测总览与协议成熟度现状\n\n"ismcpgoodyet.com"的评分体系覆盖了MCP协议的十余项关键功能扩展。截至最新评测周期,五大主流编码代理的综合得分仅为56%,这意味着协议层面定义的功能特性中,近半数尚未在任何主流客户端获得完整实现。
这一现状与MCP协议本身的高速迭代形成了鲜明对比 - - 从2025年3月的远程MCP与Streamable HTTP规范,到2026年7月的无状态核心规范,协议本身已经历多次重大修订,而客户端实现却普遍滞后。\n\n值得注意的是,评测中频繁出现的"Partial"评级反映出行业普遍存在的"部分实现"现象:功能入口已经存在,但要么需要手动开启实验性开关,要么仅在特定部署环境下生效,要么缺少完整的文档说明。这种碎片化支持状态给开发者带来了显著的集成摩擦。\n\n无状态规范支持:协议演进遭遇实现滞后\n\n2026年7月28日发布的协议修订引入了无状态核心规范,移除了传统MCP通信中的initialize握手环节与session id机制,每个请求独立携带版本号与能力声明。这一架构调整旨在简化协议复杂度、提升横向扩展能力,并为任务系统与扩展框架腾出空间。\n\n在五大编码代理中,Codex提供了该规范的opt-in支持,通过mcp_2026_07_28协议版本切换实现,但默认配置仍停留在2025-06-18版本;Claude Code的部分部署环境(Anthropic托管的CLI、VS Code扩展与SDK)已将v2运行时设为默认,但Bedrock、Vertex AI、Foundry等企业级托管平台仍停留在v1实现。
Grok Build则采取保守策略,将线协议固定在2025-11-25版本,避免rmcp升级带来的隐式变更;OpenCode的SDK v2客户端迁移甚至已经回退至带initialize握手的实现。\n\n这一现象反映出协议演进过程中典型的"先规范、后实现"困境:核心规范的发布往往领先于主流客户端的稳定支持,迫使企业在采用新特性时面临兼容性风险。\n\n任务系统(Tasks):长时任务的协议级缺失\n\n任务系统是MCP协议中用于处理长时间运行任务的关键扩展,允许服务器返回持久化任务标识符,客户端可通过轮询、提供输入与断线恢复等机制跟踪任务状态。这对于代码生成、数据处理、自动化部署等耗时操作至关重要。\n\n评测中所有五大客户端均未提供该功能的完整支持。Codex的MCP文档仅覆盖stdio、Streamable HTTP、工具、OAuth与审批模式,未涉及Tasks扩展;Cursor的支持矩阵明确列出工具、提示、资源、根目录、请求与Apps六项能力,任务系统不在其中;Claude Code与Grok的情况类似,虽然各自拥有内部的后台任务机制,但均未实现MCP协议定义的标准任务扩展。
OpenCode的客户端能力声明中甚至将该功能注释掉。\n\n更值得关注的是,即便是各客户端自带的"后台任务"或"子代理"功能,也与MCP任务扩展在协议层面完全独立,无法为开发者提供统一的跨工具任务编排能力。\n\n代码模式(Code Mode):沙箱执行理念的落地差异\n\n代码模式代表了MCP生态中一种重要的架构思路:模型编写代码来调用MCP工具,中间结果保留在沙箱环境中而非进入上下文窗口。这一模式能够显著降低token消耗,提升复杂工具调用的效率。Anthropic与Cloudflare分别在2025年11月与更早时期提出了这一理念。\n\n五大客户端对此的支持呈现明显分化。
Codex提供了code_mode表面,可与直接调用与延迟调用并列使用,但该功能默认关闭且标记为"开发中";Claude Code明确表示不提供原生的代码模式执行能力,仅通过连接MCP服务器并调用工具的方式工作,其工具搜索机制在大目录场景下发挥作用;OpenCode将该功能置于实验性开关OPENCODE_EXPERIMENTAL_CODE_MODE之后,MCP工具作为execute的子工具存在,默认路径仍采用模式加载模式。\n\nGrok则完全不支持该模式,MCP工具通过search_tool与use_tool进行调用,不涉及模型编写代码直接调用MCP的场景。Cursor同样未提供官方支持的代码模式,其动态上下文发现机制仍以模式加载为核心。\n\n工具描述延迟加载:降低上下文窗口压力的关键优化\n\n工具描述延迟加载是当前MCP实现中较为成熟的功能扩展,其核心思想是避免模型在初始请求时即获取所有MCP工具的完整JSON模式定义,而是先获取名称或简短索引,待实际需要时再加载完整模式。这一机制对于工具目录庞大的场景(如GitHub MCP、数据库连接器集合)尤为关键。\n\n在五大客户端中,该功能的支持度相对较高。
Codex自2026年6月22日起默认启用,MCP工具置于tool_search之后,首次请求不再包含完整工具列表;Cursor在第一轮对话中仅传递工具名称,完整描述以文件形式存放于各服务器目录,由代理按需读取;Claude Code的工具搜索默认开启,定义被推迟加载,代理接收摘要并按需加载最多五个匹配项;Grok的search_tool支持按名称与描述查找MCP工具,目录信息不会全量注入上下文。\n\nOpenCode是其中唯一仍以完整模式注入为默认路径的客户端,其官方文档明确警告GitHub MCP可能撑爆上下文窗口。虽然其实验性代码模式提供了基于token预算的目录管理,但仍以模式注入与缺失签名搜索为核心机制,而非完整的延迟加载架构。\n\n分页协议支持:大型目录的稳健访问能力\n\ntools/list分页机制允许服务器在工具目录过大时通过nextCursor字段返回分页结果,客户端需持续获取后续页以避免目录截断,对于企业级工具集成场景至关重要。\n\n评测显示,Claude Code、Grok与OpenCode均完整实现了该功能,支持对工具、提示、资源与模板列表的分页获取,并具备循环检测与页数上限保护(OpenCode设置了1000页上限)。Cursor完全不支持分页,单次tools/list请求后,工具列表的剩余部分将永远不会出现;Codex在opt-in的2026-07-28模式下支持分页,但其默认的2025-06-18模式仍忽略游标字段,存在已知问题追踪。
\n\n这一功能的不均衡支持意味着,开发者在集成大型MCP工具集时,可能面临目录截断的风险,特别是在使用Cursor或默认配置的Codex时。\n\nMCP Apps扩展:交互式UI渲染能力\n\nMCP Apps扩展允许工具返回交互式UI组件在客户端渲染,为开发者提供超越纯文本结果的能力。该扩展自2026年1月发布以来,已成为MCP生态中重要的体验增强方向。\n\nCursor是该功能支持最完整的客户端,其官方支持矩阵明确列出Apps能力,并提供对应的扩展矩阵标识。Codex通过app-server实现了该扩展,支持text/html;profile=mcp-app与mcpAppResourceUri,但enable_mcp_apps默认关闭;Grok能够识别MCP应用工具并声明相应能力,但未提供文档化的TUI渲染器。\n\nClaude Code仅在移动端、Web端、桌面端与Cowork场景下渲染Apps,CLI与VS Code集成场景仅显示文本结果;OpenCode则完全不支持,核心代码中无Apps宿主实现,相关请求仍处于开放状态。
\n\nOAuth认证集成:用户体验的标准化进程\n\nMCP协议的OAuth认证机制旨在为远程服务器提供标准化的认证流程,避免开发者手动粘贴令牌的繁琐操作。该领域的支持度相对统一,五大客户端均提供了不同程度的集成。\n\nCodex通过codex mcp login命令启动浏览器流程,远程服务器默认采用OAuth认证,注册流程优先尝试CIMD,回退至动态客户端注册(DCR)。Cursor的Marketplace提供"Add to Cursor"入口触发OAuth流程,CLI模式下通过agent mcp login命令启动。Claude Code支持/mcp命令与claude mcp登录命令,发现CIMD、DCR与预配置客户端凭据,Agent SDK不打开浏览器,需手动传入Authorization头部。\n\nGrok为远程HTTP连接触发浏览器流程,令牌存储于~/.grok/mcp_credentials.json,TUI界面提供/mcps i命令进行认证。
OpenCode对远程服务器自动启用OAuth,支持服务器DCR,提供opencode mcp auth、list、logout等管理命令。\n\n尽管各客户端在具体实现上有所差异,但OAuth认证已成为MCP生态中少数实现度较高的功能领域,反映出社区对标准化认证流程的重视。\n\n审批策略:细粒度权限控制的多样化实现\n\n审批策略是保障MCP工具安全调用的关键机制,各客户端均提供了基于允许列表、分类器或注释感知的自动运行策略。\n\nCodex提供auto、prompt、writes、approve四种审批模式,writes模式在工具非只读时触发提示,readOnlyHint可跳过审批;Cursor采用自动审查分类器配合mcpAllowlist,MCP工具遵循运行模式,CLI提供approvalMode、/auto-review、--approve-mcps等选项;Claude Code默认对未匹配的MCP调用进行提示,allowedTools提供预审批机制。\n\nGrok提供Ask(默认)、Auto分类器与Always-approve三级机制,配合MCPTool允许/拒绝规则;OpenCode支持allow、ask、deny与--auto模式,MCP工具使用与前缀ID相同的权限键。\n\n值得注意的是,OpenCode明确表示其权限策略不具备注释感知能力,这一限制在特定企业场景下可能带来安全隐患。
\n\n时间线回顾:MCP生态的发展脉络\n\n回顾MCP协议的发展历程,可以清晰看到一条从协议标准化到生态扩展的演进路径。2024年11月,MCP正式发布,开启了统一LLM工具交互协议的探索;2025年3月,远程MCP、Streamable HTTP与OAuth规范发布,奠定了现代MCP通信的基础架构;2025年11月,Anthropic提出通过代码执行方式使用MCP的理念,为降低上下文消耗提供了新思路。\n\n2026年是MCP生态快速发展的一年。1月,MCP Apps扩展正式发布;4月,Skills Over MCP工作组成立,启动SEP-2640草案起草;5月,Chrome I/O大会展示WebMCP能力,页面可在标签页生命周期内注册工具;7月,无状态核心规范发布,移除了initialize握手与session id,将请求与能力声明解耦;8月,MCP路线图公布,涵盖代理消息、HTTP-over-stdio、DPoP、渐进式发现等方向。\n\n这一时间线揭示了MCP协议的雄心:从协议规范、能力扩展到生态整合,试图构建一个完整的代理工具交互基础设施。然而,规范的快速迭代与客户端实现的滞后之间的张力,仍然是当前生态面临的核心挑战。
\n\n结论:协议成熟度与开发者期待的现实落差\n\n综合来看,MCP协议距离"好用"的状态仍有相当距离。56%的综合得分背后,是任务系统、代码模式、技能集成等关键能力在主流客户端中的普遍缺失,也是协议规范快速演进与生态实现之间持续存在的鸿沟。\n\n对于开发者而言,在选择编码代理工具时,需要仔细权衡各客户端对MCP各项功能的具体支持程度:若企业场景重度依赖大型工具目录,Claude Code、Grok与OpenCode是更稳健的选择;若重视交互式UI体验,Cursor与Grok提供了相对完善的MCP Apps支持;若关注OAuth认证的自动化程度,五大客户端均能满足基本需求,但具体实现细节差异显著。\n\n展望未来,随着2026年8月MCP路线图中各项扩展的逐步落地 - - 代理消息、HTTP-over-stdio、DPoP、渐进式发现 - - 客户端实现能否跟上协议演进的节奏,将是决定MCP生态能否走向成熟的关键变量。在此之前,开发者在采用MCP相关能力时,仍需保持对各客户端具体实现的精细评估,避免因功能缺失或行为差异导致集成风险。 。
