我对MCP的批评者进行了压力测试
每个人都在热议Anthropic的模型上下文协议（MCP）。但同样的批评不断涌现：象征性的膨胀、延迟、除了挥手回应什么都没有的冷启动。 所以我自己制作了一个马具来测量它，当然也是为了学习。
此回购包含 9个Python实验+一个真正的MCP stdio服务器 验证对MCP的每一个主要批评。
______________________________________________________________________
关键结果
| 测试 | 索赔 | 状态 | 关键发现 |
|---|---|---|---|
| 01 | 工具架构膨胀 | ✅ 已验证 | 100工具= +18468个代币 （486×架空） |
| 02 | 循环乘数 | ✅ 已验证 | 3-tool工作流程= 4个完整的LLM通行证，代币增长71% |
| 03 | 结果污染 | ✅ 已验证 | 全原木废料 71%代币 vs过滤 |
| 04 | 大海捞针 | ⚠️ 无定论的 | 100项目量表100%准确（声称：10-50%失败） |
| 05 | 工具模糊 | ✅ 已验证 | 相似名称： 40%准确率 与100%具有不同名称的情况相比 |
| 06 | 缓存无效 | ⚠️ 无定论的 | 3.3%延迟差异（需要Anthropic API进行验证） |
| 07 | 工具搜索延迟 | ✅ 已验证 | 添加额外的转弯，但保存 10k+代币 当许多工具 |
| 08 | 注射攻击 | ✅ 抵抗 | 模型固定在提供的工具上，但存在攻击面 |
| 09 | 输出架构模糊 | ✅ 已验证 | 缺少模式会使代码生成变得脆弱 |
| 主控程序 | 冷启动开销 | ✅ 测量 | 平均约368毫秒 （生成时间：2毫秒，初始化时间：360毫秒） |
| 主控程序 | 工作流编排 | ✅ 有效的 | 服务器端链接： 字节数减少52%, 3→1 电话 |
什么是真实的：
- 工具模式膨胀巨大（100个工具每回合18k+令牌）
- 循环乘数复合成本（用户发送1条消息→ 模型处理4+个请求）
- 结果污染严重（返回原始数据浪费70%以上的令牌）
- 冷启动时间约为350-370ms（适用于长会话，不适用于无服务器）
- 工具命名很重要（名称不明确会使准确率降至40%）
什么是可修复的：
- 工具搜索（仅加载相关工具，节省10k+代币）
- 服务器端编排（链式工具，将往返次数减少50%以上）
- 输出模式（使编程使用可靠）
- 智能过滤（从大型数据集中删除70%以上的令牌）
什么是基础：
- 工具模式的代币税（如果工具在提示中，您需要支付）
- 循环乘数（多步=多调用（上下文就是这样工作的））
- 冷启动开销（生成+握手需要时间）
- 长寿命与无服务器（MCP在IDE/聊天中大放异彩，在边缘功能方面很尴尬）
📋 我测试了什么
第一阶段：Python实验（9个测试）
每个实验都验证了来自 YouTube视频批评MCP:
- 工具架构选项卡 -使用0、10、50、100工具测量令牌开销
- 循环乘数效应 -在多步骤工作流程中跟踪每回合代币增长
- 结果污染 -比较完整结果与过滤结果令牌的使用情况
- 草垛针故障 -从大数据集中提取测试模型精度
- 工具选择错误 -使用不同或模糊的工具名称测量精度
- 缓存失效 -比较静态与动态工具定义的延迟
- 工具搜索延迟 -从工具搜索步骤测量开销
- 注入漏洞 -尝试对抗性工具的重新定义
- 输出模式歧义 -比较有/没有模式的代码生成
第2阶段：真正的MCP服务器（2个基准）
构建了一个Node.js MCP stdio服务器来测试协议级行为：
- 创业基准 -测量冷启动时间、状态持久性、无服务器友好性
- 工作流基准测试 -测试编程工具调用（服务器端编排）
______________________________________________________________________
🚀 快速入门指南
先决条件
- Python 3.9+
- Node.js 18+
- OpenRouter API密钥（或修改为直接使用Anthropic/OpenAI）
设置
# 1. Clone the repo
git clone https://github.com/yourusername/MCP-Test.git
cd MCP-Test
# 2. Install Python dependencies
pip install -r requirements.txt
# 3. Install Node.js dependencies (for MCP server)
cd mcp && npm install && cd ..
# 4. Configure API key
echo "OPENROUTER_API_KEY=your_key_here" > .env运行Python实验
# Run individual test
python run_test.py 01 # Tool schema bloat
python run_test.py 02 # Loop multiplier
python run_test.py 03 # Result pollution
# Run all 9 tests (uses API credits: ~$0.25-0.45)
python run_test.py all运行MCP服务器基准测试
cd mcp
# Test 1: Cold start + statefulness
npm run bench:startup
# Test 2: Workflow orchestration
npm run bench:workflow
# Run all benchmarks
npm run bench:all结果保存到： mcp/results/*.json 和 mcp/results/summary.csv
______________________________________________________________________
📁 项目结构
MCP-Test/
├── experiments/ # Python test suite
│ ├── common/
│ │ ├── openrouter_provider.py # API calls with usage tracking
│ │ ├── agent_loop.py # Tool-calling loop with metrics
│ │ ├── stub_tools.py # Safe local tool implementations
│ │ └── token_count.py # Token estimation utilities
│ └── cases/
│ ├── test_01_tool_schema_bloat.py
│ ├── test_02_loop_multiplier.py
│ ├── test_03_result_pollution.py
│ ├── test_04_needle_haystack.py
│ ├── test_05_tool_selection.py
│ ├── test_06_cache_invalidation.py
│ ├── test_07_tool_search_latency.py
│ ├── test_08_injection_simulation.py
│ └── test_09_output_schema.py
├── mcp/ # Real MCP server (Node.js)
│ ├── server.ts # MCP stdio server
│ ├── bench/
│ │ ├── startup.ts # Cold start benchmark
│ │ └── workflow.ts # Orchestration benchmark
│ └── results/ # Benchmark output
├── run_test.py # Test runner
├── requirements.txt # Python dependencies
└── README.md # This file📖 结果和理解
示例输出（测试01：工具模式块）
================================================================================
TEST 01: Tool Schema Bloat
================================================================================
============================================================
Running: No tools
============================================================
Tool schema size: 0 tokens (no tools)
RESULTS:
Turns: 1
Total tokens: 38
Prompt tokens: 33
Completion tokens: 5
============================================================
Running: Large (100 tools)
============================================================
Tool schema size: 17,501 tokens (~98,060 chars)
RESULTS:
Turns: 1
Total tokens: 18,506
Prompt tokens: 18,447
Completion tokens: 59
================================================================================
SUMMARY: Tool Schema Bloat Impact
================================================================================
Configuration Tools Tool Tokens Total Tokens Overhead
--------------------------------------------------------------------------------
No tools 0 0 38 -
Large (100 tools) 100 17,501 18,506 +18,468 (48600%)
VERDICT:
✓ Tool definitions add 18,468 tokens (487.0x more)
✓ This overhead is repeated on EVERY turn in the loop
✓ CLAIM VALIDATED: Large tool schemas bloat context massively寻找什么
代币指标：
- 工具架构大小：仅通过工具定义添加的令牌
- 代币总数：完成请求成本（提示+完成）
- 开销：与基线相比，额外的令牌（无工具）
- 每轮增长：多步骤工作流中上下文如何增长
延迟度量：
- 冷启动时间：生成+初始化MCP服务器的时间
- 每转延迟：每个推理过程的API响应时间
- 总延迟：端到端工作流时间
准确性指标：
- 选择精度：选择正确的工具（%）
- 提取精度：提取的正确数据（%）
- 故障率：错误的结果或错误（%）
成本估算
使用 anthropic/claude-3.5-sonnet 通过OpenRouter：
- 测试01-03：每个约0.10-0.20美元
- 测试04-09：每个约0.05-0.15美元
- 全部9项测试：总计约0.25-0.45美元
MCP基准是本地的（没有API成本）。
______________________________________________________________________
🔍 详细调查结果
1.工具模式块是真实的
索赔：“对话开始前，58个工具=55k个令牌”
测试：使用0、10、50、100个工具测量令牌开销。
结果: ✅ 已验证
- 0个工具：38个令牌
- 100个工具：18506个令牌（工具定义：17501）
- 开销：+18468个代币（486倍以上）
- 每次转弯都重复 在多步骤对话中
为什么这很重要：如果你按代币支付，加载100个不相关的工具每回合需要花费约18000个代币。
______________________________________________________________________
2.循环乘数是残酷的
索赔：每次工具调用时都显示“整个历史与模型一起重新运行”
测试：在3工具工作流程中跟踪每轮代币增长。
结果: ✅ 已验证
- 4次完整的模型推理过程 （1次初始+3次工具返回）
- 总共3503个代币 （3134次提示，369次完成）
- 总延迟17.83秒
- 提示词元 增长71% 从第一回合开始→ 转4圈（579→988）
为什么？ 每个回合包括：
- 原始系统提示
- 原始用户消息
- 所有工具定义（重复）
- 以前的助手消息
- 以前的工具调用结果
为什么这很重要：用户发送1条消息。模型处理4个请求。代币成本复合。
______________________________________________________________________
3.中间结果污染环境
索赔：“即使不需要，10MB日志文件也会进入上下文”
测试：比较完整日志与过滤日志令牌的使用情况。
结果: ✅ 已验证
- 返回完整日志： 23582个字符 （约3930个代币）→ 总计8097个代币
- 预过滤（13条错误行）： 490个字符 → 总计2324个代币
- 储蓄: 71%
为什么这很重要：返回原始数据集是浪费的。服务器端过滤（或“程序化工具调用”）大大降低了令牌成本。
______________________________________________________________________
4.干草堆中的针“10-50%失败”
索赔：“最佳情况下10%的查找失败，最差情况下50%的查找失败”
测试：10次试验，从100名总用户中提取5名管理员用户。
结果: ⚠️ 非决定性的
- 模型准确率：10/10完美匹配（100%）
- 代码准确性：100%（确定性）
警告：在这个规模（100个项目）下，模型一次也没有失败。“10-50%失败”索赔可能适用于 *大得多* 数据集（1000个项目），但我没有在这里重现。
为什么这很重要：基于代码的过滤始终是100%可靠的。模型提取通常很好，但不能保证。
______________________________________________________________________
5.工具模糊会破坏准确性
索赔：“相似的名称会导致失败”
测试：将准确度与不同与模糊的工具名称进行比较。
结果: ✅ 已验证
- 不同的名称 （1个工具）：100%正确选择（5/5次试验）
- 相似名称 （5个工具：
notify_user,notification_send_user,notification_send_users): 40%正确 （2/5次试验）
为什么这很重要：当工具名称重叠时，模型会出现问题。明确的命名或明确的示例至关重要。
______________________________________________________________________
6.缓存无效影响
索赔：“开始时的任何更改都会破坏缓存”
测试：将延迟与静态和动态工具定义进行比较。
结果: ⚠️ 非决定性的
- 静态工具：平均延迟5.91秒
- 动态工具 （每次请求更改）：平均延迟6.11s
- 差异: 3.3%
警告：OpenRouter不会像Anthropic的API那样公开缓存遥测。这个测试需要Anthropic的 cache_control 头球是决定性的。
为什么这很重要Anthropic的快速缓存可以将成本降低90%，但对静态前缀的任何更改都会使缓存无效。动态工具加载完全中断了缓存。
______________________________________________________________________
7.工具搜索增加了延迟
索赔：“刀具搜索会增加额外的转弯开销”
测试：在有和没有工具搜索步骤的情况下测量延迟。
结果: ✅ 已验证（有权衡）
- 直接执行：20.32秒，3494个代币
- 使用工具搜索：16.94秒，2517个代币
- 额外延迟：-3.38秒（更快！）
- 代币节省：-977个代币
权衡：工具搜索增加了一个额外的回合，但是 保存令牌 当你有很多工具的时候。值得拥有100多种工具。
为什么这很重要Anthropic的工具搜索功能有助于解决臃肿问题，但增加了复杂性。
______________________________________________________________________
8.注射漏洞
索赔：“历史上的工具定义可能被劫持”
测试：试图重新定义对抗性工具和注入虚假工具。
结果: ✅ 模型抵制 （但存在攻击面）
- 工具重新定义尝试：失败
- 假工具注射：失败
为什么这很重要：模型在此测试中受到抵制，但攻击面存在（特别是如果工具定义被加载到消息历史记录中而不是系统提示中）。防御：对输入进行消毒+保持工具对服务器的控制。
______________________________________________________________________
9.输出模式歧义
索赔：“无返回格式标准”
测试：比较了有/没有输出模式的代码生成。
结果: ✅ 已验证
- 没有模式：模型必须猜测输出格式→ 脆性代码生成
- 使用模式：模型知道确切的格式→ 可靠解析
为什么这很重要：MCP工具定义通常缺少输出模式。这使得“编程工具调用”（模型编写代码解析输出）变得脆弱。解决方案：将输出模式添加到工具定义中（但很少有人这样做，因为它是可选的）。
______________________________________________________________________
10.MCP冷启动顶置
测试：真正的Node.js MCP stdio服务器启动基准测试。
结果: ✅ 测量
- 产卵时间：~2ms（快速）
- 初始化/握手：约360毫秒（慢速）
- 总计: 平均约368毫秒 （5次跑步）
为什么这很重要：冷启动并不可怕，但足以排除“MCP无处不在，就像无服务器一样”。对于长期会话来说很好，对于一次性调用来说很尴尬。
______________________________________________________________________
11.工作流编排工作
测试：比较传统（3个单独的工具调用）与工作流（1个编排的调用）。
结果: ✅ 有效的
- 传统：3次调用，496字节，2.31ms
- 工作流程：1个调用，239字节，1.26ms
- 储蓄：字节数减少52%，往返次数减少2次
为什么这很重要：服务器端编排（在返回模型之前链接工具）是一种有效的缓解措施，可以减少往返和令牌浪费。
______________________________________________________________________
🗣️ 社区在说什么
除了技术测试，以下是开发人员对MCP的评价：
| 来源 | 关键引文/见解 | 背景 | 链接 |
|---|---|---|---|
| @vyrotek（2026年1月24日） | “几年前感觉就像一个死规范。” | 在MCP上下文中指JSON-RPC，指出它似乎已经过时，但正在重新出现。 | 查看帖子 |
| @aparnadhinak（2026年1月24日） | “同意，并不是说MCP已经死了。评论我们看到的势头转变。” | 观察到MCP的转变，这意味着它正在减弱。 | 查看帖子 |
| @elvissun（2026年1月24日） | “这些技能中没有MCP。你无法获得搜索量或反向链接配置文件，因此它实际上是无用的。” | 批评缺乏MCP集成的技能，使其在没有真正的API功能的情况下变得无用。 | 查看帖子 |
| @trungking（2026年1月24日） | “但随着时间的推移，现在只使用了一些MCP，其他一切都死了，几乎没有人谈论它。” | 关于MCP的炒作逐渐消退，大多数实现都没有被使用和遗忘。 | 查看帖子 |
| @AlexWalz\_（2026年1月24日） | “我的主要问题是，随着渐进式披露原则的实施，MCP是否已经死亡？” | 认为MCP会导致重复调用和代币浪费，这表明API等替代方案更好。 | 查看帖子 |
| @anders36415（2026年1月24日） | “RAG已经过时了，我假设MCP将是下一个。” | 预测MCP在RAG衰落后会过时。 | 查看帖子 |
| @\_overment（2026年1月24日） | “为什么模型上下文协议不起作用” | 客座文章从开发人员和用户的角度分析了MCP的挫折感。 | 查看帖子 |
| @chaseadams（2025年11月5日） | “这篇Anthropic帖子证实了我在MCP上看到的情况：提前加载所有定义会快速燃烧代币。它还埋下了MCP造成上下文腐烂的隐患。” | 强调代币燃烧和上下文退化是主要缺陷。 | 查看帖子 |
| @alxfazio（2025年12月17日） | “mcps是混蛋。为什么即使你不使用它们，它们也会被加载到上下文中？技能已经解决了这个问题……” | 批评不必要的上下文加载；称赞技能优越。 | 查看帖子 |
| @thdxr（2025年11月9日） | “大多数mcp服务器都是垃圾，经常崩溃……这真的感觉像是我讨厌的那种产品……” | 列出了实际的抱怨：不稳定、臃肿、没有实质内容的炒作。 | 查看帖子 |
| @lsof（2026年1月22日） | “模型上下文协议（MCP）-直接连接到企业系统的人工智能模型会给安全工具带来盲点。规模风险：一个受损的MCP服务器=数据/令牌/API暴露。” | 强调MCP实现中的安全风险和盲点。 | 查看帖子 |
| @thedaldirector（2026年1月24日） | “我认为MCP无论如何都必须被淘汰，因为它是一种无效的上下文引入方式，同时消耗了太多的代币。” | 由于效率低下和安全风险，呼吁逐步淘汰MCP。 | 查看帖子 |
| @raythurnvoid（2026年1月24日） | “嘿，我试过剧作家测试，我完全失败了，你认为今天可行吗？顺便说一句，剧作家远比光标浏览器、困惑浏览器、浏览器库和剧作家MCP好” | 这意味着剧作家MCP比剧作家等替代品差。 | 查看帖子 |
这些真实世界的观察结果与该测试套件中的许多技术发现一致。
______________________________________________________________________
如果您正在采用MCP，请使用以下清单：
- \[ \] 使用工具搜索 如果你有10个以上的工具。每回合18k代币加起来很快。
- \[ \] 清楚地命名工具。 避免
send_email_user,send_user_email,email_send_user模型精度储罐。 - \[ \] 添加输出模式 工具定义。有助于代码生成+调试。
- \[ \] 过滤服务器端的大型数据集 在回到上下文之前。不要转储23kb日志。
- \[ \] 编排多步骤工作流 如果可能的话，在服务器上。减少往返次数。
- \[ \] 预计约350ms冷启动 对于Node.js服务器。适合聊天，不适合边缘功能。
- \[ \] 使用提示缓存 （Anthropic的cache_control）将成本削减90%，但保持工具定义不变。
令牌膨胀和循环乘数是真实的。他们也是 *可预测的* 并且在许多情况下是可修复的。
🙏 贡献
想添加更多测试吗？线束已准备就绪：
- 在中添加新的测试文件
experiments/cases/ - 使用
AgentLoop以及存根工具experiments/common/ - 更新
run_test.py包括新的测试
如果您发现错误或有想法，请打开问题或PR！
______________________________________________________________________
📄 许可证
MIT许可证-自由使用。
______________________________________________________________________
🔗 学分
基于对a的分析 YouTube视频 讨论MCP故障模式和Anthropic提出的解决方案。
使用Python、Node.js、OpenRouter和健康的怀疑论构建。 🧪