曾经，给 Agent 增加一种能力，最自然的做法是寻找一个 MCP Server：访问代码仓库、查询数据库、操作服务器，似乎任何工具都值得再封装一次。

但当 Agent 已经能够阅读 API 文档、探索 CLI、编写脚本时，这个问题开始发生变化：现有接口已经能够完成任务，为什么还需要再维护一层 MCP？

Maharshi Patel 在《Why MCP Was Always a Bad Idea》中提出了一个直接的主张：删除大多数 MCP Server，让 Agent 回到 HTTP API 和 CLI。原文

对已经部署 MCP 的团队来说，更有价值的问题是：哪些可以迁移，迁移到哪里，哪些仍然值得保留？

一、MCP为何诞生？

MCP 诞生于一个真实的工程问题：模型需要连接外部世界，但不同应用的连接方式并不统一。

假设有多个 AI 应用，每个都要接入代码仓库、文档系统、数据库和内部业务系统。没有共同协议时，各个应用都需要自行实现连接、工具描述和调用适配。同一套服务能力，被不同团队反复对接。

Anthropic 在 2024 年 11 月推出 MCP，希望通过统一协议连接 AI 应用与外部工具、数据源。服务提供方实现 MCP Server，支持协议的客户端即可接入，减少重复集成。MCP 发布说明

各自对接与统一 MCP 协议的集成方式对比

这也适应了当时的模型使用方式：开发者预先定义工具名称、参数和返回值，模型选择工具并填写参数，客户端负责执行。

例如，模型不必理解工单系统的鉴权、分页和请求格式，只需调用一个“查询工单”工具。

因此，MCP 当时的价值很明确：它降低了接入成本，也让模型获得了容易理解的操作入口。对没有终端和代码执行环境的聊天应用，这种入口尤其重要。

二、MCP为何落幕？

推动变化的，是 Agent 开始具备直接使用软件接口的能力。

面对一个陌生服务，具备终端和网络权限的 Agent 可以阅读文档、查看 --help、调用 SDK，再用脚本处理分页、过滤、聚合和重试。许多原本需要 MCP 封装的工作，现在可以通过既有接口完成。

如果某个 MCP Server 只是把一次 HTTP 请求换成一次工具调用，它提供的额外价值就越来越有限。

与此同时，规模化使用 MCP 的成本开始显现。

首先是上下文开销。大量工具的名称、描述和参数定义，如果在会话开始时全部加载，会占用模型的上下文。连续调用工具时，中间结果也可能反复进入对话，增加延迟和费用。Anthropic 已经专门讨论过这两类问题，并提出通过代码执行、按需发现工具和提前过滤结果改善效率。Anthropic：Code execution with MCP

其次是维护成本。上游 API 更新之后，MCP 封装需要跟进；客户端还要处理进程启动、依赖版本、连接状态和错误映射。接口没有减少，维护对象却增加了。

最后是组合效率。查询一批记录、提取标识、逐项请求详情、计算统计值，本来就是适合程序处理的工作。让模型逐轮选择工具、读取结果、决定下一步，往往比直接执行一段脚本更绕。

逐轮调用工具与脚本集中执行的流程对比

Cloudflare 的 Code Mode 也采用了让模型编写代码、在执行环境中组合工具调用的方式。代码执行可以与 MCP 配合：脚本承接多步编排和数据处理，MCP 继续提供工具连接。二者属于不同层面，不能仅凭代码执行的出现，就断言 MCP 已失去独立价值。Cloudflare：Code Mode

所以，“落幕”首先表现为一种默认选择的变化：面对新需求，团队会优先检查 API、SDK 和 CLI，再判断是否值得维护专门的 MCP 接口。

三、MCP如何迁移？

迁移的起点应该是一份能力清单。

记录每个 MCP 的实际用途、调用频率、替代接口，以及它是否承担鉴权、权限限制、结果脱敏等职责。不能只看工具名称相似，就认为替代已经完成。

可以按下面的方式分流：

存量 MCP 的主要职责建议迁移方向
简单封装已有命令行工具直接使用 CLI，补充任务说明和调用示例
简单封装 HTTP API使用官方 SDK 或小型脚本
提供文档检索与阅读使用文档入口、搜索接口和按需加载
串联多个业务操作提炼为可复用脚本或工作流
隔离凭据、限制权限保留受控服务入口
必须兼容多个 MCP 客户端保留 MCP 适配层，复用内部业务实现

依据安全边界、替代接口和客户端兼容需求选择迁移路径

第一步：从低风险、只读能力开始。

查询状态、读取文档、统计记录，适合成为第一批迁移对象。先确认替代接口覆盖实际需求，再处理发布、删除、变更权限等写操作。

第二步：把业务逻辑从协议中拆出来。

如果已经开发了自己的 MCP Server，可以把分页、重试、格式转换等逻辑提取到独立模块。MCP 和 CLI 都调用这个模块，迁移期间并行保留两个入口。

这样既保留了已有投入，也方便逐步切换调用方。

第三步：为 Agent 提供简短的使用说明。

迁移后，Agent 仍然需要知道接口在哪里、如何选择环境、哪些字段有用，以及错误如何处理。

这些知识可以写进任务说明或 Skill，搭配经过验证的脚本。例如：

查询项目状态时使用指定脚本；默认只读；优先返回状态、负责人和更新时间；需要详情时再按标识查询。

Skill 负责指导使用方式，权限限制则需要由执行环境和服务端真正落实。

第四步：让程序处理数据，让模型处理判断。

例如，分析一千条工单时，脚本可以完成分页读取、分类统计和样本抽取，只把统计结果与必要样本交给模型。

机器接口可以继续返回结构化 JSON，面向模型的摘要则按任务裁剪。真正影响开销的是返回多少无关内容，而不仅是选择哪种格式。

第五步：用真实任务验证，再下线旧入口。

选择一组历史任务，比较迁移前后的成功率、耗时、上下文消耗和人工介入次数，并检查权限范围有没有扩大。

只读任务可以并行比较结果；写操作应在测试环境验证，避免双跑产生重复发布或重复修改。确认替代路径稳定后，再移除旧配置和不再需要的凭据。

四、哪些MCP仍然建议保留？

最值得保留的 MCP，通常承担着明确的边界职责：限制 Agent 能访问什么、能执行什么，以及凭据由谁持有。

服务器操作就是典型场景。

Agent 能够执行 ssh，只说明它具备远程操作能力。生产环境还需要回答：它应该使用哪个账号？允许执行哪些命令？是否能够读取私钥？出错后会影响多大范围？

classfang/ssh-mcp-server 提供了一个值得保留的实现方向。根据项目文档，它支持在服务端管理 SSH 凭据、配置命令黑白名单，并通过连接名称选择服务器，同时提供命令执行和文件传输工具。项目中文文档

Agent 直接操作服务器与经受控 SSH MCP 入口操作的安全边界对比

在正确部署时，Agent 先提交操作请求，SSH MCP 检查目标与命令规则，再使用受限 SSH 账号执行并返回结果。

相比把可自由操作服务器的 SSH 权限直接交给 Agent，这种受控入口更适合保留。

但安全收益来自具体配置与隔离措施。应使用低权限账号、收紧允许执行的命令，并保护凭据及规则文件，避免 Agent 通过其他路径绕过限制。命令正则也不能等同于完整的 Shell 沙箱；文件上传和下载需要单独考虑权限范围。

同样值得保留的还有以下几类：

  • 集中鉴权的企业服务。 负责用户身份、租户边界、短期凭据和访问范围。
  • 具有业务约束的操作入口。 例如只允许提交经过校验的发布任务，而不是暴露任意部署命令。
  • 封装特殊环境的服务。 例如必须运行在内网、专用设备或特定会话中的能力。
  • 服务多个客户端的统一接口。 当调用方缺少终端或代码执行环境时，MCP 仍能降低接入成本。