随着大型语言模型(LLM)技术的迅猛发展,如何让这些模型更有效地与外部软件系统交互成为业界关注的焦点。模型上下文协议(Model Context Protocol,简称MCP)服务器的出现正是为了解决这一难题。MCP的核心理念是向LLM传递可调用的软件信息,指导其如何使用这些软件接口,同时提供一条让LLM真正调用软件的路径。尽管这一目标具备一定的创新性和实用意义,但从更广泛的技术与实践视角观察,MCP或许并非必须存在于现有生态中,而更像是一种用JSON文件定义的协议样式,甚至可能显得多余。 模型上下文协议将其提供的服务分为资源、工具和提示三类。资源是被客户端读取的文件状数据,比如API响应或文件内容。
工具是可以被LLM调用的函数或命令,通常需要用户批准才能执行。提示则是一些预设的模板,帮助用户完成特定任务。乍一看,这三者之间似乎界线分明,但细究之后却发现定义存在模糊。例如,被官方标注为工具的"搜索航班"功能,本质上是一种只读操作,与资源的定义重合度很高,从而使得资源与工具的分野变得模糊且混乱。 进一步分析MCP的工具定义,可以看到它本质上就是一个远程过程调用(RPC)的接口定义。以搜索航班的工具为例,其输入包括出发城市、目的地以及旅行日期,整个接口的数据结构和调用方式和传统的API描述极为相似。
令笔者惊讶的是,当用GPT-5思考版将这段工具定义直接转化成OpenAPI规范时,结果几乎完美契合了主流Web服务的描述格式。这个过程中,OpenAPI的优势凸显:它不仅是标准化的API描述语言,而且被大规模采用,被无数工具和模型理解和支持。 这不禁让人产生疑问:既然现有的OpenAPI、gRPC和命令行接口(CLI)等机制均可满足LLM调用外部工具的需求,MCP协议为何要额外设计一套结构?尤其在OpenAPI日益普及,且模型对CLI操作的理解能力不断提升的当下,这样的协议是否具有长期价值? 拥护者通常给出的理由集中在三个方面。首先,当前LLM模型的上下文窗口有限,详细的OpenAPI文档可能占用大量宝贵的上下文空间;其次,现实中许多服务缺乏完善的API文档或标准定义,MCP能为这些服务提供快捷的定义方式;最后,LLM需要一种自动发现可用工具的机制,而非完全依赖人工配置。尽管这些论点在一定程度上成立,但随着AI技术的飞速发展,模型上下文窗口扩大到百万甚至数百万级别的Token已经成为可行事实。这也使得文档长度不再是不可逾越的瓶颈。
对于文档缺失问题,内部企业级服务确实存在大量不完善的API规范,这些可能促使MCP一战成名。然而在面对面向客户的主流SaaS产品,这一问题并不普遍。相比之下,通常创造或修改API文档的为同一群技术人员,如果他们未能提供合理完备的OpenAPI定义,也难以期待他们能书写优质的MCP协议。更重要的是,如果有能力创建这样的规范,为什么不采用早已存在且成熟的标准API描述语言? 谈到工具的发现和调用,实际上现有的机制已经十分完善。开发者们往往使用诸如AGENTS.md文件、GitHub的instructions、openapi.json文件等方式来实现对工具的标注和引用。相较之下,MCP仅仅是另一种静态宣告的形式,未能带来本质革新。
同时,目前部分企业已开始采用混合方案,例如Bruin﹩利用MCP暴露文档信息,同时依然通过传统CLI命令完成工具实际调用;Donobu﹩直接提供OpenAPI规范,也能取得良好效果。这些实践表明,MCP虽然具备一定用途,但并非必需,而更多地是以支持文档展示为主。 从趋势上来看,公众对MCP的兴趣近年明显下滑,Google趋势数据印证了这一点。MCP的设计者不可完全归责于自身,毕竟AI生态发展异常迅速,诸多实验和方案反复交替是行业常态。相比之下,现有标准和工具在可被模型理解和调用能力日益增强的条件下,正逐渐成熟稳固。MCP的出现更像是对现有生态一时不足的权宜之计,而非长远解决方案。
在探讨MCP未来方向时,需要回归本质:大型语言模型与软件交互的目标究竟是什么?真正的关键不是特定协议的诞生,而是构建能够有效帮助模型完成任务的工具和接口。无论是MCP还是OpenAPI,或是CLI,核心都应服务于提高效率和准确率。与其纠结于协议之争,不如集中精力打造用户体验优良、文档完备且易于维护的集成方案。 业界未来的发展可能会沿着提高模型上下文容量、自动生成和完善API文档、优化工具发现机制等方向前进。同时,模型自身的能力提升也将使其能够更自动、智能地理解现有接口和指令,无需依赖冗余的特别协议。CLI依旧是最灵活的工具,且大部分开发者已经习惯于其使用,而OpenAPI的标准化描述为所有Web服务提供坚实基础,有望成为模型与软件系统交互的主流选择。
综上所述,MCP服务器目前更像是一个基于JSON文件的接口定义模版,而非必须的新型协议。它确实提供了一套结构清晰的框架,但在实际应用中存在与现有工具重叠、定义边界模糊以及推广难度较大的弊端。随着AI和软件工程技术的深入融合,未来的方向应侧重于利用现有成熟标准,结合工具链和自动化能力,提升整体协作效率,而非创造看似创新但实则重复的协议层。 无论如何,MCP的出现推动了人们对于AI与软件系统交互方式的思考和探索,促使我们重新审视现有标准的优缺点以及未来可能的发展路径。它提醒我们在技术快速迭代的浪潮下,务必坚持实用、简洁与标准化的原则,聚焦于打造真正有助于任务完成的工具和接口,从而赋能更智能、更高效的AI应用生态。 。
