From REST to MCP: An Empirical Study of API Wrapping and Automated Server Generation for LLM Agents
AutoMCP studies 116 MCP servers, raising tool-generation success from 76% to 94.2% while cutting tool counts by one-third.
Key Findings
Methodology
The paper answers four research questions through repository tracing, API–tool alignment, generation experiments, and repair evaluation. It manually studies 116 official MCP repositories; compares 42 servers with vendor OpenAPI contracts; generates servers from an 80-specification corpus assembled from RQ2, APIs.guru, and Konfig; and evaluates AutoMCP, which combines defect repair, automatic configuration, filtering, and regrouping.
Key Results
- Among 116 servers, 88.6% are fully or partially REST-backed, and 92% implement tools as bare API wrappers with little adaptation beyond parameter conversion and delegation. MCP construction therefore predominantly repackages existing vendor functionality rather than introducing independently designed capabilities.
- MCP exposes a median of only 19% of available API operations. GitHub provides more than 600 REST operations but its official MCP server exposes 51 tools; Slack offers more than 200 methods but exposes only 8 tools. This indicates systematic, highly selective interface compression.
- Baseline generation succeeds for 76% of sampled tools. AutoMCP’s specification repair increases success to 94.2%, an 18.2-percentage-point absolute gain. Filtering and regrouping reduce the median tool count per API by approximately one-third.
Significance
This is the first large-scale empirical account connecting MCP construction with vendor REST APIs and OpenAPI contracts. It reframes tool overload as a supply-side interface-design problem: developers decide not only how to implement tools, but which operations agents should see. For industry, the findings justify specification-driven server generation and systematic tool curation. For research, the study supplies empirical baselines for exposure rate, omission, mapping structure, and generation failures.
Technical Contribution
AutoMCP is an end-to-end pipeline that extracts server and authentication configuration from OpenAPI fields such as servers and securitySchemes, detects specification defects, repairs them, generates MCP tools, and applies empirically grounded filtering and grouping. Unlike FastMCP’s largely one-to-one translation, it addresses both contract quality and tool-set complexity. Unlike ToolFactory’s natural-language synthesis, it uses machine-readable contracts and requires no API-specific developer knowledge.
Novelty
The novelty lies in the integrated empirical and engineering perspective. Rather than merely demonstrating OpenAPI-to-MCP conversion, the paper studies real construction patterns across 116 servers, quantifies operation omission in 42 matched cases, classifies generation failures, and combines repair with tool-set transformation. The authors position it as the first systematic study of MCP server construction and REST dependence.
Limitations
- The RQ1 corpus requires official or listed repositories with at least 10 GitHub stars, which may overrepresent mature projects and underrepresent small, private, or experimental servers.
- RQ2 requires a public, machine-readable, vendor-specific OpenAPI contract; outdated, incomplete, or implementation-mismatched specifications can prevent reliable operation-level alignment.
- Generation success and tool counts are measured directly, but the causal effect of filtering and regrouping on end-to-end LLM task completion is not yet established.
Future Work
Future studies should evaluate private, unofficial, dynamic, and security-sensitive APIs, and measure AutoMCP with API-Bank- or T-Eval-style tasks covering planning, argument completion, and response interpretation. Important directions include least-privilege tool exposure, online adaptation from usage logs, cross-tool composition, version synchronization, and security-aware specification repair.
AI Executive Summary
LLM agents increasingly act through external services, yet each new service often requires a hand-built MCP server. The paper asks whether these servers represent genuinely new agent interfaces or simply repackage existing REST APIs—and why they expose only a small fraction of the available functionality.
The authors inspect 116 official MCP repositories, align 42 of them with vendor OpenAPI specifications, and test automated generation on 80 real-world contracts drawn from RQ2, APIs.guru, and Konfig. They find that 88.6% of servers are fully or partially REST-backed and 92% are bare wrappers. MCP exposes a median 19% of API operations. AutoMCP reads OpenAPI configuration, repairs defects, generates tools, and filters or regroups them: success rises from 76% to 94.2%, while median tool counts fall by roughly one-third.
The broader message is that reliable agents require interface curation, not merely API coverage. Large tool catalogs can reduce selection accuracy by 7–85%, so deciding what the model sees is a core engineering task. The evidence is limited by public, relatively mature samples and by the absence of direct end-to-end agent-task evaluation, but AutoMCP offers a practical path from manual integration toward measurable, specification-driven infrastructure.
Deep Analysis
Background
MCP standardizes tool discovery and invocation through schema-driven JSON-RPC. Vendors such as GitHub, Notion, and Slack now publish MCP servers whose capabilities resemble their REST APIs. Prior systems—Swagger Codegen, OpenAPI Generator, and FastMCP—support specification-based conversion, while ToolFactory synthesizes wrappers from natural-language documentation. They do not jointly address specification defects, authentication automation, or tool-set scalability.
Core Problem
The paper defines four linked problems: measuring REST reliance; explaining which API operations become MCP tools; testing whether OpenAPI can support faithful automated generation; and reducing failures and tool explosion. The challenge is that real specifications contain missing security declarations, undocumented parameters, complex payloads, circular references, and implementation mismatches, while LLM tool selection degrades as catalogs grow.
Innovation
- ��A first large-scale empirical characterization of MCP–REST relationships.
- ��Operation-level exposure and omission analysis across 42 matched servers.
- ��Generation evaluation on 80 real-world OpenAPI contracts rather than synthetic examples.
- ��AutoMCP, which unifies defect detection, repair, automatic configuration, generation, filtering, and regrouping—going beyond FastMCP’s one-to-one endpoint translation.
Methodology
- ��RQ1: Starting from Anthropic’s 345-entry catalogue on July 31, 2025, the authors retain 116 mature repositories and trace each handler to its first external interaction, labeling servers REST-backed, partially REST-backed, or non-REST-backed.
- ��RQ2: They compare 42 server implementations with official OpenAPI contracts, matching paths, parameters, types, and enumerations and identifying one-to-one, one-to-many, and aggregated mappings.
- ��RQ3: They combine 42 matched APIs with stratified samples from 3,784 unique contracts, stratifying by authentication and operation count, to form 80 specifications; generated calls are manually tested.
- ��RQ4: They repair defects, then compare tool filtering and regrouping against baseline generation.
Experiments
RQ1 uses 116 repositories. RQ2 covers 42 servers, 6,966 API operations, and 968 tools. RQ3/RQ4 evaluate 80 OpenAPI specifications. The abstract reports 76% baseline tool-generation success and 94.2% after repair. Size strata are ≤20, 21–100, and >100 operations; authentication strata include none, API key, basic/bearer, and OAuth 2.0.
Results
The ecosystem follows an API-subset pattern: median exposure is 19%. GitHub’s >600 REST operations correspond to 51 MCP tools, while Slack’s >200 methods correspond to 8. AutoMCP improves absolute generation success by 18.2 percentage points and reduces median tool counts by one-third. These results identify specification quality and interface scale as separate bottlenecks.
Applications
Organizations with OpenAPI contracts can generate MCP servers for code hosting, CRM, observability, analytics, and data platforms while inheriting servers and securitySchemes configuration. Platform teams can further publish task-specific catalogs by filtering or grouping read/write operations and business domains, reducing context cost and integration maintenance.
Limitations & Outlook
Public repositories, star thresholds, and public specifications introduce selection bias. Manual tracing and testing may also depend on adjudication criteria. The paper does not provide a full ablation of individual repair rules or directly demonstrate improved real-agent task completion after compression. Future work should add online evaluations, security audits, permission analysis, and continuous synchronization for evolving APIs.
Plain Language Accessible to non-experts
Imagine a hotel. Its REST API is the complete back-office service list: rooms, laundry, repairs, restaurants—possibly hundreds of items. MCP is the front desk’s guest-facing menu. The menu uses a common format so a new assistant can serve guests without learning every hotel’s internal system. The study examines 116 such “front desks” and finds that 88.6% simply pass requests to the hotel’s existing back office; 92% of their menu items are nearly direct copies.
The back-office list is often messy: a price is missing, a form field is unclear, or two instructions point in circles. AutoMCP acts like an automatic editor. It reads the menu specification, fills in configuration and authentication details, fixes defects, creates the service buttons, and hides or combines low-value items. Success rises from 76% to 94.2%, and the typical menu shrinks by about one-third.
The lesson is not that fewer choices are always better. It is that a guest—and an AI—needs a usable menu. Too many choices can cause mistakes. AutoMCP turns menu design from ad hoc craftsmanship into a repeatable process, although it still needs testing with real guests performing real tasks.
ELI14 Explained like you're 14
Picture a video game where your character can use food delivery, maps, chat, and a school database. Each service has tons of buttons. If the game dumps hundreds of buttons on you, will you really choose the right one? MCP is like a universal controller that gives AI the same way to press buttons, while REST APIs are the hidden control panels owned by each service.
The researchers checked 116 official adapters. They found that 88.6% connect to REST backends, and 92% mostly copy backend actions. GitHub has more than 600 possible REST actions, but its MCP server gives AI 51 tools. Slack has more than 200 methods but shows only 8. Why? A giant button wall is confusing!
AutoMCP is the helpful robot that reads each service’s instruction manual. It learns where the service lives, how login works, and what information each button needs. If the manual has mistakes, it repairs them before building the buttons. Normal building worked 76% of the time; after repair it worked 94.2%, and the button list became about one-third smaller.
But smaller is not automatically smarter. Hide an important button and the AI may fail a mission. The study mostly checks whether tools can be built and called, not whether an AI wins more real tasks. The next level is testing these menus in actual game-like missions and comparing which organization helps most!
Glossary
Model Context Protocol (MCP)
A standard interface for discovering and invoking external tools from LLM applications. It uses structured schemas and JSON-RPC-style messages.
The target protocol whose server-construction process is studied.
REST API
An HTTP-based service interface organized around resources, paths, and operations. A vendor API may expose hundreds of such operations.
The principal backend wrapped by MCP servers.
OpenAPI Specification
A machine-readable contract describing paths, parameters, request bodies, responses, authentication, and servers. It can serve as input to code and tool generation.
The central input to AutoMCP.
Bare API Wrapper
A tool implementation that mainly converts arguments and delegates to an underlying API without substantial semantic orchestration. It often preserves API names, types, and enumerations.
The dominant pattern found in 92% of tools.
Specification Repair
The detection and correction of missing, inconsistent, or structurally problematic API-contract information. Repair aims to make generated tools executable and faithful.
The step that raises success from 76% to 94.2%.
Tool-set Transformation
Changing the tool catalog by filtering operations or grouping related capabilities. The purpose is to reduce selection and context complexity.
The mechanism reducing median tool counts by one-third.
Open Questions Unanswered questions from this research
- 1 Whether filtering and regrouping reliably improve planning and completion on API-Bank- or T-Eval-style tasks remains untested directly.
- 2 It is unclear whether private, rapidly changing, or high-privilege enterprise APIs follow the same 19% exposure pattern as public mature projects.
- 3 Repair may alter semantics or security boundaries; independent evaluation is needed for permissions, credential handling, leakage, and recovery from failed calls.
Applications
Immediate Applications
Rapid enterprise API onboarding
Teams with OpenAPI contracts can use AutoMCP to generate MCP servers for CRM, code hosting, monitoring, and data services. The pipeline can reuse servers and securitySchemes declarations, reducing manual authentication and parameter-mapping work.
Agent catalog governance
Platform engineers can filter and regroup tools by read/write behavior, business domain, risk, or usage frequency. They can then publish task-specific catalogs that reduce context consumption and incorrect tool selection.
Long-term Vision
Specification-driven agent infrastructure
OpenAPI could become the source of truth for synchronized agent interfaces: contract changes would update servers, permissions, and tool catalogs automatically. Major obstacles include version drift, security review, semantic grouping, and safe handling of dynamic APIs.
Abstract
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.