我们用错了MCP：它的真正价值只有一个

MCP 真正的价值：认证，而非别的

围绕模型上下文协议（MCP, Model Context Protocol）的讨论越来越热，但一位 YouTube 开发者抛出了一个颇具争议的观点：我们大多数人其实用错了 MCP。他的核心主张很直接——你使用 MCP 的唯一理由应该是它封装了认证（auth），仅此而已。

这个判断听起来简单，却点出了当前 AI 工具生态里一个被普遍忽视的问题：很多人把 MCP 当成了给 LLM 提供能力的"万能插座"，却忽略了它真正不可替代的部分其实是权限边界的控制。

CLI 登录模式的隐患

作者用 Cloudflare 的 Wrangler CLI 举了个反面例子。当你在命令行工具里登录账号后，凭证就常驻在本地环境中。问题随之而来：任何能访问这个 CLI 的 agent，都能借此对你的 Cloudflare 账户执行操作。

这是一种相当危险的授权模型。你并没有为某次具体的 agent 运行单独授权，而是把整个账户的操作能力暴露给了任何能触及该环境的程序。对于越来越自动化、越来越"放养"的 AI agent 来说，这种大范围、长期有效的凭证无异于一张空白支票。

这种风险在安全领域被称为"凭证蔓延"（Credential Sprawl）——长期有效的访问令牌散落在各个环境中，难以追踪和撤销。传统的最小权限原则（Principle of Least Privilege）要求每次操作只获得完成该操作所必需的最低权限，且权限应在操作结束后立即失效。CLI 常驻凭证恰恰违背了这一原则：它相当于给 agent 颁发了一张"无限期通行证"，而非"单次访客证"。在 AI agent 场景下，这个问题被进一步放大——agent 可能被提示注入（Prompt Injection）攻击操控，恶意指令可能借助合法凭证执行破坏性操作，而系统无法区分这是用户授权行为还是攻击行为。

MCP 的独特之处：按需授权 + 明确动作集

相比之下，MCP 的授权方式更精细。作者指出，你可以针对某一次具体运行启用某个 MCP，这样 agent 获得的是一组被限定的操作（a set of actions）以及对应的认证。

换句话说，MCP 把"你能做什么"和"你被授权做什么"打包在一起，形成了一个可控的作用域。这才是它相对于裸 CLI 或自制脚本真正的优势所在——不是能力本身，而是对能力的约束与隔离。

MCP（Model Context Protocol）是由 Anthropic 于 2024 年末提出并开源的标准协议，旨在统一 LLM 与外部工具、数据源之间的交互方式。其设计借鉴了 OAuth 2.0 的授权思路：服务提供方（MCP Server）声明自己能提供哪些工具（Tools）和资源（Resources），客户端在发起具体任务时按需请求访问，而非预先获取全部权限。这种"动态能力发现 + 作用域受限"的模式，使得同一个 agent 在不同任务中可以获得不同的权限集合，从而实现细粒度的权限管理。这也是为什么作者强调 MCP 的核心价值在于认证边界，而非工具能力本身——协议层真正做到了将"能调用什么"与"被授权调用什么"在架构层面显式分离。

能力提供：MCP 并不比自制方案更优

这里是作者观点中最反直觉、也最值得深思的部分。他明确表示：单就提供能力而言，MCP 并没有任何天然优于你自己写的工具的地方。

理由在于，现代 LLM 极其擅长遵循指令。如果你直接告诉模型"这里有五件你能做的事"，它完全可以照做，根本不需要把这些动作包裹进一层 MCP 协议里。协议层在能力表达上并没有带来额外魔力，反而增加了复杂度。

一个真实案例：直接驱动程序的 agent

作者以自己的项目（听起来像是一个名为 Alakargi 的工具）为例说明这一点。该系统有一个 client，client 直接告诉模型"这里是所有你能做的事"，然后模型就直接调用底层程序运行。

这个程序能做的事非常"底层"：获取屏幕图像、发送按键、执行鼠标操作。作者描述道，他可以让模型直接控制鼠标——"移动、双击"，模型自己就知道怎么用。于是它一路操作下去，直接开始使用界面，整个过程没有 MCP 介入。

这个案例有力地支撑了作者的核心论点：当你只是想让 LLM 使用某些能力时，一套清晰的指令和一个可调用的程序就足够了，MCP 在这种场景下是多余的。

对开发者的启示

这番观点为正在构建 AI agent 的开发者提供了一个实用的决策框架：

• 需要跨账户、跨服务的权限隔离与按需授权？ 用 MCP，它的认证模型正是为此而生。
• 只是想给模型暴露一组内部动作？ 直接写清指令、提供程序接口即可，不必强行套用 MCP。

当然，这只是单一来源的个人观点，带有明显的实践立场。MCP 生态仍在快速演进，标准化带来的工具复用、互操作性等价值也不应被完全忽视。但作者提出的问题切中要害：在引入任何协议层之前，先想清楚它到底解决了什么问题——是认证，还是仅仅因为"大家都在用"。

对于那些盲目把一切能力都塞进 MCP 的团队来说，这是一记值得听的提醒。