正文
https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview）
机制
：如果你和我一样，第一次接触 MCP 时可能会想：“这不就是工具调用吗？”确实很像，但 MCP 在工具服务器的网络连接细节上定义得更明确。显然，设计者希望让 Agent 开发者能够轻松接入，因此在接口设计上保持了极大的相似性和易用性。
Alexa / Google Assistant SDKs
（
https://developers.google.com/assistant/sdk）
：与这些面向物联网（IoT）的助手 API 有不少相似之处（优劣并存）。但 MCP 更聚焦于 LLM 场景，提供基于文本、AI 助手无关的接口规范（如 name、description、json-schema），而非复杂的、专用的语音助手 API。
SOAP / REST / GraphQL
：这些是更底层的通信协议（MCP 基于 JSON-RPC 和 SSE 构建），而 MCP 明确定义了一组固定的端点和数据结构，只有遵循这些规范，才能实现兼容接入。
3、问题一：协议的安全性
我会先从一些常见的问题说起，然后再深入探讨更细微的问题。首先，我们先从协议中存在的安全问题开始，这里的安全问题并不特指 AI 相关。
1. MCP 最初没有定义身份验证规范，现有方案也难令人满意
MCP 最初并未定义统一的认证机制。考虑到认证方案设计本身就较为复杂，协议设计者在早期阶段选择不纳入也是情有可原。然而这也导致各个 MCP 服务器各自为政，从高度复杂的认证流程到几乎无任何鉴权机制都有，尤其在访问敏感数据时风险更大。
后来，协议中终于加入了认证规范，但因为设计权衡复杂，引发了新的争议，相关改进工作仍在进行中。
2. MCP 服务器可在本地运行任意代码，存在滥用风险
MCP 协议支持通过 stdio 运行本地服务器，无需部署 HTTP 服务，极大降低了使用门槛。但许多工具的集成方式是让用户下载并直接运行第三方代码，这等于为恶意代码的本地执行打开了方便之门，尤其对技术水平不高的用户而言风险更高。虽然这类攻击方式并不新鲜，但 MCP 协议的设计降低了滥用门槛。
3. MCP 服务端通常会太相信传进来的输入
这其实也不算什么新鲜事，但现在很多 MCP 的服务器实现方式基本上就是“照着用户的输入直接执行代码”。这不是在黑开发者，因为这个事本身确实挺难转变思维的 —— 按传统安全思路来看，MCP 里的动作本来就是用户自己定义、自己控制的，那如果用户想在自己的机器上执行任意命令，好像也没啥问题？
问题就出在：一旦你中间加了个大模型来“翻译”用户意图，这事儿就变得很模糊，也很容易出问题了。
4、问题二：UI/UX 的局限性
虽然 MCP 的接口设计对 LLM 很友好，但对人类用户来说并不总是如此。
1. MCP 无法识别或区分工具的风险等级
用户可能正在使用各种与 MCP 连接的工具与助手聊天，包括读取日志（read_daily_journal）、预订航班（book_flights）、删除文件（delete_files）等。这些工具虽然大大提升了效率，但也带来了风险：某些操作不可逆或代价高昂，而 MCP 本身并没有机制去区分这些操作的风险等级。
虽然 MCP 协议建议在关键操作前增加确认，但如果用户习惯了大多数工具“安全可用”，很容易养成“默认确认”甚至“无脑操作”的习惯。一旦遇到危险操作，后果往往已经不可挽回，比如误删重要照片，甚至自动重订行程。
