Mcp service conversion system and method for inventory applications

Abstract

This invention discloses an MCP service conversion system and method for existing applications. The system includes an input layer and a protocol adaptation layer. The input layer is used to obtain the interface description information of the target existing application system and receive communication session connection requests from MCP clients. The protocol adaptation layer includes a parsing module, a protocol proxy module, and an API proxy module. The parsing module parses the interface description information to generate a tool definition list conforming to the MCP specification. The protocol proxy module generates standardized calls to the target existing application system based on the tool definition list and the communication session context information of the MCP client. The API proxy module executes the standardized calls and forwards them to the target existing application system. Using this invention can improve the efficiency and scalability of converting existing applications to MCP services.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to an MCP service conversion system and method for existing applications. Background Technology

[0002] To address the issue of large models being unable to obtain real-time information, Function Call technology emerged. This technology establishes a communication channel between large models and external Application Programming Interfaces (APIs), enabling large models to obtain the dynamic data they need by calling external real-time APIs. For example, a large model can call a real-time weather API to obtain the real-time temperature of a target area and provide feedback to the user. However, Function Call technology only implements a basic connection between the model and the API interface; it does not standardize the interface calling process. API interfaces on different platforms differ significantly in implementation methods, parameter definitions, and calling specifications. This leads to significant development difficulties and a chaotic workflow when developing tool calling modules based on Function Call.

[0003] To eliminate the fragmentation problem in adapting large models with external tools, the Model Context Protocol (MCP) was proposed. This protocol establishes cross-platform interaction guidelines for models and tools by defining unified tool description specifications, parameter definition standards, and access control mechanisms. It ensures that different large models use the same format when calling the same tool, and that different tools follow consistent specifications when called, achieving a highly efficient "develop once, compatible across multiple platforms" development model and significantly improving the adaptation efficiency of large models with external tools. However, MCP service development has a high technical threshold, and migrating existing application systems to the MCP ecosystem is difficult. Furthermore, there is a lack of effective means for the large-scale integration of massive amounts of existing APIs.

[0004] To address these technical challenges, various existing technologies have proposed solutions for converting RESTful APIs into MCP services. RESTful is a Web API interface specification designed based on the REST (Representational State Transfer) architectural style. Implementation solutions primarily include manual coding methods based on the Spring AI framework and automated development methods based on intelligent agents. Among these, Chinese patent CN120085839A proposes a method for developing MCP services using the computing power of an intelligent computing center. This method first collects the interface information of the target application programming interface (API), analyzes the interface content to be developed, then generates coding tasks based on the interface information using an intelligent agent, and finally generates the corresponding MCP service components through the intelligent agent. The MCP service components are then registered with the intelligent computing center. While this technical solution has achieved automated development of MCP services to some extent, it relies on the computing power of intelligent computing centers. The core of the method is to complete the coding development of MCP services through intelligent agents. In essence, it is still a new development model for MCP services. It does not achieve a direct and rapid conversion of existing application RESTful APIs to MCP services. Moreover, the intelligent agent coding development process still suffers from long development cycles and low adaptation efficiency, which cannot meet the actual needs of existing application systems to convert to MCP services at low cost and in a standardized manner. Summary of the Invention

[0005] The purpose of this invention is to provide an MCP service conversion system and method for existing applications, reduce the development and transformation costs of migrating existing applications to the MCP ecosystem, and improve the efficiency and scalable access capability of converting existing RESTful APIs to MCP services.

[0006] To achieve the above objectives, this invention provides an MCP service conversion system for existing applications, comprising: The input layer is used to obtain the interface description information of the target existing application system and to receive communication session connection requests from the MCP client. Protocol adaptation layer, including: The parsing module is used to parse the interface description information and generate a tool definition list that conforms to the MCP specification; The protocol proxy module is used to generate standardized calls to the target existing application system based on the tool definition list and the communication session context information of the MCP client. The API proxy module is used to execute the standardized call and forward the standardized call to the target existing application system.

[0007] Optionally, the parsing module is used for: The interface description information is parsed into a structured data model corresponding to the interface description specification of the target existing application system; Based on the structured data model, identify and extract each interface endpoint of the target existing application system and the corresponding call constraint information of the interface endpoint; Based on the call constraint information, a tool definition conforming to the MCP specification is generated for each interface endpoint, resulting in a list of tool definitions conforming to the MCP specification.

[0008] Optionally, the protocol proxy module is used for: Establish a communication session with the MCP client according to the communication session connection request, and assign a unique identifier to each communication session; Create a corresponding MCP service instance based on the unique session identifier; Based on the tool definition list, obtain the API method metadata corresponding to the MCP service instance; Based on the context information of the communication session and the API method metadata, a standardized call to the target existing application system is generated.

[0009] Optionally, the parsing module is further configured to: Based on the type of AI agent framework associated with the MCP client, the parsing method and parameter encapsulation format of the communication session context information are adjusted to generate standardized calls that conform to the specifications of the corresponding AI agent framework.

[0010] Optionally, the input layer includes a canonical conversion module for: The interface description information is standardized and converted into a specification document that conforms to the predetermined interface description according to preset mapping rules.

[0011] Optionally, it also includes: The storage layer is used to store the list of tool definitions generated by the parsing module.

[0012] Optionally, the storage layer further includes a caching module for: The response results of the target existing application system to the standardized call are cached.

[0013] Optionally, before generating a standardized call to the target existing application system, the protocol proxy module further includes: Check if a matching standardized call response result exists in the cache module; If so, return the standardized call response result; If not, the standardized call response result will be stored in the cache module after the API proxy module executes the standardized call.

[0014] Optionally, the input layer includes: The basic data acquisition module is used to acquire the interface description information of the target existing application system. The network request module is used to initiate a network request based on the remote address to obtain the corresponding interface description file when the interface description information obtained by the basic data acquisition module is a remote address, and return the obtained interface description file to the basic data acquisition module. The MCP gateway module is used to receive and maintain communication session connection requests from the MCP client based on the server sending event protocol.

[0015] To achieve the above objectives, the present invention also provides a method for converting existing applications' MCP services, comprising: Obtain the interface description information of the target existing application system and receive communication session connection requests from the MCP client; The interface description information is parsed to generate a tool definition list that conforms to the MCP specification; Based on the tool definition list and the communication session context information of the MCP client, a standardized call to the target existing application system is generated; Execute the standardized call and forward the standardized call to the target existing application system.

[0016] Compared to existing technologies, this invention provides an MCP service conversion system and method for existing applications. This system constructs a layered architecture of "input layer - protocol adaptation layer." The input layer uniformly obtains interface description information from existing application systems and receives MCP client connections. The parsing module in the protocol adaptation layer automatically parses the interface description information to generate a tool definition list conforming to the MCP specification, achieving zero-coding, automated conversion from existing APIs to MCP tools. Simultaneously, the protocol proxy module dynamically generates standardized calls based on the tool definition list and session context. The API proxy module forwards these calls to the target existing system, thus providing MCP clients with directly callable MCP service interfaces without modifying any code in the existing system. This invention abandons the indirect conversion mode of traditional "manual coding adaptation" or "intelligent agent simulation development", and directly bridges the semantic gap between existing RESTful APIs and the MCP protocol. It can reduce the development and transformation costs of existing applications migrating to the MCP ecosystem, improve the efficiency and scalable access capability of converting existing RESTful APIs to MCP services, realize standardized and normalized calls of MCP clients to existing application systems, and effectively enhance the interaction and adaptation capabilities of large models, AI agent frameworks and existing application systems. Attached Figure Description

[0017] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a structural block diagram of an MCP service conversion system for existing applications provided in an embodiment of the present invention; Figure 2 This is another structural block diagram of an MCP service conversion system for existing applications provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the interaction process of each module of an MCP service conversion system for existing applications provided in an embodiment of the present invention; Figure 4 This is a flowchart illustrating a method for converting existing applications using MCP services, as provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] See Figure 1 , Figure 1 This is a structural block diagram of an MCP service conversion system for existing applications provided in an embodiment of the present invention. The MCP service conversion system for existing applications includes an input layer 1 and a protocol adaptation layer 2. The input layer 1 is used to obtain the interface description information of the target existing application system and to receive communication session connection requests from the MCP client. For example, the input layer, acting as the boundary between the system and the external environment, is responsible for receiving external requests, collecting existing interface basic data, and obtaining interface description information of the target existing application system through remote requests. The interface description information can be a local OpenAPI specification file (JSON / YAML format) or a network address (URL) pointing to a remote description file. Simultaneously, the input layer also interfaces with MCP clients to receive and maintain communication session connection requests from MCP clients (such as AI agents, IDE plugins integrating MCP, etc.). Preferably, a server-sent events (SSE) protocol is used to establish and maintain a bidirectional long-lived connection with the client.

[0021] The protocol adaptation layer 2 includes: Parsing module 21 is used to parse the interface description information and generate a tool definition list that conforms to the MCP specification; Protocol proxy module 22 is used to generate standardized calls to the target existing application system based on the tool definition list and the communication session context information of the MCP client; API proxy module 23 is used to execute the standardized call and forward the standardized call to the target existing application system.

[0022] It should be noted that the core of this invention lies in building an intermediate protocol adaptation layer. This layer can automatically convert the interface description of the existing system (such as the OpenAPI specification) into a tool defined by the MCP specification, and interact with the MCP client as an MCP server, ultimately acting as a proxy to execute the actual calls to the backend existing application system.

[0023] For example, the parsing module in the protocol adaptation layer is connected to the input layer to parse the interface description information obtained by the input layer. This parsing process extracts metadata such as interface paths, operations, parameters, and security definitions, ultimately generating a tool definition list that conforms to the MCP specification. Each tool definition in this list precisely corresponds to an existing application's API and contains structured information required by the MCP protocol, such as name, description, and parameter schema. This effectively "translates" non-MCP format interface descriptions into a tool list that MCP clients can directly recognize.

[0024] The protocol proxy module interacts with the parsing module and the input layer, serving as the scheduling center for the MCP protocol logic. When a tool call request from an MCP client is received through the input layer, the protocol proxy module searches for a matching definition in the tool definition list based on the tool identifier in the communication session request. Simultaneously, it combines the context of the current session (which may include user intent, historical messages, parameters for large model population, etc.) to instantiate the abstract MCP tool call instruction into a target-specific and parameter-complete API call specification.

[0025] The API proxy module is the execution terminal of the protocol adaptation layer, connected to the protocol proxy module. It receives standardized call instructions generated by the protocol proxy module, transforms them into one or more standard HTTP (Hypertext Transfer Protocol) requests (including constructing the URL, setting request headers, and assembling the request body), and sends the request to the actual RESTful API endpoint of the target existing application system. Subsequently, it receives the response from the backend system, normalizes it, and returns it to the upstream module, thus completing a full proxy call loop.

[0026] In summary, the MCP service conversion system for existing applications provided by this invention constructs a layered architecture of "input layer - protocol adaptation layer". The input layer uniformly obtains the interface description information of the existing application system and receives MCP client connections. The parsing module in the protocol adaptation layer automatically parses the interface description information to generate a tool definition list that conforms to the MCP specification, realizing zero-coding and automated conversion from existing APIs to MCP tools. At the same time, the protocol proxy module dynamically generates standardized calls based on the tool definition list and session context. The API proxy module forwards the calls to the target existing system, thereby providing MCP clients with directly callable MCP service interfaces without modifying any code in the existing system. This invention abandons the traditional indirect conversion mode of "manual coding adaptation" or "intelligent agent simulation development", and directly bridges the semantic gap between existing RESTful APIs and the MCP protocol. It solves the problems of difficulty in migrating existing application systems to the MCP ecosystem, the inability of existing conversion solutions to quickly convert, long development cycles, and low adaptation efficiency. It can reduce the learning cost and manpower investment in MCP service development, realize the transformation cost of existing applications, rapid access and large-scale deployment, thereby improving the integration efficiency of AI agent framework and existing business systems.

[0027] See Figure 2 , Figure 2 This is another structural block diagram of an MCP service conversion system for existing applications provided in an embodiment of the present invention. In an optional embodiment, such as Figure 2 As shown, the input layer 1 includes: The basic data acquisition module 11 is used to acquire the interface description information of the target existing application system; The network request module 12 is used to initiate a network request based on the remote address to obtain the corresponding interface description file when the interface description information obtained by the basic data acquisition module is a remote address, and return the obtained interface description file to the basic data acquisition module. MCP gateway module 13 is used to receive and maintain communication session connection requests from the MCP client based on the server sending event protocol.

[0028] It should be noted that, in the specific implementation process, the basic data acquisition module uses two acquisition methods: local file upload and remote address specification. Local file upload involves users directly uploading the interface description file stored on their local disk to the system through the system's management interface or API. Remote address specification involves users entering a Uniform Resource Locator (URL) pointing to a remote storage location through the system's management interface or API.

[0029] When the interface description information obtained by the basic data acquisition module is a remote address, the basic data acquisition module transmits the remote address and its associated data record identifier to the network request module. Through this design, the network request module can collect heterogeneous, distributed remote interface description resources into the system in a unified and reliable manner.

[0030] In one alternative embodiment, such as Figure 2 As shown, the input layer 1 further includes a standardization conversion module 14, used for: The interface description information is standardized and converted into a specification document that conforms to the predetermined interface description according to preset mapping rules.

[0031] It should be noted that in real-world implementation environments, many existing application systems' interface description documents suffer from outdated specifications, non-standard formats, and dialectal differences. Directly inputting such defective or version-incompatible interface description documents into the parsing module may lead to parsing failures, information loss, or incomplete tool definitions. Therefore, this embodiment introduces a specification conversion module within the input layer to clean and standardize the original interface description information.

[0032] In one optional embodiment, the parsing module 21 is configured to: The interface description information is parsed into a structured data model corresponding to the interface description specification of the target existing application system; Based on the structured data model, identify and extract each interface endpoint of the target existing application system and the corresponding call constraint information of the interface endpoint; Based on the call constraint information, a tool definition conforming to the MCP specification is generated for each interface endpoint, forming a tool definition list.

[0033] Specifically, the parsing module first obtains the interface description information passed from the input layer. This interface description information is the API interface specification published by the target existing application system, usually existing in the form of a text file, with common formats including but not limited to JSON or YAML. This interface description information follows a specific interface description specification, such as, but not limited to, the OpenAPI specification, RAML, API Blueprint, or other custom interface description languages. In this embodiment of the invention, corresponding parsing rules and data structure definitions are pre-defined for different specification types, enabling the parsing module to identify the specification type and version followed by the interface description information. Then, the semi-structured or unstructured raw interface description text is converted into a structured, traversable, and queryable data model instance in memory according to the predefined data structure mapping rules.

[0034] The structured data model in this embodiment of the invention is a complete object-oriented representation of the original interface description information, and its data structure design follows the meta-model definition of the target interface description specification itself. Taking the OpenAPI specification as an example, this structured data model may include global information objects, a set of path objects, operation objects, a set of parameter objects, request body objects, a set of response objects, a set of component objects, etc.

[0035] After constructing the structured data model, the parsing module performs a deep traversal and semantic analysis on the model. Specifically, the parsing module identifies each path item by traversing the path set in the structured data model. For each path item, it further traverses its supported HTTP method operations. Each "path + method" combination corresponds to an independent interface endpoint. For each identified interface endpoint, the parsing module extracts its call constraint information. This call constraint information includes at least the calling method, parameter definitions, and data structure characteristics.

[0036] After traversing all identified interface endpoints and obtaining complete call constraint information for each endpoint, the parsing module performs the aforementioned mapping and encapsulation operations for each endpoint, generating a complete tool definition that can be directly recognized and invoked by the MCP client. The collection of all tool definitions constitutes a tool definition list conforming to the MCP specification.

[0037] Compared to existing technologies, the complete conversion process from the original interface description document to the MCP tool definition in this invention requires no manual intervention and eliminates the need to write adapter code for each existing application, thereby reducing the technical threshold and manpower costs for existing systems to access the MCP ecosystem. By constructing a structured data model and extracting call constraint information in a refined manner, all technical details of the original API interface can be completely preserved, avoiding tool functionality defects caused by information loss. By pre-setting parsing and mapping rules for multiple interface description specifications, it can flexibly adapt to input sources of different specification formats, and is not limited to a single specification version or type, possessing good versatility and scalability.

[0038] In one optional embodiment, the protocol proxy module 22 is configured to: Establish a communication session with the MCP client according to the communication session connection request, and assign a unique identifier to each communication session; Create a corresponding MCP service instance based on the unique session identifier; Based on the tool definition list, obtain the API method metadata corresponding to the MCP service instance; Based on the context information of the communication session and the API method metadata, a standardized call request for the target existing application system is generated.

[0039] Specifically, when an MCP client needs to call the MCP service provided by the system, it first initiates a communication session connection request through the MCP gateway module in the input layer. The protocol proxy module listens for connection request events received by the MCP gateway module in real time. When a new client connection is detected, the protocol proxy module immediately assigns a globally unique session identifier (Session ID) to that connection. This unique identifier is the index key for all subsequent session-related operations, used to distinguish between different clients, different threads, and even multiple independent connections from the same client. At the same time, the protocol proxy module maintains a session context storage structure in memory, using the session identifier as the key to store all state information related to that session. By assigning a unique identifier to each session and maintaining an independent context storage, isolation and concurrent processing capabilities for multiple clients and sessions can be achieved, avoiding state pollution and resource contention between different user requests.

[0040] After completing session establishment and identifier allocation, the protocol proxy module dynamically and on-demand creates MCP service instances based on the unique session identifier generated. Each MCP service instance is bound to the corresponding client session throughout its lifecycle; it is created when the session is established and reclaimed when the session is destroyed. After the MCP service instance is created, it needs to know which callable tools it can provide externally, as well as the backend API call details for each tool. First, the interface identifier is determined. When the MCP service instance is created, in addition to binding the session identifier, it also obtains a unique interface identifier for the target existing application system. Second, the tool definition list is queried. Based on the aforementioned interface identifier, the protocol proxy module obtains a complete list of tool definitions corresponding to that identifier. Finally, API method metadata is extracted. The protocol proxy module traverses the tool definition list, extracts and caches the corresponding API method metadata for each tool definition, completing the preloading and caching of tool semantics and call details.

[0041] When an MCP client initiates a tool invocation request, it performs a match in the tool definition list cached by the current MCP service instance based on the tool name in the request. This locates the corresponding tool definition and its associated API method metadata. Then, it reads supplementary context information related to the invocation request from the current session's context storage structure. The actual parameter values ​​carried in the request are then merged and deduplicated with the supplementary parameter values ​​in the context information to form a complete parameter set. Subsequently, parameter binding is completed according to the parameter mapping rules in the API method metadata, thereby generating a complete, standardized invocation request description that can be directly executed by an HTTP client.

[0042] It is worth noting that, by assigning a unique identifier to each client session and creating an independent MCP service instance, this embodiment of the invention can solve the problems of state confusion and resource contention in multi-user, multi-threaded concurrent scenarios. By preloading API method metadata and dynamically binding parameters in combination with runtime context information, this process does not require manual intervention, has high call accuracy, and fully preserves the parameter semantics and data structure constraints of the original interface, thus completing a precise semantic mapping from AI intent to API call.

[0043] In an optional embodiment, the parsing module 21 is further configured to: Based on the type of AI agent framework associated with the MCP client, the parsing method and parameter encapsulation format of the communication session context information are adjusted to generate standardized calls that conform to the specifications of the corresponding AI agent framework.

[0044] For example, when the client is detected as the LangChaiAI proxy framework, framework-specific metadata is extracted from the extended fields of the protocol interface parameters in the request; when the client is detected as the LlamaIndex proxy framework, custom parameters are parsed from the extra_info property (an optional custom extended property in the tool_call object) of the tool_call object (the core data object that triggers external tool calls from large models).

[0045] It is worth noting that this dynamic adaptation mechanism enables the system to seamlessly connect with various mainstream AI agent frameworks without the need to develop separate adaptation services for each framework, thereby further improving the system's versatility and ecosystem compatibility.

[0046] In one alternative embodiment, such as Figure 2 As shown, the MCP service conversion system for existing applications also includes a storage layer 3, which includes a persistent storage module 31 for: Store the list of tool definitions generated by the parsing module.

[0047] For example, after the parsing module completes the parsing of the interface description information of the target existing application system and successfully generates a tool definition list conforming to the MCP specification, it can push the tool definition list and its associated metadata to the persistent storage module for storage. When the protocol proxy module responds to the connection request of the MCP client and needs to load the tool definition list of a specific existing application system, it can send a query request to the persistent storage module to obtain the corresponding serialized data.

[0048] In solutions without persistent storage, the original interface description file must be read again and the specification conversion and parsing generation process must be re-executed every time the system restarts or a new MCP client connects, resulting in wasted CPU and memory resources and high service startup latency. This embodiment persists the tool definition list, enabling the protocol proxy module to quickly load the generated tool definitions, thereby improving system startup speed and response efficiency.

[0049] In one alternative embodiment, such as Figure 2 As shown, the storage layer 3 further includes a cache module 32, used for: The response results of the target existing application system to the standardized call are cached.

[0050] This invention introduces a caching module inside the storage layer, which enables temporary storage and rapid reuse of high-frequency, repetitive standardized call response results.

[0051] In one optional embodiment, before generating a standardized call to the target existing application system, the protocol proxy module further includes: Check if a matching standardized call response result exists in the cache module; If so, return the standardized call response result; If not, the standardized call response result will be stored in the cache module after the API proxy module executes the standardized call.

[0052] For example, after receiving the response from the caching module, the protocol proxy module does not need to call the API proxy module. It can directly encapsulate the result into a tool call response according to the MCP protocol specification and push it to the MCP client through the MCP gateway module. If the cache is not hit, the protocol proxy module will send the standardized call instruction to the API proxy module normally. The API proxy module will return the response result to the protocol proxy module. While forwarding the response result to the MCP client, the protocol proxy module asynchronously triggers the cache to cache the response result of the standardized call. In the future, call requests with the same characteristics will directly hit the cache, thereby improving the response time.

[0053] To enable those skilled in the art to clearly understand the specific implementation process of the present invention, the following example illustrates the specific implementation process of the present invention by automatically converting the OpenAPI 2.0 specification to the standard OpenAPI 3.0 specification, and parsing any HTTP interface based on the standardized OpenAPI 3.0 specification to quickly generate an adapter conforming to the MCP protocol specification.

[0054] See Figure 3 , Figure 3 This is a schematic diagram illustrating the interaction flow of various modules in an MCP service conversion system for existing applications provided in an embodiment of the present invention. Figure 3 As shown, First, the interface description information of the target existing application system is filled in the basic data acquisition module 11. There are two ways to fill it in: an interface description information file (such as a YAML or JSON file in OpenAPI 2.0 or OpenAPI 3.0 format) or a remote file address. If a remote file address is filled in the basic data acquisition module 11, the remote file content is obtained through the network request module 12. Whether the content is a local JSON file or obtained from a remote file via network request, it may contain non-standard or non-compliant content, which will affect subsequent parsing. Therefore, the file needs to be input into the specification conversion module 14 for verification and conversion to obtain an accurate and parsable standard OpenAPI 3.0 specification file.

[0055] The specification conversion module 14 first detects the OpenAPI specification version using the keywords "swagger" or "openapi". If it is OpenAPI 2.0, it needs to be converted to the more compatible OpenAPI 3.0 specification through rule mapping. This process includes extracting and normalizing key fields such as path, operation, parameter, and security. To ensure consistency in the interface description, deserialization and mapping methods can be used to unify the interface definitions in the original interface into a format conforming to the OpenAPI 3.0 specification, resulting in a deserialized specification document.

[0056] Specifically, first, data classes are defined according to the OpenAPI official documentation. The interface description document content is deserialized into data instances, and then converted to OpenAPI 3.0 through field mapping. For example, in 2.0, `Api` is mapped to `Tag`, `ApiOperation` to `Operation`, and `ApiImplicitParam` to `Parameter`. Furthermore, parameter formats can be standardized, including mapping `in` fields and type validation and conversion of `schema` fields. For instance, in OpenAPI 2.0, the `type` field only supports basic types (such as `string`, `integer`, etc.), while OpenAPI 3.0 introduces `schema` objects to support more complex type definitions, such as combined types like `oneOf` and `allOf`. Therefore, during protocol conversion, the `type` field in OpenAPI 2.0 can be mapped to the `schema.type` field, with attributes such as `description` and `format` added as needed. In terms of security mechanisms, OpenAPI 2.0 uses `securityDefinitions` to define authentication methods, while OpenAPI 3.0 replaces it with `components.securitySchemes` and supports more flexible authentication configuration. By building a mapping table, each entry in `securityDefinitions` can be converted into a corresponding item under `components.securitySchemes`, and the `security` field reference at the interface level can be updated.

[0057] Furthermore, the obtained specification document is deserialized and input into the parsing module 21, which parses the interface information conforming to the OpenAPI 3.0 specification into a method list conforming to the MCP protocol specification.

[0058] The specific parsing process is as follows: First, a structure model strictly corresponding to the OpenAPI 3.0 specification is defined. The input specification document is deserialized into an instance of this structure, forming a structured data model in memory. During the parsing process, $ref references need to be handled, and component definitions such as schemas and parameters are recursively parsed and inlined to the corresponding positions to ensure the integrity of the data model. At the same time, the accurate parsing of various parameters and request bodies is completed. Path parameters are identified through a dual matching method: first, path templates such as / users / {id} are parsed to extract the parameter names within curly braces, and then the parameter definition with the In field being path and matching name is searched in the Parameters list of the corresponding operation, while verifying its required attribute and schema type constraint; query parameters are directly obtained by filtering parameters with the In field being query; the request body is identified by parsing RequestBody.Content[mediaType].Schema, and nested object attributes when type is object and array type attributes corresponding to items are recursively processed to completely parse complex data structures.

[0059] After completing all the above parsing operations, a corresponding MCP tool definition list is generated for each API endpoint based on this structured data model. The core advantage of this parsing method is that it achieves end-to-end automated conversion from the OpenAPI specification to the MCP protocol. It can generate tool definitions that conform to the MCP protocol specification without manual intervention. It fully preserves the parameter semantics (type, constraints, location), HTTP features (request methods, status code handling), and support for complex structures (nested objects, arrays) of the original API, while ensuring the accuracy of the specification document through reference resolution. This significantly improves the integration efficiency and reliability of the large language model and the RESTful API system.

[0060] Furthermore, the tool definition list that conforms to the MCP protocol specification obtained from the above parsing is stored in the persistent storage module 31 to provide data support for subsequent MCP service calls; the persistent storage module can use MySQL or other mainstream repositories as data storage carriers.

[0061] Then, configure a dedicated touchpoint connection for the parsed and stored tool definition list, for example, http: / / localhost:8989 / sse?id=234567, where the suffix id corresponding to 234567 is the unique identifier of the tool list in the persistent storage module 31.

[0062] The contact connection is provided to the MCP client. The client initiates a request based on the SSE protocol. The request will first enter the MCP gateway module 13. The MCP gateway module 13 will store the request content in memory and assign a unique sessionid as an access identifier for each SSE connection. After the identifier is completed, the request context content is forwarded to the protocol proxy module 22.

[0063] The protocol proxy module 22 creates a dedicated MCP service based on the session ID. When the service is created, it obtains the corresponding RESTful API method content from the parsing module 21 through the unique identifier in the persistent storage module. This content includes core information such as the method call address, request method (GET / POST / PUT / DELETE, etc.), and request parameter names. Then, it extracts the actual request parameter content and forms a parameter signature based on the request context. It can also automatically generate corresponding context parameters according to the adaptation requirements of different AI proxy frameworks such as LangChain and LlamaIndex, and encapsulate them into a standard MCP context object for large models to call. For example, when a large model calls the user registration interface, it can generate parameters such as username and password based on the current context and complete the above encapsulation.

[0064] After completing the parameter processing described above, the system forwards the request to the caching module 32 for verification, checking whether the request is a duplicate request or a request with an existing cached result. If the cache is hit, the result will be retrieved directly from the cache and returned to the MCP client. If the cache is not hit, the request will enter the API proxy module 23.

[0065] The API proxy module 23 parses the request context and initiates a remote call based on the parsed target existing application system RESTful API information. The call address of the RESTful API has been collected in the basic data collection module 11. After the remote call is completed, the system stores the call result in the cache module 32 and then returns the result to the MCP client.

[0066] In summary, this invention automatically converts the OpenAPI 2.0 specification to OpenAPI 3.0. By parsing the OpenAPI 3.0 specification, any HTTP interface is quickly converted into an adapter conforming to the Model Context Protocol (MCP), enabling seamless integration with large models without requiring any modifications to existing APIs. It is also compatible with existing RESTful application interfaces, significantly improving adaptation efficiency. Through complete parsing of OpenAPI 3.0, it ensures that all API functions and features can be completely and accurately converted and used. Following the MCP specification, it has compatibility with various large models and AI proxy frameworks.

[0067] See Figure 4 , Figure 4 This is a flowchart of an MCP service conversion method for existing applications provided in an embodiment of the present invention. Figure 4 As shown, the MCP service conversion method for existing applications includes steps S1 to S4: Step S1: Obtain the interface description information of the target existing application system and receive the communication session connection request from the MCP client; Step S2: Parse the interface description information to generate a tool definition list that conforms to the MCP specification; Step S3: Generate a standardized call to the target existing application system based on the tool definition list and the communication session context information of the MCP client; Step S4: Execute the standardized call and forward the standardized call to the target existing application system.

[0068] In one optional embodiment, step S2 includes: The interface description information is parsed into a structured data model corresponding to the interface description specification of the target existing application system; Based on the structured data model, identify and extract each interface endpoint of the target existing application system and the corresponding call constraint information of the interface endpoint; Based on the call constraint information, a tool definition conforming to the MCP specification is generated for each interface endpoint, resulting in a list of tool definitions conforming to the MCP specification.

[0069] In one optional embodiment, step S3 includes: Establish a communication session with the MCP client according to the communication session connection request, and assign a unique identifier to each communication session; Create a corresponding MCP service instance based on the unique session identifier; Based on the tool definition list, obtain the API method metadata corresponding to the MCP service instance; Based on the context information of the communication session and the API method metadata, a standardized call to the target existing application system is generated.

[0070] It should be noted that the MCP service conversion method for existing applications provided in this embodiment of the invention is applied to the MCP service conversion system for existing applications in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0071] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A system for converting existing applications' MCP services, characterized in that, include: The input layer is used to obtain the interface description information of the target existing application system and to receive communication session connection requests from the MCP client. Protocol adaptation layer, including: The parsing module is used to parse the interface description information and generate a tool definition list that conforms to the MCP specification; The protocol proxy module is used to generate standardized calls to the target existing application system based on the tool definition list and the communication session context information of the MCP client. The API proxy module is used to execute the standardized call and forward the standardized call to the target existing application system.

2. The MCP service conversion system for existing applications as described in claim 1, characterized in that, The parsing module is used for: The interface description information is parsed into a structured data model corresponding to the interface description specification of the target existing application system; Based on the structured data model, identify and extract each interface endpoint of the target existing application system and the corresponding call constraint information of the interface endpoint; Based on the call constraint information, a tool definition conforming to the MCP specification is generated for each interface endpoint, resulting in a list of tool definitions conforming to the MCP specification.

3. The MCP service conversion system for existing applications as described in claim 1, characterized in that, The protocol proxy module is used for: Establish a communication session with the MCP client according to the communication session connection request, and assign a unique identifier to each communication session; Create a corresponding MCP service instance based on the unique session identifier; Based on the tool definition list, obtain the API method metadata corresponding to the MCP service instance; Based on the context information of the communication session and the API method metadata, a standardized call to the target existing application system is generated.

4. The MCP service conversion system for existing applications as described in claim 3, characterized in that, The parsing module is also used for: Based on the type of AI agent framework associated with the MCP client, the parsing method and parameter encapsulation format of the communication session context information are adjusted to generate standardized calls that conform to the specifications of the corresponding AI agent framework.

5. The MCP service conversion system for existing applications as described in claim 1, characterized in that, The input layer includes a normalization conversion module, used for: The interface description information is standardized and converted into a specification document that conforms to the predetermined interface description according to preset mapping rules.

6. The MCP service conversion system for existing applications as described in claim 1, characterized in that, Also includes: The storage layer is used to store the list of tool definitions generated by the parsing module.

7. The MCP service conversion system for existing applications as described in claim 6, characterized in that, The storage layer also includes a caching module for: The response results of the target existing application system to the standardized call are cached.

8. The MCP service conversion system for existing applications as described in claim 7, characterized in that, Before generating a standardized call to the target existing application system, the protocol proxy module further includes: Check if a matching standardized call response result exists in the cache module; If so, return the standardized call response result; If not, the standardized call response result will be stored in the cache module after the API proxy module executes the standardized call.

9. The MCP service conversion system for existing applications as described in claim 1, characterized in that, The input layer includes: The basic data acquisition module is used to acquire the interface description information of the target existing application system. The network request module is used to initiate a network request based on the remote address to obtain the corresponding interface description file when the interface description information obtained by the basic data acquisition module is a remote address, and return the obtained interface description file to the basic data acquisition module. The MCP gateway module is used to receive and maintain communication session connection requests from the MCP client based on the server sending event protocol.

10. A method for converting existing applications' MCP services, characterized in that, include: Obtain the interface description information of the target existing application system and receive communication session connection requests from the MCP client; The interface description information is parsed to generate a tool definition list that conforms to the MCP specification; Based on the tool definition list and the communication session context information of the MCP client, a standardized call to the target existing application system is generated; Execute the standardized call and forward the standardized call to the target existing application system.

Images