MCP或将成弃子

Anthropic 的工程师们上周发了篇博客，可以说是 直接把自家的 MCP 给「背刺」了。

而这时间点，也好巧不巧，正好就是 MCP 推出刚刚一年之际。

文章中提出了一个方案，能让 token 消耗从 150,000 降到 2,000，直接节省 98.7%！

在我看来，这个方案其实说的就是： 别用 MCP 了，写代码吧！

此话怎讲？且往下看——

Token 黑洞

MCP（Model Context Protocol）的设计思路很简单：把工具们的「说明书」塞进 Claude 的 context window，然后让模型决定要不要用，怎么用。

但这就好像，给一位工人配了一套工具箱，但要求他必须把所有工具的使用手册都摊在工作台上。

于是， 问题来了：

假设你有 100 个工具，每个工具定义占 150 tokens. 然后还没开始干活，context 就被占了 15,000 tokens 了。

如果是大型企业场景的 1000 个工具呢？

那就是 150,000 tokens！

工作台都被说明书占满了，哪还有地方干活呢？

别急，还有另一个更要命的： 数据「过路费」：

比如你要把 Google Drive 的文档同步到 Salesforce，传统 MCP 的流程是这样的：

Claude 调用 Google Drive API，10KB 的文档返回到 context（消耗 10,000 tokens）。Claude 读取内容，再调用 Salesforce API，把这 10KB 发出去（又消耗 10,000 tokens）。

在这里，Claude 就是个搬运工的角色而已，但却付了两次过路费。

Claude 模型价格

Anthropic 的文章里提到，复杂工作流可能消耗 150,000+ tokens。处理 50 个客户反馈生成报告，光 token 成本就要 $0.225，还要等 100 秒。

又慢又贵，极其浪费。

从调工具到写代码

Anthropic 团队表示，他们发现了一个被忽视的事实： Claude 写代码的能力远超调用工具的能力。

想让 Claude 从 100 个工具中找到正确的，理解参数格式，正确调用， 这很难 。

但让 Claude 写段 Python 代码？

那 Claude 可就高兴了： 这题我会 。

from tools import db, email# 查询数据users = db.query("SELECT * FROM users WHERE last_active > '2024-01-01'")# 筛选活跃用户（在代码中处理，不经过 context）active_users = [u for u in users if u.login_count > 10]# 批量发送for user in active_users:    email.send(user.email, "您是我们的活跃用户...")

而这里的关键在于： 代码在沙箱执行，中间数据不经过 context。

MCP 变成文件系统

新的方案是把 MCP 服务器转换成了代码文件来运行。

MCP 方案：

所有工具定义加载到 context，Claude 需要理解这些定义，然后调用。

新的代码方案：

servers/├── google-drive/│   ├── getDocument.ts      # 可执行的代码文件│   └── index.ts├── salesforce/│   ├── updateRecord.ts│   └── index.ts

Claude 只需要看到文件结构，然后写代码导入：

import { getDocument } from './servers/google-drive'import { updateRecord } from './servers/salesforce'

然后执行，然后完事。

上下文很干净，token 也很少，一切都很美好。

来做一下数字对比

同样是「把 Google Drive 文档同步到 Salesforce」：

MCP：

工具定义加载：15,000 tokens

文档数据传输：20,000 tokens

总计：35,050 tokens

往返次数：4 次

代码：

文件结构理解：500 tokens

Claude 写代码：200 tokens

结果返回：20 tokens

总计：720 tokens

往返次数：1 次

节省： 97.9% tokens ， 75% 时间 。

Skills 或成 MCP 的替代品

Skills 是 Anthropic 上个月在 Claude Code 中引入的功能（网页版中也能使用），见： Claude 推出 Skills 功能，及 Agent Skills 开发指南 。

而 Skills 在本质上，可以理解为就是一个包含知识、代码和最佳实践的文件夹，例如：

/mnt/skills/user/my-tools/├── SKILL.md          # 简短的说明文档└── src/              # 实际的代码文件    ├── github.ts    ├── database.ts    └── utils.ts

而在我看来，上个月推出的 Skills 其实是上周文章的伏笔，二者的组合之下， MCP 可能要成弃子了 。

再看个例子对比

MCP 方式

即使用户只问「帮我搜索 AI 相关的仓库」，12 个工具定义也全在 context 中（~2,400 tokens）。

执行后返回 20 个仓库的完整数据（~5,000 tokens）。

总计约 8,000 tokens。

Skills 方式

Claude 读取 SKILL.md（100 tokens），写代码（150 tokens），代码在沙箱执行，20 个仓库数据在沙箱内处理，只返回格式化的 Top 10 列表（500 tokens）。

总计 750 tokens。

而还有一个重要的， 是代码的可组合性。

处理「分析 TypeScript 生态中最活跃的 10 个项目」这种复杂任务，Skills 方式下 Claude 可以写一段完整的分析代码，50+ API 调用在沙箱完成，数据处理、分析、图表生成都在沙箱，Claude 的 context 只看到最终结果。

Token 消耗约 2,000，而不是 100,000+。

实战迁移

如果你看到了这里，那你可能要心动了。你可能想问：

那是不是可以把 MCP Server 转换成代码和 Skills 的方式呢？

答案当然是肯定且简单的。

假定原 MCP Server 的 tool handler 长这样：

server.addTool({  name: 'query_database',  description: 'Query PostgreSQL database',  parameters: {...},  handler: async (params) => {    // 数据库查询逻辑  }})

转换为 Skills 则是这样：

// /mnt/skills/user/data-tools/src/database.tsexport async function queryDatabase(sql: string): Promise<any[]> {  // 同样的数据库查询逻辑扔这里}

再写个简洁的 SKILL.md，完成。

使用时，Claude 只需要读取 SKILL.md（100 tokens），写代码调用这些函数（200 tokens），执行（数据不经过 context），返回结果（10 tokens）。

总 tokens：310，而 MCP 方式要 12,000，节省 97.4%。

问题出在哪里？

传统 MCP 的问题本质是： 计算发生在错误的地方。

所有数据必须经过 context，而 context 是很「贵」的（每个 token 都要钱都要经过计算），有大小限制（100K-200K tokens），往返延迟高。

而代码 + Skills 的方案，则把计算下沉到了沙箱之中。

数据处理在沙箱中，不经过 context，Context 只有代码和结果，干净简单。

而为什么 LLM 写代码比调用工具更高效呢？

因为代码是 LLM 的「母语」，是 Claude 的一直 bet 的超强项。

LLM 训练数据中有数十亿行代码样本，想出错已经很难了，但 API 调用定义只有数百万个。

在 LLM 写出 const filtered = users.filter(u => u.age > 18) 时，它隐式知道 JavaScript 数组方法、异步操作、类型推断，并且这些知识不需要在 context 中明确说明，它早已内化于心了。

而对于工具调用，则需要大量 tokens 来描述 LLM 不那么知道的东西。

MCP 还有未来吗？

那么……MCP 是不是要 deprecated 了？

虽然我已经让 Claude Code 自己把我的几个大 MCP 转成 Skills 在用了，但也不能说 MCP 从此就完了，至少目前 MCP 还有些有价值的场景：

大型组织需要统一的工具接入标准

复杂协议实现（LSP、DAP）

权限和安全控制

第三方生态

只是目前来看，大多数场景下，Skills + 代码 > MCP.

至于未来，MCP 则可能变成一种「 中间格式 」，还会有些自动转换工具可以把 MCP Server 转成 Skill 代码。

我其实可以（让 Claude Code）做一个，只是我最近确实太忙了，你若有兴趣就交给你了，我还在看 Claude Agent SDK 混乱的文档。

也可能会是混合式的架构：部分用 Skills（ 大量的长尾工具 ），另一部分则保留 MCP（ 核心的高频工具 ）。