核心发现
方法论
论文围绕四个研究问题展开：人工分析116个官方MCP服务器，研究REST依赖；对42个拥有OpenAPI规范的服务器进行工具—操作对齐；从80份真实OpenAPI合约生成MCP服务器；最后在AutoMCP中结合规范缺陷检测、自动修复、工具过滤与分组。数据来自Anthropic目录、APIs.guru和Konfig。
关键结果
- 116个服务器中，88.6%完全或部分依赖厂商REST API；其中92%的工具属于几乎不加适配逻辑的“裸API包装”。这表明当前MCP生态主要是在重新表达既有API，而非构建全新的能力抽象。
- MCP服务器仅暴露底层API操作的中位数19%。以GitHub为例，REST API超过600个操作，而官方MCP仅提供51个工具；Slack超过200个方法，却只暴露8个工具，显示工具选择存在稳定的压缩规律。
- AutoMCP基线生成在工具层面成功率为76%；规范修复后升至94.2%。过滤与重组将每个API的中位工具数减少约三分之一，缓解模型工具选择和上下文负担。
研究意义
研究首次以大规模实证方式连接REST API、OpenAPI与MCP工具设计，解释了为什么MCP接口通常只是供应商API的子集。它把“工具太多导致选择准确率下降”这一代理系统痛点，转化为接口供应侧的可测量设计问题。对工业界而言，结果支持从手工编写服务器转向规范驱动生成；对学术界而言，研究提供了工具暴露率、遗漏类别和映射结构等可复用基线。
技术贡献
AutoMCP是端到端流水线：读取OpenAPI中的servers与securitySchemes自动配置服务和认证，检测不完整安全声明、缺失参数、循环引用及实现不一致等缺陷并进行修复，再依据实证模式过滤低价值操作、合并相关工具。与FastMCP的一对一转换不同，它同时处理规范质量和工具集合复杂度；与ToolFactory的自然语言合成不同，它直接利用机器可读契约。
新颖性
论文声称这是首个系统研究MCP服务器构建及其与厂商REST API关系的大规模实证工作。新颖性不只在于OpenAPI转MCP，而在于把真实开发模式、生成失败分类、规范修复和工具集变换整合为统一方法，并用116个服务器、42个映射样本和80份合约验证。
局限性
- RQ1样本来自官方目录并要求仓库至少10个GitHub stars，可能高估成熟项目、低估小众或私有服务器的多样性。
- RQ2依赖公开且可配对的OpenAPI规范；未公开、过时或与实现不一致的API难以进行操作级对齐。
- 成功率主要由工具生成和人工测试衡量，尚未充分证明过滤、分组对真实LLM任务完成率的因果提升。
未来方向
后续应在更多非官方、私有和动态API上验证AutoMCP，并用API-Bank、T-Eval式任务直接测量工具压缩对规划、参数填写和结果解释的影响。还需研究安全策略、权限最小化、跨工具组合及基于使用日志的自适应分组。
AI 总览摘要
大型语言模型代理正在从“回答问题”转向调用外部服务：查仓库、发消息、更新数据。然而，连接这些服务通常需要手工编写MCP服务器。论文指出，一个关键事实长期缺乏数据支持：许多MCP工具其实只是REST API的另一种包装，而供应商API往往远大于模型真正需要的工具集合。
研究团队分析了116个官方MCP服务器、42个带OpenAPI规范的服务器，并用来自APIs.guru和Konfig的真实合约评估自动生成。结果显示，88.6%的服务器完全或部分依赖REST，92%的工具是裸API包装；MCP只暴露底层操作中位数19%。AutoMCP读取OpenAPI，自动处理认证和服务器配置，修复规范缺陷，并通过过滤、重组压缩工具集合。基线生成成功率为76%，修复后达到94.2%，工具数量中位数减少三分之一。
这项工作把MCP建设从经验性手工工程推进为可测量、可自动化的软件工程流程。它也提醒开发者：覆盖更多API并不等于代理更强，因为工具目录过大可能使选择准确率下降7%至85%。目前证据仍主要来自公开、较成熟项目，工具压缩是否必然提升真实任务表现尚待直接实验；但AutoMCP为更可靠、更易维护的代理基础设施提供了明确路线。
深度分析
研究背景
MCP以JSON-RPC和模式驱动的工具描述统一LLM代理调用外部服务。GitHub、Notion和Slack等厂商已发布服务器，但其能力常与REST API重叠。既有Swagger Codegen、OpenAPI Generator和FastMCP主要解决代码转换，不处理工具规模或规范缺陷；ToolFactory则依赖自然语言文档且不面向MCP。
核心问题
核心问题有四个：服务器是否依赖REST；哪些API操作被暴露或遗漏；OpenAPI能否可靠生成MCP工具；如何处理错误规范与工具爆炸。难点在于真实规范存在认证缺失、复杂请求体、循环引用和文档—实现不一致，而模型又会因工具数量增长而更难选择。
核心创新
- ��首次大规模刻画MCP—REST关系。
- ��用42个配对服务器量化操作覆盖与映射。
- ��以80份真实OpenAPI合约评估生成，而非仅用合成示例。
- ��AutoMCP将缺陷修复、自动配置、一对一生成与过滤/分组结合，区别于FastMCP的直接端点转换。
方法详解
- ��RQ1：从Anthropic截至2025年7月31日的345条目录记录出发，筛得116个成熟仓库；追踪工具处理器到首次外部服务调用，标记REST、部分REST或非REST。
- ��RQ2：选出42个同时拥有官方OpenAPI的服务器，比较路径、参数、类型和枚举，识别一对一、一对多及聚合映射。
- ��RQ3：从3,784份规范按认证方式和规模分层抽样，并与42份配对API合并为80份；生成工具后人工测试调用序列。
- ��RQ4：修复规范缺陷，再执行过滤和重组，比较成功率与工具数量。
实验设计
RQ1使用116个仓库，RQ2使用42个服务器、6,966个API操作和968个工具。RQ3/RQ4覆盖80份OpenAPI；论文摘要报告基线工具成功率76%，修复后94.2%。规模分为≤20、21–100和>100操作，认证分为无认证、API key、basic/bearer和OAuth 2.0。
结果分析
结果支持明显的“API子集”规律：中位覆盖率仅19%。GitHub超过600个REST操作对应51个MCP工具，Slack超过200个方法对应8个工具。AutoMCP修复带来18.2个百分点的绝对成功率提升，并把工具集合压缩约三分之一，说明规范质量和接口规模是两个独立瓶颈。
应用场景
企业可用OpenAPI批量生成GitHub、CRM、监控或数据平台的MCP服务器，自动继承servers和securitySchemes中的配置。团队还可按风险、读写属性或业务域筛选、分组工具，降低上下文成本，并缩短新服务接入和维护周期。
局限与展望
研究依赖公开仓库、GitHub stars和公开规范，存在选择偏差；人工追踪与测试也可能受判定标准影响。论文未报告不同修复规则的完整消融，也没有直接在真实代理任务上证明工具压缩提升成功率。未来需要在线评测、安全与权限测试，以及面向动态API的持续同步。
通俗解读 非专业人士也能看懂
把一个MCP服务器想成酒店前台。REST API是酒店后台所有服务的总菜单：客房、洗衣、维修、餐厅，可能有几百项；MCP工具是前台真正摆给客人的快捷菜单，通常只放最常用的十几项。论文先调查116家“酒店”，发现大多数前台只是把后台菜单换了种写法，92%的工具几乎直接转交后台。
问题是，后台菜单本身常有错字、漏写价格或步骤不清。AutoMCP像一位自动质检员：先读菜单，补齐认证、参数和地址，修复循环引用等错误，再把很少用的项目隐藏，把相关项目合并。这样，原本生成成功率只有76%，修复后达到94.2%；菜单项目中位数还减少三分之一。
这并不意味着项目越少越好，而是要让客人更容易找到正确服务。对LLM代理来说，工具太多就像面对几百页菜单，可能选错。论文的价值，是用真实数据说明菜单应如何裁剪，并把这件事变成可重复的自动化流程。
简单解释 像给14岁少年讲一样
想象你在玩一款超级游戏，角色可以调用外卖、地图、社交媒体和仓库系统。每个系统都有一大堆按钮，但如果把几百个按钮全部塞给你，你反而会按错。MCP就像一个统一的游戏手柄，让AI用相同方式操作不同服务；REST API则是每个服务自己的后台按钮。
论文作者检查了116个官方“手柄适配器”。他们发现，88.6%的适配器其实连接的是REST后台，92%的按钮只是把后台功能原样搬过来。比如GitHub后台有600多个操作，官方MCP只给AI 51个工具；Slack有200多个方法，却只给8个。
接着作者做了AutoMCP，像一个能读说明书的机器人。它读取OpenAPI说明书，自动知道服务器地址、登录方式和每个按钮需要什么参数；如果说明书写得不完整，它会先修补，再生成工具。普通生成成功率是76%，修补后升到94.2%，工具数量也少了约三分之一。
不过，少按钮不一定总是更好。如果隐藏了关键功能，AI可能做不了任务；而且实验主要检查工具能否生成和调用，还没有完全证明真实游戏任务一定变快。因此下一步要让AI真正使用这些工具完成任务，再比较不同菜单设计。
术语表
Model Context Protocol（模型上下文协议）
一种让LLM客户端以统一格式发现和调用外部工具的协议。它使用JSON-RPC与结构化模式描述工具。
论文研究的目标接口。
REST API（REST接口）
通过HTTP资源、路径和方法提供服务能力的接口。一个API通常包含多个可调用操作。
MCP服务器最常包装的底层服务。
OpenAPI Specification（OpenAPI规范）
机器可读地描述路径、参数、请求体、响应、认证和服务器地址的合约。它可作为自动生成输入。
AutoMCP的主要输入。
Bare API Wrapper（裸API包装）
工具只完成参数转换和API调用，几乎不增加业务编排或语义适配。它保留底层字段和枚举。
92%工具的主要实现模式。
Specification Repair（规范修复）
检测并补正OpenAPI中的缺失、冲突或不可生成结构。目标是提高生成代码和调用的正确性。
AutoMCP将76%成功率提升到94.2%的步骤。
Tool-set Transformation（工具集变换）
通过过滤低价值操作或合并相关操作改变呈现给模型的工具集合。其目标是降低选择复杂度。
使工具数量减少约三分之一。
开放问题 这项研究留下的未解疑问
- 1 工具过滤和重组是否在API-Bank或T-Eval式真实任务中稳定提高规划与完成率，论文尚未直接验证。
- 2 公开成熟仓库之外，私有企业API、实时变化接口和高权限操作是否遵循相同的19%暴露规律，仍缺少数据。
- 3 自动修复可能改变原始语义或安全边界；需要权限、认证、数据泄露和错误恢复方面的独立评测。
应用场景
近期应用
企业API快速接入
拥有OpenAPI合约的企业可用AutoMCP自动生成MCP服务器，读取服务器地址和securitySchemes，减少手工认证与参数映射工作。适用于CRM、代码托管、监控和数据服务。
代理工具目录治理
平台团队可依据读写属性、业务类别和使用频率过滤或分组工具，降低上下文占用和误选风险，并为不同代理任务发布定制化工具集合。
远期愿景
规范驱动的代理基础设施
OpenAPI可能成为服务接入代理生态的统一源文件：规范更新触发服务器、权限和工具目录同步。实现这一愿景仍需解决版本漂移、安全审计与跨API组合。
原文摘要
The Model Context Protocol (MCP) is emerging as a standard interface through which LLM agents invoke external tools, and a growing ecosystem of MCP servers now mediates access to vendor services. Most of these servers target vendors that already expose REST APIs, yet the relationship between MCP tool interfaces and the underlying API surface has not been empirically characterised. This paper presents the first large-scale study of MCP server construction. We analyse 116 official servers to determine REST reliance and integration strategies (RQ1); examine servers paired with OpenAPI specifications to quantify operation exposure, omission, and mapping patterns (RQ2); evaluate automated generation from 80 real-world OpenAPI contracts (RQ3); and assess specification repair and tool-set transformations to improve correctness and reduce complexity (RQ4). We find that 88.6% of servers are fully or partially REST-backed, with 92% implementing tools as bare API wrappers. MCP servers expose a median of 19% of available operations, following systematic patterns predictable from the specification. Baseline generation succeeds for 76% of sampled tools; automated repair raises this to 94.2%, while filtering and regrouping reduce the median tool count per API by one-third. We release AutoMCP, an end-to-end pipeline integrating specification repair and empirically grounded tool-set transformations.