MCP：责任过载
一个常见的批评是MCP承担了过多的责任。作者认为，MCP应该主要作为LLM访问和与外部资源交互的门户。将其视为简单的“门”或“桥梁”有助于明确其目的和局限性。
将诸如意外数据泄露、提示注入漏洞和成本控制缺陷等问题直接归咎于MCP是错误的。这些是开发人员应该在他们控制的范围内解决的问题。无论使用何种协议，开发人员都需要实施速率限制并监控使用情况。这好比把超速行驶归咎于道路——基础设施不应对个人行为负责。
最终，许多被提出的担忧是与将任务委派给AI Agent相关的更广泛的问题。开发人员必须负责管理其特定应用中的这些挑战，而不是期望API本身处理所有事情。
LLM与提示注入的双刃剑
最近关于MCP的讨论常常类似于关于锋利刀具的固有危险的警告——如果处理不当，它们可能会造成伤害。提示注入是一个重要的担忧，它是LLM本身性质的后果。试图消除提示注入风险会降低使LLM有价值的能力。
传统系统中常见的“控制与数据”分离的概念，在LLM中并不自然存在。LLM之所以获得其力量和通用性，恰恰是因为它们缺乏这种严格的分离。这种固有的特征使它们容易受到提示注入攻击。
虽然远程MCP即服务可能存在风险，但问题不在于协议本身，而在于将敏感任务委托给不受信任的第三方。这类似于将一把刀用胶带粘在一个不稳定的Roomba上——问题不在于刀本身，而在于将其连接到不可预测的设备的决定。
告诫“小心”或建议保护装备，虽然技术上准确，但忽略了核心问题：将锋利的工具与不受控制的系统结合起来是不明智的。
可扩展性挑战
除了安全问题之外，MCP还面临着基本的可扩展性限制。作者强调了LLM可靠性与所提供的指令上下文数量之间的负相关关系。这挑战了增加更多数据和集成将自动解决问题的普遍观点。随着工具和集成数量的增加，Agent的性能可能会下降，同时增加每个请求的成本。
作者强调，MCP无法超越某个阈值进行扩展。尝试向Agent的上下文中添加无限数量的工具将不可避免地对它的能力产生负面影响。这种限制是MCP概念固有的，需要比身份验证问题更多的关注。
用户最终可能会体验到性能下降，因为他们启用了更多的MCP服务器，导致它们之间发生干扰。这与典型的包管理系统形成鲜明对比，在典型的包管理系统中，互不干扰是一个基本属性。
MCP的核心问题是它的实际行为偏离了用户的期望。至关重要的是要认识到MCP不是一个即插即用的解决方案，它可以无缝地集成无限数量的工具而不会产生后果。
通过UI和工具管理解决局限性
一个解决MCP局限性的建议是改进用户界面。如果一个工具被意外执行，UI应该提供一种简单的方法来禁用它或修改其描述以明确其预期用途。
作者还指出，上下文增长通常会导致性能的提高和实际使用能力的提升，这与严格的负相关概念相矛盾。但是，他们承认在某些用例中或使用设计不佳的上下文时，可能会发生性能下降。
为了解决工具选择过多的问题，建议采用“分而治之”的方法。这涉及到添加一个专门用于选择给定任务最相关工具的工具。这个“工具选择工具”可能是另一个LLM调用，其任务是返回可用工具的子集给“父”Agent。这种分层方法增加了额外的间接级别来管理复杂性。
但是，仅仅在上下文中拥有工具就可以显着改变模型的输出。虽然上下文相关的工具（通过诸如检索增强生成或RAG之类的技术实现）是有益的，但将所有工具隐藏在“get_tools”请求后面可能是有害的。
MCP作为传输和授权层
MCP主要用作具有请求/响应生命周期的传输和线路格式，重点在于工具级别的授权。文章认为，MCP的最大问题在于它未能使AI Agent在功能上组合工具。
作者认为，MCP可能根本没有必要，因为LLM已经具备与使用OpenAPI规范记录的API交互的能力。缺失的要素是授权——控制AI可以访问哪些API的能力。作者建议，与其使用MCP，不如允许AI发出HTTP请求，同时对特定端点应用授权。这种方法与目前用薄MCP工具包装现有API的趋势相一致。
MCP一个特别令人恼火的方面是它缺乏对流式传输工具调用结果的支持。单个请求/响应对迫使客户端重复调用工具进行分页，从而阻碍了长时间运行的进程。实现流式传输功能（可能使用gRPC）可以显着提高MCP的效率。
暴露敏感数据的易用性
MCP的一个重要担忧是容易暴露敏感数据的可能性。此外，MCP本质上并不会使AI Agent更可靠；它只是授予它们访问更多工具的权限，这可能会在某些情况下适得其反地降低可靠性。
作者承认，他们不期望MCP解决或负责所有这些问题。相反，MCP为这些问题创造了更大的表面积，要求应用开发人员和用户保持警惕。
类比和城市规划
作者使用城市规划的类比来说明这个问题。将MCP比作一条有25英里/小时限速的六车道城市道路，突出了设计与预期用途之间的脱节。仅仅处以罚款或添加表面上的“修复”并不能解决不良设计的根本问题。
有效的城市规划涉及设计能够自然鼓励遵守速度限制的道路。类似地，MCP应该被设计为固有地减轻潜在风险，而不是仅仅依靠外部控制。
LLM采取不希望的行动
本文转向对允许LLM在服务上执行操作的协议的更广泛批评。作者确定了一个核心问题：LLM可能会采取用户不希望它们采取的行动。他们区分了LLM可以独立采取的行动和需要用户提示的行动。
虽然最终目标可能是让LLM管理整个业务，但该技术尚未为此做好准备。目前，用户甚至可能不希望AI在未经事先审查的情况下发送电子邮件。
作者拒绝了提示用户确认的解决方案，理由是当大多数工具看起来无害时，用户可能会陷入自动确认的模式（“YOLO模式”）。这类似于人们用卡比用现金消费更多的心理现象——一个植根于人类行为而不是技术的问题。
根本问题：为什么不直接使用API？
在关于MCP的讨论中，一个反复出现的问题是为什么不直接使用API。
MCP允许用户不直接控制的LLM客户端（例如，Claude、ChatGPT、Cursor、VSCode）与API交互。如果没有MCP，开发人员将需要使用LLM API构建自定义客户端，这比使用具有订阅的现有客户端并教他们如何使用特定工具要昂贵得多。
一位开发人员分享了他们构建MCP服务器以通过USB连接到他们的FM硬件合成器的经验，从而实现了AI驱动的声音设计。
LLM客户端集成和标准化
核心问题是并非所有LLM客户端都原生支持直接API交互，ChatGPT自定义GPT操作是一个值得注意的例外。Anthropic、Google和OpenAI已同意采用MCP作为共享协议，以简化Claude、ChatGPT和Cursor等LLM驱动客户端的流程。
MCP简化了构建LLM客户端的流程。如果你希望LLM与API交互，你不能简单地提供一个API密钥并期望它能够工作——你需要创建一个Agent。
MCP可以被视为一种记录API并描述如何调用它们的方式，以及用于公开该文档和促进调用的标准化工具。它提供了足够的抽象来包装API，而没有不必要的复杂性，但这种简单性也可能导致用户“搬起石头砸自己的脚”。
MCP的效率和可重用性
如果没有MCP，开发人员每次调用工具时都需要反复向LLM解释如何使用该工具。这会带来LLM由于忘记信息或非标准API行为而无法正确使用该工具的风险。
这种不断的解释和重复浪费了上下文中的token，增加了成本和时间。MCP通过捆绑所有必要的信息来简化此流程，从而使工具的使用更加高效并促进工具共享。
通过告诉LLM提供商“这是一个你可以使用的工具”以及API文档，用户可以在多个聊天中重用该工具，而无需重复提醒。这还使桌面LLM客户端能够连接到本地运行的程序，从而解决了特定于OS的执行过程的问题。
MCP和本地资源访问
MCP促进了LLM对本地资源（如文件、环境变量和网络访问）的访问。它被设计为在本地运行，从而授予LLM对这些资源的受控访问。
标准LLM工具调用“形状”与MCP工具调用“形状”非常相似，使其成为连接工具和Agent的简单标准。
MCP充当暴露给AI模型的功能调用模式和底层API之间的桥梁。它将功能调用转换为工具，从而实现无缝通信。
如果你是工具提供商，MCP提供了一个标准化协议，供AI Agent前端连接到你的工具。这回答了为什么标准协议不能简单地是HTTP和OpenAPI的问题。
MCP是一个元API，它将端点及其操作细节纳入规范，使LLM能够更有效地与它们交互。
MCP在特定场景中的应用
当用户提出问题或不确定使用哪些API时，MCP可以解决问题。它还可以根据之前的消息处理请求。
一位用户分享了他们想要检索用户的“X”并将其发送到端点的经验。他们发现MCP对于如此简单的任务来说是多余的，这表明它并不总是基本API交互所必需的。
MCP类似于用于构建可以通过网络通信的软件的FastAPI Web应用框架，专门为Agent体验而设计。它可以被视为“Rails-for-Skynet”，为AI Agent开发提供了一个标准化框架。
对提供商控制的担忧
有人担心MCP正在被推动以增加提供商对系统的控制。LLM提供商最终可能会限制API访问，类似于Google如何让使用IMAP/SMTP与Gmail变得困难。
使用OpenAPI允许Agent从/openapi.json检索API规范。
MCP实现了快速交互，允许用户在几秒钟内完成任务，而不是花费时间准备输入数据，将其发送到API，解析输出，并为每个消息重复该过程。
沙盒和安全风险
最大的问题之一是一个MCP服务器工具的输出如何影响同一消息线程中的其他工具。这需要对工具之间进行沙盒化，以防止意外后果。Invariant Labs通过工具描述解决了这个问题，而其他公司则使用了MCP资源附件。缺乏沙盒化加剧了提示注入风险。
这类似于SQL注入——一个拼凑起来的系统，漏洞可以在任何时候以最小的可观察性被利用。
提示接口也容易受到一种SQL注入的影响，因为模型无法区分提示中值得信赖的部分和用户污染的输入。解决这个问题需要对编码、解码和模型训练进行根本性的改变。
这允许提示注入和工具注入，可能导致执行不可信的代码。
容器化和受控访问
一位开发人员创建了一个MCP服务器，该服务器启动一个安装了项目代码的Docker容器。这种方法允许LLM访问沙盒环境中的整个Unix工具集和特定于项目的工具。
这种通过基于聊天的界面驱动的Agent工作流程已被证明比传统方法更有效。
关键是授予MCP Agent访问他们需要的内容，而不是更多。容器化和透明的工具UX对于减轻安全风险至关重要。
虚拟机和互联网访问
为Agent提供一台安装了最少Linux安装的计算机（作为VM或容器）可以产生更好的结果，允许他们从互联网获取信息。但是，这引发了关于恶意指令和数据泄露的安全问题。
限制对受信任网站的访问可以减轻一些风险，但即使是受信任的来源也可能托管恶意内容。必须仔细考虑遇到恶意指令的可能性与生产力收益之间的权衡。
员工和AI Agent之间的差异是显着的。员工是受法律和合同约束的法人，提供问责制。AI Agent缺乏这种法律框架，使得信任更加困难。
MCP开发的早期阶段
MCP仅在2024年11月宣布，RFC正在积极发展。
有些人认为包括MCP在内的整个AI个人助理概念从根本上存在缺陷。
在1990年代末和2000年代初，对AI助理的最初推动失败了，因为具有垂直整合和批量购买力的内容聚合器被证明更有效。这导致了Expedia和eBay等平台的兴起。
多Agent系统要求程序员影响Agent的状态，这是一项具有挑战性的编程任务。
免费价值的限制
“按停车可用性对结果进行排名”的愿望突出了访问付费API或广告支持的前端背后数据的问题。公司不太可能通过API免费提供对其整个数据集的访问。
虽然并非所有公司都会将他们的数据集成到AI Agent中，但组合各种工具来驱动工作流程的潜力仍然很大。
优先考虑维护数据护城河的公司可能会抵制威胁该护城河的新技术。
如果booking.com有一个API，他们可能会返回与其网站相同的结果，可能使用JSON或XML格式。
绕过中间人
对于像booking.com这样的中间人来说，允许用户完全绕过他们的服务是没有意义的。
但是，个别酒店可能会发现绕过他们通常不喜欢的中间人booking.com是有益的。
一个深度研究AI可以根据特定标准扫描酒店，并与各个酒店运行的酒店发现MCP服务器交互，而无需浏览booking.com的界面和广告。
实际用例
MCP可以促进以更结构化的方式从Elasticsearch获取日志或查询数据库等任务。
MCP服务器配置的静态性质（其中新服务器需要编辑.json文件并重新启动应用）可能具有局限性。
微调模型
MCP可以被看作是一个小的、微调的模型，它理解众多的MCP工具，并为每次对话选择合适的工具。
根据上下文动态调整工具可能对于某些场景是必要的。
开放式对话和业务问题
MCP非常适合没有预定义流程的通用、开放式对话系统。但是，它不是解决每个业务问题的一刀切的解决方案。它并非旨在取代LangChain等框架。
MCP的替代方案是一个开放的社区驱动的标准，该标准是分散的、专有的和供应商锁定的协议。一个有缺陷但不断发展的标准比没有标准要好。
看待MCP的最佳方式是从各个开发人员构建API周围的客户端包装器到API提供商或社区维护的包装器构建它们的一种转变。这提供了一个大型工具箱，类似于NPM或PyPi。但是，仍然需要编排、安全和使用定义。
下一代Langchain将受益于这个更大的工具箱，但仍然需要创新。
用户特定的工具
在某些情况下，工具可能特定于用户数据，例如用于切片和操作上传的CSV文件的工具。
一个经常被忽视的问题是MCP可能会使模型上下文拥挤过多的选项。优先级排序和元数据暴露对于避免浪费token使用和不稳定的模型行为至关重要。
标准和不断发展的技术
随着时间的推移，新的标准会出现，自从标准真正重要以来已经很久了，人们已经忘记了它们是如何发展的。
从随机开发人员那里下载小型服务器程序以向LLM客户端添加“工具”可能存在风险。
提出的问题是MCP生态系统需要解决的合法问题。一些解决方案将在MCP规范中，而另一些将在外部。
Claude代码和实际使用
对于MCP的成功与否存在不同的看法。有些人听说过公司与MCP集成的故事，而另一些人则从用户那里听说过它令人失望。
这突出了炒作和早期采用的缺点。
一些开发人员发现，对于大多数用例，HTTP API优于MCP。他们认为，“工具”的使用归结为功能的API端点。
API默认情况下不是自描述的，这代表了REST和HATEOAS支持者展示他们方法的一个错失机会。
MCP作为LangChain的替代方案？
MCP被描述为具有“LangChain气味”——没有解决一个紧迫的问题，过于抽象，难以解释其优势。
也许它需要说“END OF LINE”并将那些想成为黑客的人驱逐到游戏网格！
一个关键问题是“通用”聊天机器人范例是否会持续存在。具有自己专用工具的专用应用可能不需要MCP。
相反，随着LLM变得越来越有能力，外部工具可能变得不那么必要。当LLM可以直接编辑图像时，为什么你想要一个MCP来驱动Photoshop？
科幻小说机器人助理的梦想可能不会实现，专业的语言操作工具可能更有用。
用户群和安全意识
MCP的用户群包括技术水平较低的个人，使得安全问题尤其重要。提高对安全最佳实践的认识至关重要。
基于需要定义结果模式的OpenRPC的Xops有助于计划输出如何连接到输入，从而提高复杂工作流程的可靠性。
该技术可能会随着时间的推移而发展和稳定。
冗余和云基础设施
有些人质疑使用MCP而不是OpenAPI标准所获得的收益，认为它是多余的。
LLM将使用什么来调用OpenAPI系统？它将如何绑定到shell？LLM的主机将如何编排？
MCP为LLM进行工具调用提供了一种结构化的方式。
MCP服务器已经是HTTP服务器。
MCP最大的优势在于像OpenAI这样的LLM提供商，而不是应用开发人员。
LLM是没有工具的大脑，而工具调用赋予它们力量。但是，使用普通API，LLM提供商无法访问这些工具。MCP授予他们访问权限，将他们定位为AI的门户。
CLI与API
鉴于LLM接受过自然语言训练，并且CLI是一种常见的人类可读和可写解决方案，为什么不直接使用CLI？
MCP出现得太快，需要时间才能成熟。它缺乏传统标准机构的审查，并且受到炒作的驱动。
缺乏实际应用。
MCP的关键应用
MCP用于Claude Desktop和利基AI聊天应用、代码自动化工具和Agent/LLM自动化框架。
这是另一项仓促的技术，可能会在下一个可炒作的首字母缩写词出现时被丢弃。
有两种语言模型工具调用协议：人们抱怨的协议和没人使用的协议。
Anthropic在真空中开发了这个“标准”，导致了安全问题。
JSON-RPC 2.0
MCP建立在JSON-RPC 2.0之上，JSON-RPC 2.0是一种轻量级协议，允许客户端和服务器使用JSON进行通信。
感觉就像一个为特定生态系统设计的集中式规范，声称具有普遍性，但没有赢得它。
MCP足够强大，可以做有用的事情，这引发了安全问题。
它不是一个成熟的标准，也不是为了安全而设计的。
虽然存在建议，但它们没有被强制执行或实施。
Langchain和工具调用
Langchain是实现“工具调用”模式的众多框架之一。
MCP是一个规范，用于说明外部信息如何进入语言模型的上下文窗口，包括工具调用、模板化输入、取消、进度跟踪和工具服务器的状态。
它有助于标准化细节，以便任何助理/集成组合都兼容。
虽然MCP存在合法问题，但批评者应该完善他们的论点。
身份验证至关重要，不应从初始版本中省略。
有太多的复杂性。