什么是MCP以及它有什么用？
MCP（Model Context Protocol，模型上下文协议）允许第三方工具和数据源构建插件，可以将这些插件添加到AI软件（例如Claude、ChatGPT、Cursor等）中。这些AI（基于文本型大语言模型构建的友好用户界面）通过“工具”来执行非文本操作。MCP允许用户自带工具（BYOT，bring-your-own-tools）进行插拔。
作为一种清晰的标准，它让助手公司能够专注于构建更好的产品和界面，同时允许这些第三方工具自行构建到与助手无关的协议中。MCP的核心价值在于其能够高效地提供上下文（而不是复制粘贴，它可以根据需要搜索并获取私有上下文）以及代理自主性。具体到Cursor，可以利用MCP来实现超出集成开发环境（IDE）默认提供的更多调试自主性（例如，screenshot_url、get_browser_logs、get_job_logs）。
与其他标准的比较
ChatGPT 插件
非常相似， OpenAI 最初的想法是正确的，但执行得不够好。SDK 的使用难度稍高，当时许多模型对工具调用的支持不够完善，而且感觉它更像是为 ChatGPT 量身定制的。
Tool-Calling
如果你第一次看到 MCP 时可能会想：“这不就是工具调用吗？” 它确实有点类似，不过 MCP 在连接应用程序与工具服务器的网络细节方面更加明确。显然，设计者希望它能够方便代理开发者接入，并且设计得与工具调用非常相似。
Alexa/Google Assistant SDKs
与智能助手物联网API有许多（好与坏的）相似之处。MCP 专注于一种对 LLM（大语言模型）友好且与助手无关的基于文本的接口（名称、描述、JSON 模式），而这些SDK则更倾向于复杂且特定于助手的API。
SOAP/REST/GraphQL
这些属于更低层次（MCP 基于 JSON-RPC 和 SSE 构建），并且 MCP 规定了必须使用的一组特定的端点和模式，以实现兼容性。
问题1:协议安全性
首先讨论协议中与人工智能无关的安全性问题。MCP 最初没有定义身份验证规范，现在虽然定义了，但人们却不满意。身份验证是一个棘手的问题，因此设计者选择不在协议的第一个版本中包含它是相当合理的。这意味着每个 MCP 服务器都自行实现“身份验证”，其方式从高摩擦（high-friction）到完全不存在的授权机制，用于敏感数据访问。自然而然地，有人会觉得身份验证是一个非常重要的事项，需要明确定义，但是实施了这一规范后，事情变得复杂了。
MCP 服务器可以在本地运行（恶意代码）。
该规范支持通过标准输入输出（stdio）运行 MCP“服务器”，这使得在不实际运行 HTTP 服务器的情况下使用本地服务器变得毫无阻力。这导致许多集成要求用户下载并运行代码才能使用它们。显然，由于下载和运行第三方代码而导致被入侵并不是一种新的漏洞，但该协议实际上为技术能力较弱的用户在其本地机器上被利用开辟了一条低阻力的路径。
MCP 服务器通常会信任它们的输入。
这并不是什么新奇的现象，但似乎许多服务器实现往往会有效地“执行”输入代码。我并不完全责怪服务器的开发者，因为这确实是一种与传统安全模型截然不同的思维方式。从某种意义上说，MCP 的操作完全由用户定义并由用户控制——如果用户希望在其自己的机器上运行任意命令，这是否真的算是一种漏洞呢？当在其中加入大语言模型（LLM）意图翻译器时，情况就变得模糊且有问题了。
MCP 服务器通常会信任它们的输入。
这种现象很常见，但似乎许多服务器实现往往会有效地“执行”输入代码。并不完全责怪服务器的开发者，因为这确实是一种与传统安全模型截然不同的思维方式。从某种意义上说，MCP 的操作完全由用户定义并由用户控制——如果用户希望在其自己的机器上运行任意命令，这是否真的算是一种漏洞呢？当在其中加入大语言模型（LLM）意图翻译器时，情况就变得模糊且有问题了。
问题2：UI/UX限制
MCP 没有工具风险级别的概念或控制机制。
用户可能正在与一个连接了多种MCP工具的助手进行聊天，这些工具包括：read_daily_journal(…)、book_flights(…)、delete_files(…)。尽管他们选择的集成为自己节省
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。
本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！
程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）
