如果你这半年给 Agent 接过 MCP，大概率干过同一件事：平台有什么接口，就包成一个工具；工具越多，心里越踏实。
ServiceNow 的一组研究人员把这份踏实拿去测了。同样的模型、同样的 729 个任务、同样的三个企业平台（ServiceNow、GitLab、ERPNext），只换 Agent 跟系统打交道的方式：一种拿 MCP 工具箱，一种开浏览器点网页，一种只给一个终端和文件系统，让它自己读文档、自己 curl 接口。论文已发表在 TMLR。
最刺眼的一格在 ServiceNow：MCP 服务器给了 83 个工具，四个前沿模型（Sonnet 4.6、Opus 4.6、GPT-5.4 Thinking、Gemini 3.1 Pro）的成功率只有 11.5% 到 18.5%。同一批任务，只有终端的 Agent 做到 73.6% 到 79.1%。
我的判断是：输的不是 MCP，是“替模型把路修好”这种思路。你包的每一个窄工具，都在悄悄规定 Agent 能做什么。83 个工具不是 83 种能力，是 83 道围栏。
证据来自 Patrice Bechard、Orlando Marquez Ayala、Emily Chen、Jordan Skelton、Sagar Davasam、Srinivas Sunkara、Vikas Yadav、Sai Rajeswar（ServiceNow；Sai Rajeswar 同时在 Mila 与蒙特利尔大学）的 《Terminal Agents Suffice for Enterprise Automation》（arXiv:2604.00073，TMLR，2026 年 10 月）。代码在 ServiceNow/StarShell。
工具越多，能做的越少
最能说明问题的不是 ServiceNow，而是另外两个平台的对比。GitLab 的 MCP 有 81 个工具，和 ServiceNow 几乎一样多，工具派成功率 45.2% 到 48.9%。ERPNext 的 MCP 只有 7 个工具，反而是工具派离终端派最近的地方，Opus 4.6 做到 68.9%。
ERPNext 那 7 个工具特别在哪？它们是通用的增删改查，能作用在任何单据类型上。工具少，但每个都“宽”。ServiceNow 的 83 个恰好相反：一个工具对应一个具体操作，任务一旦需要一个没被包进去的字段、一种没被预想到的查询，Agent 就只能干瞪眼。论文开头有个例子：让 MCP Agent 下单一台 iPad Pro，它找到了商品，却没有“下单”这个工具，最后去开了张工单，任务失败。
作者还做了一个更狠的消融：把那堆工具换成一个通用的 api_call，就一个，能发任意 API 请求，差距几乎全部补了回来——附录 C.2 里，Sonnet 4.6 全量 73.5%（工具派 32.9%，终端 72.7%），每个任务 0.15 美元，Opus 4.6 是 79.2% 对终端的 78.7%，ServiceNow 上分别从 11.5% 和 16.1% 拉到 72.6% 和 79.5%。所以优势的来源不是“终端”这个形式，而是“没有被预先规定的接口”。
浏览器能做到，但贵得离谱
网页 Agent 确实灵活，人能点的它都能点，成功率和终端派基本打平：全量任务上，四个模型里有三个相差在一个点左右。代价是每一步都要吞下整棵无障碍树和截图。ServiceNow 上，网页 Agent 的单任务成本是终端的 2 到 7 倍；Opus 4.6 在 ERPNext 上，网页 6.49 美元一单，终端 0.72 美元，贵 9 倍，成功率只多 4.8 个点（81.6% 对 76.8%）。Gemini 3.1 Pro 的终端 Agent 全平台 77.5%，每个任务 0.09 美元，是整张表里最划算的配置。
那把浏览器和终端都给它呢？Sonnet 4.6 两样都拿到之后，ServiceNow 成功率没涨，72.1%，还略低于纯终端的 73.6%，成本 3.02 美元，接近纯终端 0.78 美元的四倍。Opus 4.6 挑出来了一部分：混合之后到 83.0%，是这一格里最高的，成本 2.57 美元，仍高于纯终端的 1.94 美元。多给一样工具，模型不一定会挑。
真正值钱的工具，是 Agent 自己写的
论文里还有一个容易被忽略的结果：允许终端 Agent 把踩过的坑写进一个 skills 文件夹，下次先翻再干。三个平台一共写下 38 个 skill 文件。ServiceNow 上单任务成本降了 43.7%（0.78 → 0.44 美元），成功率涨了 3.4 个点；ERPNext 成功率涨了 5.3 个点，GitLab 涨了 1.6 个点。这些 skill 里写的大多不是“怎么调接口”，而是界面标签对应哪个 API 字段、哪个字段语义是反的、JSON 引号怎么不被 shell 吃掉。恰恰是你提前包工具时想不到的那部分。
人提前修的路，是按人的想象修的；Agent 自己走出来的路，是按任务真实的形状长出来的。
别误读
这不等于 MCP 该扔。作者自己强调，输的是“大量窄的、按端点一一包装的工具目录”，不是协议本身。也不等于浏览器没用：ServiceNow 的模拟登录靠浏览器 cookie，终端打到 /api/now/ui/user/impersonate 拿到 HTTP 200，会话却没切过去，网页 Agent 点两下就完成；拖拽式的流程编辑器更是没有公开 API。终端和网页各自能解对方解不了的题。ServiceNow 上拿 Sonnet 4.6 来算，终端能解 55 道网页解不了的，网页能解 51 道终端解不了的；每题都挑对那一个，能到 89.1%，比这一对里任何一方都高 15 个点以上。只是今天的模型还不会挑。
明天就能做的一件事
打开你接的 MCP 服务器，数一下工具。如果超过 20 个，而且大多是“一个接口一个工具”，先别再往里加了。加一个通用的 api_call（或者干脆给一个受限的 shell），配一份 API 文档和一个可写的笔记目录，拿你最近失败的十个任务重跑一遍。成功率要是上去了，你就知道那 83 道围栏是谁修的了。
If you've wired an agent to MCP this year, you've probably done the same thing everyone does: every endpoint the platform has becomes a tool, and more tools feel safer.
A team at ServiceNow put that feeling to a test. Same models, same 729 tasks, same three enterprise platforms (ServiceNow, GitLab, ERPNext). The only thing that changed was how the agent touched the system: an MCP toolbox, a browser it clicks through, or just a terminal and a filesystem where it reads the docs and curls the API itself. The paper is out in TMLR.
The ugliest cell is ServiceNow. The MCP server exposes 83 tools, and four frontier models (Sonnet 4.6, Opus 4.6, GPT-5.4 Thinking, Gemini 3.1 Pro) succeed 11.5% to 18.5% of the time. On the same tasks, the terminal-only agent lands 73.6% to 79.1%.
My read: MCP didn't lose. The habit of paving the road for the model did. Every narrow tool you wrap quietly decides what the agent is allowed to do. 83 tools aren't 83 capabilities; they're 83 fences.
The evidence is Patrice Bechard, Orlando Marquez Ayala, Emily Chen, Jordan Skelton, Sagar Davasam, Srinivas Sunkara, Vikas Yadav, and Sai Rajeswar (ServiceNow; Rajeswar also at Mila and Université de Montréal), "Terminal Agents Suffice for Enterprise Automation" (arXiv:2604.00073, TMLR, October 2026). The code is ServiceNow/StarShell.
More tools, less reach
The telling comparison isn't ServiceNow alone. GitLab's MCP server has 81 tools, almost as many, and tool-use agents get 45.2% to 48.9%. ERPNext's has just 7, and that's where tool-use comes closest to the terminal: Opus 4.6 hits 68.9%.
What's special about ERPNext's seven? They're generic create/read/update/delete calls that work on any document type. Few tools, each one wide. ServiceNow's 83 are the opposite: one tool per specific operation, so the moment a task needs a field nobody wrapped or a query nobody anticipated, the agent is stuck. The paper opens with a perfect example: asked to order an iPad Pro, the MCP agent finds the item, has no order tool, opens a support ticket instead, and fails.
Then the authors ran the brutal ablation: replace the pile of tools with one generic api_call that can send any request, and that single tool closes almost the whole gap. In Appendix C.2, Sonnet 4.6 reaches 73.5% overall (tool-use 32.9%, terminal 72.7%) at $0.15 a task, Opus 4.6 reaches 79.2% against the terminal's 78.7%, and on ServiceNow the two go from 11.5% and 16.1% to 72.6% and 79.5%. The advantage isn't the terminal as such. It's an interface nobody pre-decided.
The browser can do it, at a ridiculous price
Web agents really are flexible: anything a person can click, they can click, and overall they roughly tie the terminal, within about a point for three of four models. The price is swallowing a full accessibility tree and screenshots at every step. On ServiceNow, web agents cost 2 to 7 times what terminal agents do per task. Opus 4.6 on ERPNext: $6.49 per task through the browser versus $0.72 through the terminal, 9 times the cost for 4.8 more points (81.6% vs 76.8%). Gemini 3.1 Pro's terminal agent gets 77.5% across all platforms at $0.09 a task, the best deal in the whole table.
What about giving it both? With Sonnet 4.6, terminal plus browser didn't raise ServiceNow success: 72.1%, a hair under the terminal's 73.6%, at $3.02, nearly four times the terminal's $0.78. Opus 4.6 did pick up some of it: the hybrid reaches 83.0% on ServiceNow, the best cell there, at $2.57, still above the terminal's $1.94. Handing a model one more tool doesn't mean it knows when to pick it.
The tools worth having are the ones the agent writes
One result is easy to miss: let the terminal agent jot down what it learned in a skills folder and check it before each task. Across the three platforms it wrote 38 skill files. On ServiceNow, cost per task fell 43.7% ($0.78 to $0.44) and success rose 3.4 points; on ERPNext, success rose 5.3 points; on GitLab, 1.6. The skills are mostly not how to call the API. They're which UI label maps to which API field, which flag has inverted meaning, how to keep the shell from eating your JSON quotes. Exactly the part you can't foresee when you pre-wrap tools.
A road you pave in advance follows your imagination. A road the agent walks into existence follows the actual shape of the work.
Don't over-read it
This isn't a reason to throw out MCP. The authors are explicit that what lost was a large catalog of narrow, per-endpoint tools, not the protocol. And browsers aren't useless: ServiceNow impersonation lives in browser cookies, so the terminal got an HTTP 200 from /api/now/ui/user/impersonate that did nothing while the web agent finished in two clicks, and drag-and-drop flow editors have no public API at all. Each mode solves tasks the other can't. On ServiceNow with Sonnet 4.6, the terminal solves 55 tasks the web agent can't, and the web agent solves 51 the terminal can't; picking the right one per task would reach 89.1%, more than 15 points above either of that pair. Today's models just can't pick yet.
One thing to do tomorrow
Open the MCP server your agent uses and count the tools. If it's over 20 and mostly one-tool-per-endpoint, stop adding more. Add one generic api_call (or a sandboxed shell), give it the API docs and a writable notes folder, and rerun your last ten failed tasks. If the success rate goes up, you'll know who built those 83 fences.