Method, system, medium, and device for dynamically building mcp services based on openapi

Abstract

This invention discloses a method, system, medium, and device for dynamically constructing MCP services based on OpenAPI. The system includes: a dynamic mapping module for loading and parsing the OpenAPI description file at runtime, and constructing a dynamic operation graph in memory based on the parsed API metadata; a session management module for reconstructing and maintaining a virtual session context on the server side when a request to establish an SSE long connection is received, through a dual-channel negotiation mechanism that extracts the session identifier from the HTTP request header and the URL query string; and an execution proxy module for receiving LLM tool call requests in the virtual session context, interpreting them according to the dynamic operation graph into target HTTP requests conforming to the OpenAPI description, sending them to the business system, and encapsulating and returning the response. This invention achieves dynamic and real-time adaptation of API interfaces, solving the lag problem of static compilation schemes.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence middleware and heterogeneous system integration technology, specifically to a method, system, medium, and device for dynamically building MCP services based on OpenAPI. Background Technology

[0002] With the rise of Agentic AI, Large Models (LLMs) have evolved from simple text generation to tool calling, which executes complex business logic. To connect models with external business systems, existing industry solutions primarily exhibit a trend towards "discretization" and "staticization," specifically including:

[0003] Hard-coding solutions based on static compilation: such as Swagger Codegen, LangChain Toolkits, or OpenAPI Generator. The core process of these solutions is compile-time binding, meaning that developers need to take the OpenAPI documentation as input during the development phase and use a code generator to convert it into a static client code library. Each business system's interface needs to generate a separate set of code and package it into the application. This solution suffers from the "lag" in interface evolution and high maintenance costs: when the business API changes, the static code immediately becomes invalid, causing the AI ​​application to be unable to achieve "hot-swap" of business capabilities, and the code must be regenerated, compiled, and deployed.

[0004] Discrete Standard MCP Service Architecture: While Anthropic's Model Context Protocol (MCP) standardizes the communication protocol between models and tools, its current ecosystem mainly consists of independent services with single functions. When enterprises connect to multiple complex internal business systems, they typically adopt a "one system, one service" deployment model, which results in high deployment and management costs and a lack of unified dynamic build capabilities.

[0005] Furthermore, in cloud-native complex network environments (such as Kubernetes), the SSE (Server-Sent Events) long-lived connections relied upon by the MCP protocol face severe challenges. When requests pass through multiple layers of load balancers, the header information used to maintain the session (such as mcp-session-id) is often stripped or lost by the middleware, leading to frequent session interruptions and severely impacting service availability and stability.

[0006] Therefore, there is an urgent need for a technical solution that can dynamically parse OpenAPI, generate MCP services in real time, and effectively cope with complex network environments and ensure session continuity. Summary of the Invention

[0007] Therefore, a solution is needed to dynamically build MCP services based on OpenAPI, which can solve the problem of how to generate MCP tool definitions in real time based on OpenAPI description files without recompiling the code, and achieve highly available streaming session persistence in complex network environments, so as to solve the technical problems of lagging interface evolution, fragile sessions and poor robustness of heterogeneous parameter processing in existing technologies.

[0008] To achieve the above objectives, in a first aspect, this application provides a system for dynamically constructing MCP services based on OpenAPI, the system comprising:

[0009] The dynamic mapping module is used to load and parse the OpenAPI description file at runtime, build a dynamic operation graph in memory based on the parsed API metadata, generate MCP tool definitions based on the dynamic operation graph, and provide the MCP tool definitions to the client large language model LLM.

[0010] The dynamic operation graph includes tool metadata generated from API function descriptions, isomorphic parameter contracts formed by mapping and integrating API path parameters, query parameters, request header parameters and request body parameters, and execution mapping logic for restoring MCP tool call requests to HTTP requests.

[0011] The session management module, connected to the dynamic mapping module, is used to obtain a session identifier through a dual-channel negotiation mechanism when it receives a request from the LLM's establishment server to send an event SSE long connection. The dual channels include a standard header channel extracted from the HTTP request header and an out-of-band anchor channel extracted from the URL query string. The module also reconstructs and maintains the virtual session context for the obtained session identifier on the server side.

[0012] The execution proxy module, connected to both the dynamic mapping module and the session management module, is used to receive tool invocation requests from the LLM based on the MCP tool definition within the virtual session context. It then translates the tool invocation requests into target HTTP requests conforming to the OpenAPI description according to the execution mapping logic in the dynamic operation graph, sends the target HTTP requests to the corresponding business system, and encapsulates the business system's response into a tool invocation result object conforming to the MCP protocol standard, returning it to the LLM.

[0013] Furthermore, the dynamic mapping module includes:

[0014] The loading and parsing unit is used to read and parse the OpenAPI specification file when the system starts up or receives a hot update instruction, traverse the paths and component nodes in it, and extract the API's metadata.

[0015] The graph construction unit is used to construct the dynamic operation graph in memory based on the metadata;

[0016] The isomorphism mapping unit is used to merge and map the heterogeneous parameters defined in the OpenAPI specification in path parameters, query parameters, request header parameters and request body parameters into a one-dimensional input pattern definition that conforms to a preset structure description specification, so as to form the isomorphism parameter contract.

[0017] Furthermore, the session management module includes:

[0018] The first negotiation unit is used as the standard header channel to extract the session identifier from the HTTP request header for establishing an SSE connection.

[0019] The second negotiation unit is used as the out-of-band anchor channel. When the first negotiation unit fails to extract the session identifier or the HTTP request is redirected, the session identifier is parsed from the URL query string of the HTTP request.

[0020] The context reconstruction unit is used to reconstruct and maintain the corresponding virtual session context in the server memory based on the session identifier extracted by the first negotiation unit or the second negotiation unit.

[0021] Furthermore, the execution agent module includes:

[0022] The multipart request encapsulation unit is used to automatically detect whether the parameter value is a file path according to the homogenization parameter contract in the dynamic operation graph when the media type of the target HTTP request is multipart form data. If it is, the corresponding file content stream is mounted; otherwise, it is encapsulated as a text field.

[0023] The path self-healing unit is used to clean the complete request URL, which is formed by concatenating the base URL and endpoint path recorded in the dynamic operation graph, before sending the target HTTP request, and remove redundant forward slashes and hidden whitespace characters at the concatenation point.

[0024] The result encapsulation unit is used to encapsulate the original HTTP response returned by the business system into an MCP standard invocation tool result object containing content and error status.

[0025] Furthermore, the system also includes:

[0026] The traffic learning and analysis module is connected to the dynamic mapping module and the execution proxy module, respectively.

[0027] The traffic learning and analysis module includes:

[0028] The traffic collection unit is used to anonymously collect the combination of request parameters and response status codes to form runtime traffic data during the process of the execution agent module sending HTTP requests and receiving responses from the business system.

[0029] The contract optimization and discovery unit is used to analyze the runtime traffic data and compare and learn it with the homogeneous parameter contract in the dynamic operation graph.

[0030] The contract optimization and discovery unit is specifically used for:

[0031] Filter the runtime traffic data to identify request samples with response status codes indicating success;

[0032] Statistical analysis of the co-occurrence frequency of different parameters in the successful request samples;

[0033] When the co-occurrence frequency of the first parameter and the second parameter in the successful request samples exceeds the preset confidence threshold, it is determined that there is a dependency constraint relationship between the first parameter and the second parameter.

[0034] The identified dependency constraints are added to the isomorphic parameter contract so that when the LLM calls the tool later, the tool definition generated by the dynamic mapping module can guide the LLM to generate a parameter combination that conforms to the dependency constraints.

[0035] Furthermore, the dynamic mapping module also includes:

[0036] An operation association analysis unit is used to analyze the potential associations between different API operations when constructing the dynamic operation graph. The potential associations include semantic similarity or data structure matching between the output parameters of the first API operation and the input parameters of the second API operation.

[0037] The system also includes a toolset and orchestration engine, which is connected to the dynamic mapping module, the session management module, and the execution agent module, respectively. The toolset and orchestration engine includes:

[0038] The intent parsing and matching unit is used to parse tool call requests from LLM and generate task descriptions; match the task descriptions with the isomorphic parameter contracts of each API operation in the dynamic operation graph; when no single API operation has an isomorphic parameter contract that can satisfy all the input parameter requirements of the task description, it is determined that a tool combination is needed.

[0039] The process generation unit is used to generate an execution sequence containing multiple API operations based on the potential relationships in the dynamic operation graph when it is determined that tool combinations are required. The execution sequence defines the execution order of each API operation and specifies which data from the output parameters of the upstream API operation will be used as the input parameters of the downstream API operation.

[0040] The process execution and context management unit is used to sequentially call the execution proxy module to execute each API operation according to the execution sequence; during the execution process, according to the specified execution sequence, the corresponding data in the response result of the upstream API operation is filled into the corresponding parameters of the homogenization parameter contract of the downstream API operation;

[0041] The result output unit is used to collect the output data obtained by the process execution and context management unit after executing the execution sequence, and encapsulate the output data into a call tool result object conforming to the MCP protocol and return it to the LLM.

[0042] In a second aspect, this application provides a method for dynamically constructing MCP services based on OpenAPI, the method being applicable to the system for dynamically constructing MCP services based on OpenAPI as described in the first aspect of this application, the method comprising:

[0043] The dynamic mapping module loads and parses the OpenAPI description file at runtime, constructs a dynamic operation graph in memory based on the parsed API metadata, generates MCP tool definitions based on the dynamic operation graph, and provides the MCP tool definitions to the client large language model LLM.

[0044] When the session management module receives a request from the LLM's establishment server to send an event SSE long connection, it obtains the session identifier through a dual-channel negotiation mechanism. The dual channels include a standard header channel extracted from the HTTP request header and an out-of-band anchor channel extracted from the URL query string. The virtual session context is reconstructed and maintained on the server side for the obtained session identifier.

[0045] In the virtual session context, the execution agent module receives a tool invocation request from the LLM based on the MCP tool definition, translates the tool invocation request into a target HTTP request that conforms to the OpenAPI description according to the execution mapping logic in the dynamic operation graph, sends the target HTTP request to the corresponding business system, and encapsulates the response of the business system into a tool invocation result object that conforms to the MCP protocol standard and returns it to the LLM.

[0046] Furthermore, the system includes a traffic learning and analysis module, which includes a traffic acquisition unit and a contract optimization and discovery unit;

[0047] The method includes:

[0048] During the process of the execution proxy module sending HTTP requests and receiving responses from the business system, the traffic collection unit anonymously collects the combination of request parameters and response status codes to form runtime traffic data.

[0049] The contract optimization and discovery unit analyzes the runtime traffic data and compares and learns it with the homogenized parameter contracts in the dynamic operation graph, specifically including:

[0050] Filter the runtime traffic data to identify request samples with response status codes indicating success;

[0051] Statistical analysis of the co-occurrence frequency of different parameters in the successful request samples;

[0052] When the co-occurrence frequency of the first parameter and the second parameter in the successful request samples exceeds the preset confidence threshold, it is determined that there is a dependency constraint relationship between the first parameter and the second parameter.

[0053] The identified dependency constraints are added to the isomorphic parameter contract so that when the LLM calls the tool later, the tool definition generated by the dynamic mapping module can guide the LLM to generate a parameter combination that conforms to the dependency constraints.

[0054] In a third aspect, the inventors also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for dynamically constructing MCP services based on OpenAPI as described in the first aspect of the invention.

[0055] In a fourth aspect, the inventors provide an electronic device including a processor and a storage medium storing a computer program that, when executed by the processor, implements the method for dynamically constructing an MCP service based on OpenAPI as described in the first aspect of the invention.

[0056] Unlike existing technologies, the above technical solution describes a method, system, medium, and device for dynamically constructing MCP services based on OpenAPI. The system includes: a dynamic mapping module, used to load and parse the OpenAPI description file at runtime, and construct a dynamic operation graph in memory based on the parsed API metadata; a session management module, used to reconstruct and maintain a virtual session context on the server side when a request to establish an SSE long connection is received, through a dual-channel negotiation mechanism that extracts the session identifier from the HTTP request header and the URL query string; and an execution proxy module, used to receive LLM tool call requests within the virtual session context, translate them into target HTTP requests conforming to the OpenAPI description according to the dynamic operation graph, send them to the business system, and encapsulate and return the response. This invention achieves dynamic and real-time adaptation of API interfaces, solves the lag problem of static compilation schemes, and effectively ensures high session availability in complex network environments through a dual-channel session negotiation mechanism.

[0057] The above description of the invention is merely an overview of the technical solution of this application. In order to enable those skilled in the art to better understand the technical solution of this application and to implement it based on the description and drawings, and to make the above-mentioned objectives and other objectives, features and advantages of this application easier to understand, the following description is provided in conjunction with the specific embodiments and drawings of this application. Attached Figure Description

[0058] The accompanying drawings are only used to illustrate the principles, implementation methods, applications, features, and effects of specific embodiments of this application and other related content, and should not be considered as limitations on this application.

[0059] In the accompanying drawings of the instruction manual:

[0060] Figure 1 This is a schematic diagram of a system for dynamically building MCP services based on OpenAPI, which is an exemplary embodiment of this application.

[0061] Figure 2 This is a schematic diagram of a dynamic mapping module according to an exemplary embodiment of this application;

[0062] Figure 3 This is a schematic diagram of a session management module according to an exemplary embodiment of this application;

[0063] Figure 4 This is a schematic diagram of an execution proxy module according to an exemplary embodiment of this application;

[0064] Figure 5 This is a schematic diagram of a traffic learning and analysis module involved in an exemplary embodiment of this application;

[0065] Figure 6 This is a schematic diagram of a tool combination and orchestration engine involved in an exemplary embodiment of this application;

[0066] Figure 7 A flowchart illustrating a method for dynamically constructing MCP services based on OpenAPI, as shown in an exemplary embodiment of this application;

[0067] Figure 8 A flowchart illustrating a method for dynamically constructing MCP services based on OpenAPI, as described in another exemplary embodiment of this application;

[0068] Figure 9 This is a schematic diagram of an MCP gateway architecture according to an exemplary embodiment of this application;

[0069] Figure 10 A flowchart illustrating parameter isomorphism mapping and MCP protocol adaptation in an exemplary embodiment of this application;

[0070] Figure 11 This is a timing diagram of a stateless handshake in an exemplary embodiment of this application;

[0071] Figure 12 This is a schematic diagram of the modules of an electronic device according to an exemplary embodiment of this application;

[0072] The reference numerals used in the above figures are explained as follows:

[0073] 10. A system for dynamically building MCP services based on OpenAPI;

[0074] 101. Dynamic Mapping Module; 1011. Loading and Parsing Unit; 1012. Graph Construction Unit; 1013. Isomorphic Mapping Unit; 1014. Operation Correlation Analysis Unit;

[0075] 102. Session Management Module; 1021. First Negotiation Unit; 1022. Second Negotiation Unit; 1023. Context Reconstruction Unit;

[0076] 103. Execution Proxy Module; 1031. Multipart Request Encapsulation Unit; 1032. Path Self-Healing Unit; 1033. Result Encapsulation Unit;

[0077] 104. Traffic Learning and Analysis Module; 1041. Traffic Acquisition Unit; 1042. Contract Optimization and Discovery Unit;

[0078] 105. Tool Combination and Orchestration Engine; 1051. Intent Parsing and Matching Unit; 1052. Process Generation Unit; 1053. Process Execution and Context Management Unit; 1054. Result Output Unit;

[0079] 20. Electronic equipment;

[0080] 201. Processor;

[0081] 202. Storage medium. Detailed Implementation

[0082] To illustrate the possible application scenarios, technical principles, implementable specific solutions, and achievable objectives and effects of this application in detail, the following description, in conjunction with the listed specific embodiments and accompanying drawings, provides a detailed explanation. The embodiments described herein are merely illustrative of the technical solutions of this application and are therefore intended to limit the scope of protection of this application.

[0083] In this document, the term "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The term "embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment, nor does it specifically limit its independence or connection with other embodiments. In principle, in this application, as long as there are no technical contradictions or conflicts, the technical features mentioned in each embodiment can be combined in any way to form corresponding implementable technical solutions.

[0084] Unless otherwise defined, the technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the use of related terms herein is merely for the purpose of describing particular embodiments and is not intended to limit this application.

[0085] In the description of this application, the term "and / or" is used to describe the logical relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A exists, B exists, and A and B exist simultaneously. Additionally, the character " / " in this document generally indicates that the preceding and following objects have an "or" logical relationship.

[0086] In this application, terms such as “first” and “second” are used only to distinguish one entity or operation from another, and do not necessarily require or imply any actual quantity, hierarchy or order relationship between these entities or operations.

[0087] Unless otherwise specified, the use of terms such as “comprising,” “including,” “having,” or other similar expressions in this application is intended to cover non-exclusive inclusion, which does not exclude the presence of additional elements in a process, method, or product that includes the stated elements, such that a process, method, or product that includes a list of elements may include not only those defined elements but also other elements not expressly listed, or elements inherent to such a process, method, or product.

[0088] As understood in the Examination Guidelines, in this application, expressions such as "greater than," "less than," and "exceeding" are understood to exclude the stated number; expressions such as "above," "below," and "within" are understood to include the stated number. Furthermore, in the description of the embodiments in this application, "multiple" means two or more (including two), and similar expressions related to "multiple" are also understood in this way, such as "multiple groups" and "multiple times," unless otherwise explicitly specified.

[0089] In the description of the embodiments of this application, the space-related expressions used, such as "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "vertical," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential," indicate the orientation or positional relationship based on the orientation or positional relationship shown in the specific embodiments or drawings. They are only for the purpose of describing the specific embodiments of this application or for the reader's understanding, and do not indicate or imply that the device or component referred to must have a specific position, a specific orientation, or be constructed or operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0090] Unless otherwise expressly specified or limited, the terms "installation," "connection," "linking," "fixing," and "setting," as used in the description of the embodiments of this application, should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral setting; it can be a mechanical connection, an electrical connection, or a communication connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be the internal connection of two components or the interaction between two components. For those skilled in the art to which this application pertains, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0091] like Figure 1 As shown, in a first aspect, this application provides a system 10 for dynamically building MCP services based on OpenAPI, the system comprising:

[0092] The dynamic mapping module 101 is used to load and parse the OpenAPI description file at runtime, construct a dynamic operation graph in memory based on the parsed API metadata, generate MCP tool definitions based on the dynamic operation graph, and provide the MCP tool definitions to the client large language model LLM.

[0093] The dynamic operation graph includes tool metadata generated from API function descriptions, isomorphic parameter contracts formed by mapping and integrating API path parameters, query parameters, request header parameters and request body parameters, and execution mapping logic for restoring MCP tool call requests to HTTP requests.

[0094] The session management module 102, connected to the dynamic mapping module, is used to obtain a session identifier through a dual-channel negotiation mechanism when it receives a request from the LLM's establishment server to send an event SSE long connection. The dual channels include a standard header channel extracted from the HTTP request header and an out-of-band anchor channel extracted from the URL query string. The virtual session context is reconstructed and maintained on the server side for the obtained session identifier.

[0095] The execution proxy module 103 is connected to the dynamic mapping module and the session management module, respectively. It is used to receive tool call requests from the LLM based on the MCP tool definition in the virtual session context, translate the tool call requests into target HTTP requests that conform to the OpenAPI description according to the execution mapping logic in the dynamic operation graph, send the target HTTP requests to the corresponding business system, and encapsulate the response of the business system into a tool call result object that conforms to the MCP protocol standard and return it to the LLM.

[0096] An OpenAPI description file is an interface specification file written in YAML / JSON format. It contains metadata information such as the path of the business system API, request method, parameter definition, data model, and security authentication. It is the core file for implementing standardized interface descriptions.

[0097] Dynamic operation graphs refer to the set of structured API metadata generated by parsing OpenAPI description files at runtime and stored in memory. They are the core mapping basis connecting the MCP protocol and the underlying HTTP interface.

[0098] MCP tool definition refers to the tool calling specification that conforms to the Model Context Protocol standard. It provides the Large Language Model (LLM) with recognizable tool names, function descriptions, parameter formats, and other information, and serves as the direct basis for LLM to call business APIs.

[0099] Homogenized parameter contracts refer to parameter specifications formed by unifying and flattening heterogeneous parameters scattered in API paths, queries, request headers, and request bodies, conforming to the JSON Schema Draft standard.

[0100] SSE long-lived connection refers to a server-sent event long-lived connection, which is a communication method natively relied upon by the MCP protocol, supporting one-way, streaming real-time data transmission from the server to the client.

[0101] Virtual session context refers to the independent memory state space built by the server for each LLM session, used to store information such as session identifier, interaction records, and parameter context, so as to achieve state isolation and precise routing of multiple sessions.

[0102] The CallToolResult object is a response encapsulation object that conforms to the MCP protocol standard. It contains two core fields: content (the response content of the business system) and isError (the error status indicator), providing standardized response results for LLM.

[0103] The system for dynamically building MCP services based on OpenAPI involved in this embodiment includes a dynamic mapping module, a session management module, and an execution proxy module. These modules work together to realize the entire process of dynamic construction and streaming interaction from OpenAPI interface description to LLM-callable MCP tools. The overall implementation steps are divided into the following three core stages:

[0104] First, during the dynamic construction and release phase of the MCP tool, the dynamic mapping module automatically loads and parses the OpenAPI description file when the system starts up or receives a hot update command, extracting API metadata from core nodes such as paths and components. Based on this metadata, a dynamic operation graph is built in memory. Subsequently, the dynamic mapping module generates standardized MCP tool definitions based on the dynamic operation graph and provides these definitions to the client's LLM, enabling the LLM to obtain a list of callable business tools through the standard tools / list commands.

[0105] During the SSE long-connection establishment and session context maintenance phase, when the LLM initiates a request to establish an SSE long-connection, the session management module, connected to the dynamic mapping module, initiates a dual-channel negotiation mechanism to obtain the session identifier: First, it attempts to extract the mcp-session-id from the HTTP request header through the standard header channel; if the header channel fails to extract the session identifier, or if the request is temporarily redirected, it immediately triggers the out-of-band anchor channel to parse the session_id parameter from the URL query string. Regardless of which channel the session identifier is obtained through, the session management module reconstructs and maintains a dedicated virtual session context for that identifier in the server's memory, providing state support and accurate routing basis for subsequent tool call requests.

[0106] Then, during the MCP tool invocation and HTTP request execution phase, the execution proxy module establishes connections with the dynamic mapping module and the session management module, respectively. Within the virtual session context, it receives tool invocation requests initiated by the LLM based on the MCP tool definition. According to the execution mapping logic in the dynamic operation graph, the execution proxy module translates the abstract MCP tool invocation request into a specific HTTP request conforming to the OpenAPI description (including URL concatenation, parameter binding, request method matching, etc.). Subsequently, the target HTTP request is sent to the corresponding business system, and the original response from the business system is received. Finally, the original response is encapsulated into a CallToolResult object conforming to the MCP protocol standard and returned to the LLM through an SSE long connection, completing a complete tool invocation loop.

[0107] With the above solution, developers do not need to write adaptation code. The system automatically completes the construction of the OpenAPI to the MCP tool at runtime, completely abandoning the traditional static toolchain of "documentation → code → compilation → deployment", which greatly reduces the technical threshold and integration cost of connecting the enterprise's existing business APIs to the LLM ecosystem.

[0108] The dual-channel session negotiation mechanism leverages the immutability of URL query parameters in HTTP redirection to solve the session loss problem caused by request header stripping and redirection in complex network environments such as Kubernetes and enterprise private clouds, ensuring the stability of SSE long connections and improving the success rate of streaming connections between the model and the gateway.

[0109] By using dynamic operation graphs, MCP commands can be accurately translated into HTTP requests, avoiding parameter matching errors caused by manual coding. At the same time, it provides LLM with standardized tool definitions and response results, shielding the underlying HTTP protocol details and reducing the cognitive burden and error rate of LLM calling tools.

[0110] When backend business APIs undergo adjustments such as parameter additions or interface changes, only the OpenAPI description file needs to be updated. The system can then rebuild the dynamic operation graph and MCP tool definition through hot updates without restarting the service or re-releasing the version, enabling real-time iteration of business capabilities.

[0111] In some embodiments, such as Figure 2 As shown, the dynamic mapping module 101 includes:

[0112] The loading and parsing unit 1011 is used to read and parse the OpenAPI specification file when the system starts up or receives a hot update instruction, traverse the paths and component nodes in it, and extract the API metadata.

[0113] The graph construction unit 1012 is used to construct the dynamic operation graph in memory based on the metadata;

[0114] The homogenization mapping unit 1013 is used to merge and map the heterogeneous parameters defined in the OpenAPI specification in path parameters, query parameters, request header parameters and request body parameters into a one-dimensional input pattern definition that conforms to a preset structure description specification, so as to form the homogenization parameter contract.

[0115] In this embodiment, the loading and parsing unit 1011 refers to the basic data processing unit of the dynamic mapping module, which is responsible for reading, parsing and extracting metadata from the OpenAPI description file, and is the data source entry point for dynamically building MCP services.

[0116] The graph construction unit 1012 refers to the core processing unit of the dynamic mapping module, which is responsible for structuring the extracted API metadata into a dynamic operation graph in memory, thereby realizing the standardized storage and association of metadata.

[0117] The homogenization mapping unit 1013 refers to the core parameter processing unit of the dynamic mapping module, which is responsible for solving the heterogeneity problem of API parameters and is the key unit for realizing unified LLM calls.

[0118] The one-dimensional input pattern definition refers to the integration of four heterogeneous parameters (Path, Query, Header, Body) into a single-dimensional parameter input specification, which conforms to the JSON Schema Draft standard and is the core representation of the homogeneous parameter contract.

[0119] This embodiment details the internal structure and execution logic of the dynamic mapping module. The dynamic mapping module includes a loading and parsing unit, a graph construction unit, and a homogenization mapping unit. These three units work collaboratively in the order of data flow to achieve precise conversion from OpenAPI files to the MCP tool definition. Specific implementation steps are as follows:

[0120] API Metadata Extraction: The loading and parsing unit automatically reads the OpenAPI specification file (YAML / JSON format) when the system starts, or rereads the updated specification file when a hot update command is received; then, it performs deep parsing of the file, traversing the paths node (containing API access address, GET / POST request methods, operation descriptions, etc.) and components node (containing reusable data model schemas, security authentication modes, response definitions) to extract the complete metadata of the API, including core information such as parameter names, parameter types, parameter locations, constraints, and function descriptions.

[0121] Dynamic Operation Graph Construction: The graph construction unit receives the API metadata extracted by the loading and parsing unit and constructs the dynamic operation graph in memory according to preset structured rules. During the construction process, the metadata is associated and bound with tool metadata, parameter contracts, and execution mapping logic to ensure that each API information in the graph contains the core elements required for LLM calls, and at the same time, a precise mapping relationship between MCP instructions and HTTP requests is established.

[0122] Heterogeneous parameter homogenization processing: The homogenization mapping unit extracts API parameters scattered across four dimensions from the dynamic operation graph: Path parameters for locating resource entities, Query parameters for filtering / sorting / pagination, Header parameters for passing context / security credentials, and Body parameters for transmitting business payloads. Then, through a preset mapping algorithm, the above heterogeneous parameters are merged, flattened, and standardized, mapped to a one-dimensional input pattern definition conforming to the JSONSchema Draft standard, and finally forming a homogenized parameter contract, which is then updated in the dynamic operation graph.

[0123] MCP Tool Definition Generation and Release: Based on the dynamic operation graph containing isomorphic parameter contracts, the dynamic mapping module generates standardized MCP tool definitions, provides LLMs with unified tool names, natural language function descriptions, and one-dimensional parameter input specifications, and releases the tool definitions to client LLMs, completing the core workflow of the dynamic mapping module.

[0124] The above scheme integrates four-dimensional heterogeneous parameters into a one-dimensional input mode through homogenization mapping units, providing LLM with a clear and unified parameter input interface. This eliminates the need for LLM to understand the parameter distribution rules of the underlying HTTP protocol, significantly reducing the cognitive burden of LLM calling APIs and the parameter matching error rate.

[0125] The loading and parsing unit supports triggering the rereading and parsing of OpenAPI files via hot update commands. When business APIs change, the dynamic operation graph and MCP tool definitions can be updated without restarting the service, achieving real-time synchronization of business capabilities and significantly reducing system operation and maintenance costs.

[0126] The graph construction unit organizes API metadata into a standardized dynamic operation graph, realizing the associated storage of tool metadata, parameter contracts, and execution mapping logic. This provides an accurate basis for the subsequent request translation of the execution proxy module, ensuring that the conversion from MCP instructions to HTTP requests is error-free.

[0127] Through homogenization and dynamic operation graph construction, the system shields the LLM from the protocol and parameter distribution differences of different business APIs, exposing only standardized tool definitions. This allows the LLM to call different business system APIs in a unified way, improving the universality and efficiency of LLM tool calls.

[0128] In some embodiments, such as Figure 3 As shown, the session management module 102 includes:

[0129] The first negotiation unit 1021 is used as the standard header channel to extract the session identifier from the HTTP request header for establishing an SSE connection.

[0130] The second negotiation unit 1022 is used as the out-of-band anchor channel. When the first negotiation unit fails to extract the session identifier or the HTTP request is redirected, the session identifier is parsed from the URL query string of the HTTP request.

[0131] The context reconstruction unit 1023 is used to reconstruct and maintain the corresponding virtual session context in the server memory based on the session identifier extracted by the first negotiation unit or the second negotiation unit.

[0132] In this embodiment, the first negotiation unit refers to the main session identifier acquisition unit of the session management module, which corresponds to the standard header channel and is responsible for extracting the session identifier from the HTTP request header. This is the session acquisition method in a conventional scenario.

[0133] The second negotiation unit refers to the backup session identifier acquisition unit of the session management module. It corresponds to the out-of-band anchor channel and is the core fault tolerance processing unit, responsible for extracting the session identifier when the header channel fails.

[0134] The context reconstruction unit refers to the state management unit of the session management module, which is responsible for the reconstruction, maintenance and updating of the virtual session context, and is the core unit for realizing multi-session isolation.

[0135] 307 Temporary Redirect is an HTTP temporary redirect status code, indicating that the requested resource has been temporarily moved to a new URL. The client will automatically follow the redirect request, but will discard custom request headers by default. It is one of the main scenarios that lead to the loss of MCP sessions.

[0136] Strict slash refers to the gateway's strict path matching rule. It means that the gateway strictly matches the slash ending of the request path. If the slash in the request path does not match the slash in the actual path, a 307 redirect will be triggered. This is a common redirection scenario in cloud-native environments.

[0137] This embodiment details the internal structure and fault-tolerant execution logic of the session management module. The session management module includes a first negotiation unit, a second negotiation unit, and a context reconstruction unit. These three units work collaboratively according to the principle of "master-slave switching and unified state" to solve the session breakage problem of SSE long connections in cloud-native environments. Specific implementation steps are as follows:

[0138] SSE Connection Request Reception and Main Channel Negotiation: When the LLM initiates a request to the system to establish an SSE long connection, the session management module first starts the first negotiation unit as the standard header channel, and attempts to extract the custom mcp-session-id session identifier from the HTTP request header; if the first negotiation unit successfully extracts a valid session identifier, it directly passes the identifier to the context reconstruction unit.

[0139] Backup channel triggering and fault tolerance negotiation: If the first negotiation unit fails to extract the session identifier from the request header (e.g., the request header is stripped by middleware such as Nginx Ingress or API Gateway), or if the request is detected to be redirected to 307 Temporary Redirect due to rules such as Strict Slash, the session management module immediately triggers the second negotiation unit, which acts as an out-of-band anchor channel. It parses the URL query string of the HTTP request and extracts the session_id parameter as the session identifier. The second negotiation unit utilizes the immutability of the URL parameter during the HTTP redirection process to ensure that the session identifier is not lost, thus completing the session negotiation in the fault tolerance scenario.

[0140] Virtual Session Context Reconstruction and Maintenance: The context reconstruction unit receives a valid session identifier from the first or second negotiation unit. First, it searches the server memory to see if a virtual session context corresponding to the identifier exists. If it exists, it loads and maintains the context directly, updating the latest session state. If it does not exist, it creates a dedicated virtual session context for the identifier, storing core data such as the session identifier, connection information, and interaction context. Throughout the entire SSE long connection lifecycle, the context reconstruction unit continuously maintains the virtual session context to ensure that subsequent MCP tool call requests can be accurately routed to the corresponding event stream.

[0141] Session context routing and usage: The session management module synchronizes the reconstructed virtual session context information to the execution agent module, enabling the execution agent module to receive and process LLM tool call requests within the corresponding context, thereby achieving session state isolation and precise routing.

[0142] The above solution, through its dual-channel primary / backup switching design, effectively addresses various session loss scenarios in cloud-native environments, such as request header stripping and 307 redirects. It is compatible with various middleware deployment methods, including Nginx Ingress, K8s Service, and enterprise-level API gateways, significantly improving the system's deployment success rate and stability in complex network topologies.

[0143] Out-of-band anchor point channels leverage the immutability of URL parameters to completely resolve the Session ID Required error in MCP protocol redirection scenarios, ensuring that the session identifier of SSE long-connection is not lost throughout the interaction process, and improving the success rate of streaming connections between the model and the gateway.

[0144] The context reconstruction unit constructs an independent virtual session context for each session identifier, effectively achieving state isolation in multi-user, multi-LLM, and multi-dialogue scenarios, preventing data crosstalk between different sessions, and ensuring the accuracy of tool calls and the security of business data.

[0145] The virtual session context is built in memory and does not require persistent storage, enabling lightweight management of session state. At the same time, the context reconstruction unit only performs a retrieval / creation operation once when the connection is established, and only maintains the state thereafter, which greatly reduces the system's resource consumption and improves the concurrent processing capability.

[0146] In some embodiments, such as Figure 4 As shown, the execution agent module 103 includes:

[0147] The multipart request encapsulation unit 1031 is used to automatically detect whether the parameter value is a file path according to the homogenization parameter contract in the dynamic operation graph when the media type of the target HTTP request is multipart form data. If it is, the corresponding file content stream is mounted; otherwise, it is encapsulated as a text field.

[0148] The path self-healing unit 1032 is used to clean the complete request URL, which is formed by concatenating the base URL and endpoint path recorded in the dynamic operation graph, before sending the target HTTP request, and remove redundant forward slashes and hidden whitespace characters at the concatenation point.

[0149] The result encapsulation unit 1033 is used to encapsulate the original HTTP response returned by the business system into an MCP standard call tool result object containing content and error status.

[0150] In some embodiments, the multipart request encapsulation unit refers to the multimodal processing unit of the execution proxy module, which is responsible for the automatic encapsulation of multipart / form-data type HTTP requests and is the core unit supporting multimodal tasks such as file upload.

[0151] The path self-healing unit refers to the URL preprocessing unit of the execution proxy module, which is responsible for cleaning and repairing the request URL and is a fault-tolerant unit that improves the success rate of HTTP request execution.

[0152] The result encapsulation unit refers to the response standardization unit of the execution agent module. It is responsible for the MCP protocol encapsulation of the original response of the business system and is the core unit for realizing unified response processing in LLM.

[0153] multipart / form-dat is a complex HTTP request media type, primarily used for file uploads or submissions with multiple fields, and is a common request type in enterprise-level business systems.

[0154] The base URL refers to the basic access address of the business system. It is the core address information defined in the OpenAPI description file, such as https: / / api.enterprise.com.

[0155] Endpoint path refers to the specific access path of the API, which is the path defined in the paths node of the OpenAPI description file, such as / v1 / user / create.

[0156] The UnsupportedProtocol error refers to an HTTP request protocol error caused by an invalid URL format (such as containing hidden spaces, redundant forward slashes, or illegal characters). It is a common cause of call failure in static adaptation schemes.

[0157] This embodiment details the internal structure and complex scenario handling logic of the execution proxy module. The execution proxy module includes a multi-part request encapsulation unit, a path self-healing unit, and a result encapsulation unit. These three units are designed to address three major enterprise-level pain points: multimodal requests, URL format errors, and response standardization. Each unit performs its specific function in the entire process of MCP instruction translation to HTTP request execution and response return. Specific implementation steps are as follows:

[0158] MCP Request Translation and Request Type Determination: The execution proxy module receives the MCP tool call request from the LLM in the virtual session context. Based on the execution mapping logic in the dynamic operation graph, it translates the request into a target HTTP request that conforms to the OpenAPI description, and determines core information such as the request method, parameter binding location, and media type. If the media type of the target HTTP request is determined to be multipart / form-data, the multipart request encapsulation unit is triggered for processing. If it is a normal media type, it directly enters the path self-healing stage.

[0159] Automatic encapsulation of multimodal payloads: The multi-part request encapsulation unit traverses and checks the translated request parameters according to the isomorphic parameter contract in the dynamic operation graph, and determines whether each parameter value is a file path (such as a local file path or a network file path). If a parameter value is detected as a file path, the file content is automatically read and mounted into the HTTP request. If a parameter value is detected as plain text / numeric, it is encapsulated according to the field specification of multipart / form-data. After encapsulation, a multi-part form data request conforming to the standard is generated and passed to the path self-healing unit.

[0160] Request URL self-healing and cleaning: The path self-healing unit receives the reverse-translated target HTTP request (or the request processed by the multi-part request encapsulation unit), extracts the Base URL and Endpoint path recorded in the dynamic operation graph, and performs full cleaning on the complete request URL formed by concatenating the two: automatically identifies and removes redundant forward slashes (such as https: / / api.enterprise.com / / v1 / user) and hidden whitespace characters (such as spaces and tabs introduced by configuration errors), while filtering illegal characters in the URL; after cleaning, it generates a complete request URL with a valid format to ensure that the HTTP request can be executed normally.

[0161] HTTP Request Execution and Raw Response Reception: The execution proxy module sends the cleaned / encapsulated target HTTP request to the corresponding business system, establishes a communication connection with the business system, and receives the raw response returned by the business system. The raw response may contain various formats such as business data in JSON format, error pages in HTML format, and plain text prompts.

[0162] Standardized encapsulation and return of response results: The result encapsulation unit receives the original response from the business system and encapsulates it into a CallToolResult object according to the MCP protocol standard. After parsing the original response content, it stores it in the content field. Based on the response status code and error information, it determines whether the request was executed successfully and stores the determination result in the isError field (false for success and true for failure). After encapsulation, the CallToolResult object is returned to the LLM through an SSE long connection, completing the entire tool call response process.

[0163] The above solution achieves automated encapsulation of multipart / form-data type requests through a multipart request encapsulation unit, supports automatic identification of file paths and mounting of file streams, and enables LLM to perform multimodal business tasks such as ticket uploading, file parsing, and image recognition through the MCP tool, breaking through the limitation of traditional static adaptation solutions that only support simple text requests.

[0164] The path self-healing unit automatically cleans up redundant forward slashes, hidden whitespace characters, and other formatting issues in URLs, avoiding UnsupportedProtocol errors caused by configuration mistakes or splicing errors. This solves the core pain point of URL format sensitivity in static adaptation solutions, significantly improving the success rate of HTTP request execution.

[0165] The result encapsulation unit uniformly encapsulates the original responses from various business systems into CallToolResult objects conforming to the MCP protocol. This allows the LLM to resolve the content and isError fields using fixed logic, eliminating the need to adapt to different business system response formats and reducing the complexity and development cost of response processing on the LLM side. (Businessperson)

[0166] The fully automated process of multimodal encapsulation, URL cleaning, and response encapsulation eliminates the need for developers to write dedicated request / response processing code for each API. This enables code-free adaptation of complex requests from enterprise-level business systems, significantly improving the integration efficiency of LLM with heterogeneous enterprise systems.

[0167] All three units of the execution agent module are designed to be fault-tolerant. They have been specifically designed to address common issues such as multimodal requests, configuration errors, and inconsistent response formats during enterprise-level deployment, making the system more robust and adaptable to complex business system scenarios within enterprises, such as ERP, OA, and finance.

[0168] In some embodiments, such as Figure 5 As shown, the system also includes:

[0169] The traffic learning and analysis module 104 is connected to the dynamic mapping module and the execution proxy module, respectively.

[0170] The traffic learning and analysis module 104 includes:

[0171] Traffic acquisition unit 1041 is used to anonymously collect request parameter combinations and response status codes to form runtime traffic data during the process of the execution proxy module sending HTTP requests and receiving business system responses.

[0172] Contract optimization and discovery unit 1042 is used to analyze the runtime traffic data and compare and learn it with the homogenization parameter contract in the dynamic operation graph.

[0173] The contract optimization and discovery unit 1042 is specifically used to perform the following steps:

[0174] Filter the runtime traffic data to identify request samples with response status codes indicating success;

[0175] Statistical analysis of the co-occurrence frequency of different parameters in the successful request samples;

[0176] When the co-occurrence frequency of the first parameter and the second parameter in the successful request samples exceeds the preset confidence threshold, it is determined that there is a dependency constraint relationship between the first parameter and the second parameter.

[0177] The identified dependency constraints are added to the isomorphic parameter contract so that when the LLM calls the tool later, the tool definition generated by the dynamic mapping module can guide the LLM to generate a parameter combination that conforms to the dependency constraints.

[0178] In this embodiment, the traffic learning and analysis module is the core module of the system's intelligent self-optimization. By collecting and analyzing API call traffic data from actual operation, it realizes the automated optimization and improvement of homogeneous parameter contracts.

[0179] The traffic acquisition unit refers to the basic data acquisition unit of the traffic learning and analysis module. It is responsible for collecting and calling data seamlessly during the execution of HTTP requests, providing real runtime data support for contract optimization.

[0180] The Contract Optimization and Discovery Unit is the core analysis and processing unit of the Traffic Learning and Analysis Module. It is responsible for mining and analyzing the collected traffic data to discover and extract parameter dependency constraints that are not declared in the OpenAPI description file.

[0181] Runtime traffic data refers to the actual data generated by the system during the actual processing of LLM tool call requests. It mainly includes the combination of request parameters and the response status codes of the business system, and is the raw data for traffic analysis.

[0182] Co-occurrence frequency refers to the proportion of times two or more parameters appear simultaneously in a successful API call request sample out of the total number of successful samples. It is a core quantitative indicator for determining whether there is a dependency relationship between parameters.

[0183] The confidence threshold is a critical value for the co-occurrence frequency of parameters preset by the system. When the co-occurrence frequency between parameters exceeds this value, it is determined that there is a real business-level dependency constraint relationship between the parameters. This threshold can be flexibly configured according to the enterprise's business scenario.

[0184] Parameter dependency constraints refer to the association rules between parameters formed in the actual use of a business system API. That is, some parameters must be passed in at the same time to complete a valid call. This relationship may not be explicitly declared in the OpenAPI description file.

[0185] This embodiment adds a traffic learning and analysis module to the system. This module connects to the dynamic mapping module and the execution proxy module. While the system completes the basic MCP tool construction and invocation process, it executes a closed-loop self-learning process of traffic collection, data analysis, and contract optimization in parallel, realizing the dynamic improvement of homogeneous parameter contracts. The specific implementation steps are as follows:

[0186] The runtime traffic data collection unit performs non-intrusive and anonymized data collection throughout the entire process of the execution proxy module sending target HTTP requests to the business system and receiving responses from the business system. It only extracts the parameter combinations (including parameter names and input values) in the request and the HTTP response status code returned by the business system, without collecting sensitive business data, forming standardized runtime traffic data and storing it temporarily. The collection process does not affect the request processing efficiency of the execution proxy module, thus achieving seamless collection.

[0187] The successful request sample screening contract optimization and discovery unit filters out successful request samples (such as requests corresponding to HTTP success status codes) from the temporarily stored runtime traffic data; it removes failed request samples with response status codes of 4xx and 5xx to ensure that subsequent analysis is based on real and valid API call scenarios and avoids interference from erroneous data in the determination of parameter constraint relationships.

[0188] The parameter co-occurrence frequency statistical contract optimization and discovery unit performs in-depth analysis on the filtered successful request samples, traverses all parameter combinations of the samples, and calculates the co-occurrence frequency between any two parameters: that is, the ratio of the number of times two parameters appear in the same successful request to the total number of successful request samples; the statistical process covers all parameters in the isomorphic parameter contract to ensure no omissions.

[0189] The parameter dependency constraint determination contract optimization and discovery unit compares the statistically obtained parameter co-occurrence frequency with the system's preset confidence threshold. When the co-occurrence frequency of the first parameter and the second parameter exceeds the confidence threshold, it is determined that there is a real business dependency constraint relationship between the two parameters (that is, the two parameters must be passed in at the same time to realize the effective call of the API). If it does not exceed the threshold, it is determined that there is no mandatory dependency relationship between the parameters.

[0190] The isomorphic parameter contract update and tool definition regeneration contract optimization and discovery unit adds all identified parameter dependency constraints to the isomorphic parameter contracts in the dynamic operation graph, supplementing and improving the original contracts. Based on the updated isomorphic parameter contracts, the dynamic mapping module regenerates standardized MCP tool definitions and synchronously provides the updated tool definitions to the client LLM. When the LLM subsequently initiates a tool call request, it will generate parameter combinations that conform to parameter dependency constraints based on the updated tool definitions.

[0191] The above solution analyzes real runtime traffic data to automatically discover parameter dependency constraints that are not declared in the OpenAPI description file but exist in actual business, and realizes the dynamic improvement of isomorphic parameter contracts, thus solving the problem of API documentation being out of touch with actual business scenarios in traditional solutions.

[0192] The updated MCP tool definition includes real parameter dependency constraints, which can effectively guide LLM to generate complete parameter combinations that conform to business rules, reduce API call failures caused by missing parameters or incorrect parameter combinations, and significantly improve the success rate of LLM tool calls.

[0193] The entire process of traffic learning and contract optimization is fully automated, eliminating the need for developers to manually analyze API call logs, update OpenAPI documentation and parameter contracts, reducing the need for continuous manual maintenance of API documentation and further lowering the company's operational costs.

[0194] When business process adjustments lead to changes in API parameter dependencies, the system can automatically detect and update parameter contracts through continuous traffic learning, without manual intervention. This allows the system to quickly adapt to dynamic changes in business scenarios, improving its business adaptability. The traffic collection process employs anonymization and non-intrusive design, collecting only parameter combinations and response status codes, without collecting any business-sensitive data. This ensures self-optimization while fully protecting the security and privacy of enterprise business data.

[0195] In some embodiments, the dynamic mapping module 101 further includes:

[0196] The operation association analysis unit 1014 is used to analyze the potential associations between different API operations when constructing the dynamic operation graph. The potential associations include semantic similarity or data structure matching between the output parameters of the first API operation and the input parameters of the second API operation.

[0197] The system also includes a toolset and orchestration engine 105, which is connected to the dynamic mapping module, the session management module, and the execution agent module, respectively. Figure 6 As shown, the toolset and orchestration engine 105 includes:

[0198] The intent parsing and matching unit 1051 is used to parse the tool call request from the LLM and generate a task description; match the task description with the isomorphic parameter contract of each API operation in the dynamic operation graph; when there is no isomorphic parameter contract of a single API operation that can satisfy all the input parameter requirements of the task description, it is determined that a tool combination is needed.

[0199] The process generation unit 1052 is used to generate an execution sequence containing multiple API operations based on the potential relationships in the dynamic operation graph when it is determined that tool combination is required; the execution sequence defines the execution order of each API operation and specifies which data in the output parameters of the upstream API operation will be used as the input parameters of the downstream API operation.

[0200] The process execution and context management unit 1053 is used to sequentially call the execution proxy module to execute each API operation according to the execution sequence; during the execution process, according to the specified execution sequence, the corresponding data in the response result of the upstream API operation is filled into the corresponding parameters of the homogenization parameter contract of the downstream API operation;

[0201] The result output unit 1054 is used to collect the output data obtained by the process execution and context management unit after executing the execution sequence, and encapsulate the output data into a call tool result object conforming to the MCP protocol and return it to the LLM.

[0202] In this embodiment, the operation association analysis unit refers to the extended core unit of the dynamic mapping module. It is responsible for analyzing the data flow association between different API operations when constructing the dynamic operation graph, providing a preliminary association basis for tool combination and orchestration.

[0203] The tool suite and orchestration engine is the core module for handling complex tasks in the system. It enables the automated combination and orderly execution of multiple API operations, allowing LLM to complete complex business tasks that require the collaboration of multiple APIs with a single request.

[0204] Potential relationships refer to the data flow association rules between different API operations. The core is the semantic similarity or data structure matching between the output parameters of the upstream API and the input parameters of the downstream API, which is the core basis for realizing automatic API combination.

[0205] The intent parsing and matching unit refers to the pre-processing unit of the tool assembly and orchestration engine. It is responsible for parsing the tool call requests of LLM, extracting the core task intent, and matching it with the parameter contract of the single API operation to determine whether tool assembly is needed.

[0206] The execution sequence refers to the multi-API operation execution rules generated by the tool combination and orchestration engine for complex tasks. It includes the execution order of API operations and the parameter passing rules between upstream and downstream APIs, and is the core basis for multi-API collaborative execution.

[0207] The process execution and context management unit refers to the core execution unit of the tool suite and orchestration engine. It is responsible for executing API operations sequentially according to the execution sequence and realizing automatic parameter transfer and context maintenance between upstream and downstream APIs.

[0208] This embodiment adds an operation association analysis unit to the dynamic mapping module and a new tool combination and orchestration engine to the system. This engine connects to the dynamic mapping module, session management module, and execution agent module, respectively. Based on the potential relationships between APIs, it can realize the intent parsing of complex tasks, automatic tool combination, process orchestration and execution, and unified result return, breaking through the capability boundary of single API operation. Specific implementation steps:

[0209] The operation correlation analysis unit of the API operation potential correlation analysis and graph update dynamic mapping module performs cross-operation correlation analysis on all API operations during the construction of the dynamic operation graph by the graph construction unit. It extracts the output and input parameters of each API operation and determines the potential correlation between different API operations (i.e., whether the output parameter of the first API operation can be used as the input parameter of the second API operation) through semantic similarity matching and data structure matching algorithms. The potential correlation obtained from the analysis is added to the dynamic operation graph to provide a correlation basis for subsequent tool combination.

[0210] The intent parsing and matching unit of the LLM tool call request assembly and orchestration engine receives tool call requests from LLM, parses the core semantics of the request using natural language processing algorithms, and generates a standardized task description (including task objectives, required input information, etc.). It then matches the task description one by one with the isomorphic parameter contracts of each individual API operation in the dynamic operation graph, checking if there is a single API operation parameter contract that can satisfy all the input parameter requirements of the task description. If so, the request is directly forwarded to the execution proxy module for processing; otherwise, the task is determined to be a complex task requiring tool assembly.

[0211] When it is determined that tool combinations are required, the process generation unit extracts the potential relationships between various API operations from the dynamic operation graph and generates an execution sequence containing multiple API operations based on the core requirements of the task description:

[0212] Define the execution order of each API operation to ensure it conforms to the business process logic;

[0213] Define the parameter passing rules between upstream and downstream API operations, specifying which data from the output parameters of the upstream API operation will be used as input parameters for the downstream API operation.

[0214] The multi-API operation orchestration and execution, along with the automatic parameter passing process and context management unit, operates within a virtual session context maintained by the session management module. Following the execution sequence requirements, it sequentially calls the execution proxy module to execute each API operation. During execution, based on the parameter passing rules specified in the execution sequence, it extracts the target data from the upstream API operation response in real time and automatically fills it into the corresponding input parameters of the homogeneous parameter contract of the downstream API operation, achieving automatic parameter passing between upstream and downstream APIs without manual intervention. Simultaneously, it maintains the global context of multi-API execution, recording the execution status and data of each step to ensure the continuity of the process.

[0215] The complex task result unified encapsulation and return result output unit collects the full-process output data obtained by the process execution and context management unit after executing the entire execution sequence, and encapsulates it in a unified manner according to the MCP protocol standard to generate a compliant tool call result object. The result object is returned to the LLM through an SSE long connection to complete the full-process processing of complex tasks, so that the LLM only needs to receive a standardized result and does not need to handle the scattered responses of multiple APIs.

[0216] The above solution enables LLM to complete complex business tasks that require the coordinated execution of multiple API operations (such as "querying the latest user orders and completing the shipment process") with a single request, breaking through the capability limitations of traditional single API tool calls and allowing LLM to be truly implemented in complex business scenarios of enterprises.

[0217] The system completes the process planning, API combination, and parameter passing of complex tasks through tool combinations and orchestration engines. The LLM only needs to express the high-level business intent, without having to perform tedious step planning and parameter matching, which reduces the processing burden of the LLM and avoids task execution failures caused by LLM planning errors, thereby improving the reliability and efficiency of complex task execution.

[0218] The operation correlation analysis unit can automatically discover potential relationships between API operations. The process generation unit automatically generates execution sequences based on these relationships, eliminating the need for developers to manually configure API combination rules and process orchestration logic, thus significantly reducing the manual development and maintenance costs for enterprises.

[0219] The process execution and context management unit can automatically extract the output parameters of the upstream API and fill them into the input parameters of the downstream API. This eliminates the need for LLM or manual intermediate data processing and transmission, enabling end-to-end automated execution of complex business processes and improving task processing efficiency.

[0220] The system encapsulates the scattered results of multiple API executions into a unified package, providing a standardized single result object for LLM. This enables LLM to parse the results with a unified logic, eliminating the need to adapt to different API response formats and reducing the complexity of LLM result processing.

[0221] In the second aspect, such as Figure 7 As shown, this application provides a method for dynamically constructing MCP services based on OpenAPI. This method is applicable to systems for dynamically constructing MCP services based on OpenAPI as described in the first aspect of this application. The method includes:

[0222] S701: The dynamic mapping module loads and parses the OpenAPI description file at runtime, constructs a dynamic operation graph in memory based on the parsed API metadata, generates MCP tool definitions based on the dynamic operation graph, and provides the MCP tool definitions to the client large language model LLM.

[0223] S702: When the session management module receives a request from the LLM's establishment server to send an event SSE long connection, it obtains the session identifier through a dual-channel negotiation mechanism. The dual channels include a standard header channel extracted from the HTTP request header and an out-of-band anchor channel extracted from the URL query string. The virtual session context is reconstructed and maintained on the server side for the obtained session identifier.

[0224] S703: In the virtual session context, the execution agent module receives a tool invocation request from the LLM based on the MCP tool definition, translates the tool invocation request into a target HTTP request that conforms to the OpenAPI description according to the execution mapping logic in the dynamic operation graph, sends the target HTTP request to the corresponding business system, and encapsulates the response of the business system into a tool invocation result object that conforms to the MCP protocol standard and returns it to the LLM.

[0225] In some embodiments, the system includes a traffic learning and analysis module, which includes a traffic acquisition unit and a contract optimization and discovery unit;

[0226] like Figure 8 As shown, the method includes:

[0227] S801: During the process of the execution agent module sending HTTP requests and receiving responses from the business system, the traffic collection unit anonymously collects the combination of request parameters and response status codes to form runtime traffic data.

[0228] S802: The contract optimization and discovery unit analyzes the runtime traffic data and compares and learns it with the homogenized parameter contract in the dynamic operation graph, specifically including:

[0229] Filter the runtime traffic data to identify request samples with response status codes indicating success;

[0230] Statistical analysis of the co-occurrence frequency of different parameters in the successful request samples;

[0231] When the co-occurrence frequency of the first parameter and the second parameter in the successful request samples exceeds the preset confidence threshold, it is determined that there is a dependency constraint relationship between the first parameter and the second parameter.

[0232] The identified dependency constraints are added to the isomorphic parameter contract so that when the LLM calls the tool later, the tool definition generated by the dynamic mapping module can guide the LLM to generate a parameter combination that conforms to the dependency constraints.

[0233] This method automates and dynamically updates isomorphic parameter contracts, enabling MCP tool definitions to reflect the actual business scenarios of enterprises in real time. It effectively guides LLM in generating parameter combinations that conform to business rules, continuously improving the accuracy and success rate of LLM tool calls. The entire traffic learning and contract optimization process is fully automated, requiring no manual intervention. This achieves system self-learning and self-evolution, reducing developers' manual maintenance work on API documentation and parameter contracts, and further lowering enterprise operational costs.

[0234] like Figure 9 The diagram shown is a schematic representation of the overall architecture of the metadata-driven dynamic MCP gateway system of this invention. Figure 9 The document clearly demonstrates the core modules of the system, the connections between modules, and the overall data flow logic. This architecture is a unified, managed streaming gateway architecture that enables the aggregation and parsing of OpenAPI files from multiple business systems and the centralized construction of MCP services, solving the problem of isolated deployment of traditional MCP services with "one system, one service".

[0235] This architecture is based on three core modules: dynamic mapping, session management, and execution proxy. It also includes modules for traffic learning and analysis, tool combinations, and orchestration. These modules work together to form a complete adaptive MCP dynamic gateway system. The overall architecture is divided into three layers based on data interaction: the business system layer, the gateway core layer, and the Large Language Model (LLM) layer.

[0236] The business system layer is the underlying data source for the gateway, including various heterogeneous business systems within the enterprise such as ERP, OA, and finance. Each business system provides a standardized OpenAPI description file, which provides the metadata foundation for the gateway to build MCP services.

[0237] The gateway core layer is the processing core of the entire system. It integrates all the above-mentioned functional modules and completes all core business logic such as OpenAPI parsing, dynamic operation graph construction, SSE long connection session maintenance, MCP and HTTP protocol conversion, traffic learning optimization, and complex task orchestration. It is the key middleware layer connecting business systems and large language models.

[0238] The LLM layer serves as the gateway's service object. The large language model interacts with the gateway's core layer through the standard MCP protocol. It does not need to be aware of the protocol differences of the underlying business system. It only obtains the MCP tool definition and initiates tool call requests through standard commands such as tools / list, and receives the standardized MCP protocol response results returned by the gateway.

[0239] The architecture features loose coupling between modules. The dynamic mapping module establishes data connections with the session management module, execution agent module, traffic learning and analysis module, and tool combination and orchestration engine, providing core metadata support such as dynamic operation graphs and MCP tool definitions for the remaining modules. The session management module provides virtual session contexts for the execution agent module, tool combination and orchestration engine, ensuring state isolation and accurate routing for streaming interactions. The execution agent module serves as the interaction entry point between the gateway and the business system, while also providing runtime traffic data to the traffic learning and analysis module and single API operation execution capabilities to the tool combination and orchestration engine. The traffic learning and analysis module analyzes runtime traffic data to inversely optimize the homogeneous parameter contract in the dynamic mapping module, achieving self-learning and self-evolution of the system.

[0240] The overall data flow follows a closed-loop logic of "LLM request - gateway processing - business system interaction - result return". The SSE long connection request initiated by the large language model and the MCP tool call request are processed collaboratively by multiple modules in the gateway core layer and then translated into HTTP requests that conform to the business system specifications. The response result of the business system is standardized and encapsulated by the gateway and returned to the large language model through the SSE long connection. The entire process realizes protocol transparency, interactive streaming and automated processing.

[0241] like Figure 10 The diagram illustrates the specific execution flow of the core parameter isomorphism mapping and MCP protocol adaptation in the dynamic mapping module of this invention. It details the entire process from heterogeneous parameter sources in the business system to the generation of standardized MCP ToolDefinition. This process is the core link to achieve the abstraction and shielding of the underlying protocol and enable large language models to call business APIs without being aware of them. The entire process strictly follows the JSON Schema Draft standard and finally outputs a one-dimensional inputSchema that conforms to the MCP protocol specification.

[0242] The execution body of this process is the loading and parsing unit, graph construction unit, and homogenization mapping unit of the dynamic mapping module. The process starts from the heterogeneous parameter source of the business system. This parameter source contains four types of heterogeneous parameters defined in the business system's OpenAPI description file, which are also the core processing objects of the process: first, path parameters (Path) used to locate specific resource entities; second, query parameters (Query) used for resource filtering, sorting, and pagination; third, header parameters (Header) used to pass context information and security credentials; and fourth, payload parameters (Body) used to transmit business content payloads. The payload parameters support multiple data formats such as JSON and Multipart / form-data.

[0243] The specific execution process of parameter isomorphism mapping and MCP protocol adaptation consists of the following five core steps:

[0244] Multi-source parameter aggregation: Load the parsing unit to parse the OpenAPI description file, extract the complete metadata of the above four types of heterogeneous parameters, including parameter name, parameter type, parameter constraints, parameter location and other information, and complete the unified aggregation and preliminary sorting of multi-source heterogeneous parameters;

[0245] Complex type inference and file stream identification: The isomorphism mapping unit performs deep analysis on the aggregated parameters, performs type inference on the complex MIME types in the Body, focuses on identifying file path parameters in the multipart / form-data type, provides pre-parameter marking for subsequent multimodal payload encapsulation, and flattens the complex data structure of various parameters.

[0246] Business constraint extraction: Combining the parameter validation rules in the OpenAPI description file and the basic business rules of the business system, extract business constraints such as the mandatory nature, value range, and format requirements of various parameters, so as to provide a basis for constraints in the subsequent construction of isomorphic parameter contracts;

[0247] Homogenization Mapping: The homogenization mapping unit uses a preset mapping algorithm to merge and map the four-dimensional heterogeneous parameters after aggregation, parsing, and constraint extraction into a one-dimensional input schema that conforms to the JSON Schema Draft standard, forming a standardized homogenization parameter contract. This contract provides a clear and unified parameter input specification for large language models.

[0248] MCP Tool Definition Generation: Based on the isomorphic parameter contract, the graph construction unit combines tool metadata (unique tool name, natural language function description) and execution mapping logic to generate a complete MCP Tool Definition in the dynamic operation graph, and provides the tool definition to the large language model to complete the entire parameter isomorphic mapping and MCP protocol adaptation process.

[0249] Through the above process, a precise conversion from heterogeneous parameters of business systems to standardized MCP tool definitions is achieved, allowing the large language model to perceive only concise tool names, function descriptions, and one-dimensional parameter lists, completely shielding the detailed differences in parameter distribution, message format, URL concatenation, and other aspects of the underlying HTTP protocol.

[0250] like Figure 11 The diagram shows the anti-redirection SSE long connection handshake sequence of the session management module of this invention in stateless cloud-native environments such as Kubernetes and enterprise private clouds. It clearly shows the execution sequence of the dual-channel session negotiation mechanism, the interaction steps of each participant, and the reconstruction process of the virtual session context. This sequence process is specifically designed for scenarios such as 307 Temporary Redirect caused by gateway strict path matching (Strict Slash) and middleware stripping of custom headers. It completely solves the "Session ID Required" error problem of native SSE long connections in the MCP protocol and ensures the stability of streaming sessions in stateless environments.

[0251] Figure 11 The sequence diagram shown involves three main participants: the Large Language Model (LLM) client, the Layer 7 middleware (Nginx Ingress / API Gateway), and the MCP dynamic gateway (session management module). The Layer 7 middleware is a necessary step in a stateless environment and is the core cause of session identifier loss. The entire handshake sequence begins with the LLM initiating an SSE long connection establishment request and ends with the completion of virtual session context reconstruction and successful SSE long connection handshake. It consists of four core stages: standard header channel negotiation, out-of-band anchor channel degradation triggering, virtual context reconstruction, and SSE long connection establishment. The specific execution sequence is as follows:

[0252] Phase 1: The LLM client initiates an SSE long connection request (standard header channel): The LLM client initiates an SSE long connection establishment request to the MCP dynamic gateway, carrying a custom mcp-session-id session identifier in the HTTP request header. The request is forwarded through the Layer 7 middleware.

[0253] Phase Two: Layer 7 Middleware Triggers 307 Redirect, Stripping Custom Header: Due to strict path matching rules, Layer 7 middleware triggers a 307 Temporary Redirect for requests to LLM clients. At the same time, during the forwarding process, the custom field mcp-session-id in the request header is stripped, causing the redirected request to lose the session identifier header.

[0254] Phase 3: MCP dynamic gateway detects missing header and triggers out-of-band anchor channel: The session management module of the MCP dynamic gateway receives the request after being redirected by the layer 7 middleware. The first negotiation unit attempts to extract the mcp-session-id from the request header. After detecting the missing header identifier, it immediately triggers the degradation strategy and starts the second negotiation unit.

[0255] Phase 4: Parsing Session Identifier for Out-of-Band Anchor Channel: The second negotiation unit of the MCP dynamic gateway parses the query string of the redirected request URL and extracts the session_id parameter as a valid session identifier. By utilizing the immutability of URL parameters during the HTTP redirection process, the session identifier can be effectively obtained.

[0256] Phase 5: Server-side reconstruction of virtual session context: The context reconstruction unit of the session management module reconstructs the virtual session context in the server memory of the MCP dynamic gateway based on the extracted session_id session identifier, allocates an independent state space for the session, records session connection information, and completes context initialization;

[0257] Phase Six: MCP Dynamic Gateway Returns SSE Connection Success Response: After the virtual session context is rebuilt, the MCP Dynamic Gateway returns a response to the LLM client indicating that the SSE long connection has been successfully established, and binds the rebuilt virtual session context to the SSE event stream.

[0258] Phase 7: SSE long connection handshake completed, entering the streaming interaction phase: After receiving the connection success response, the LLM client confirms that the SSE long connection handshake is complete. Subsequently, it can initiate MCP tool call requests in this session context. All requests can be accurately routed to the corresponding virtual context through the session identifier, realizing stable streaming interaction in a stateless environment.

[0259] In the above timing process, the standard header channel is the conventional negotiation method, and the out-of-band anchor point channel is the fault-tolerant degradation method. The two channels serve as backups for each other, ensuring that the session identifier can be effectively obtained and the virtual context can be accurately reconstructed in various network anomaly scenarios in the stateless cloud-native environment, so that the handshake success rate of the MCP protocol's SSE long connection in complex network topology is close to 100%.

[0260] In a third aspect, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for dynamically constructing an MCP service based on OpenAPI as described in the first aspect of the present invention.

[0261] The computer-readable storage medium may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0262] The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD ROM); the magnetic surface memory may be a disk storage device or a magnetic tape storage device.

[0263] The volatile memory may be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synclink dynamic random access memory (SLDRAM), and direct memory bus random access memory (DRRAM). The computer-readable storage media described in the embodiments of the present invention are intended to include these and any other suitable types of memory.

[0264] like Figure 12 As shown, in a fourth aspect, the present invention provides an electronic device 20, including a processor 201 and a storage medium 202, wherein a computer program is stored on the storage medium, and the computer program, when executed by the processor, implements the method for dynamically constructing MCP services based on OpenAPI as described in the first aspect of the present invention.

[0265] In some embodiments, the processor may be implemented by software, hardware, firmware, or a combination thereof, and may use at least one of the following: circuit, single or multiple application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), central processing units (CPUs), controllers, microcontrollers, and microprocessors, thereby enabling the processor to execute some or all of the steps, or any combination thereof, in the system for dynamically building MCP services based on OpenAPI as described in the various embodiments of this application.

[0266] It should be noted that although the above embodiments have been described herein, this does not limit the scope of patent protection for this invention. Therefore, any changes and modifications made to the embodiments described herein based on the innovative concept of this invention, or equivalent structural or procedural transformations made using the description and drawings of this invention, directly or indirectly applying the above technical solutions to other related technical fields, are all included within the scope of protection of this invention.

Claims

1. A system for dynamically building MCP services based on OpenAPI, characterized in that, The system includes: The dynamic mapping module is used to load and parse the OpenAPI description file at runtime, build a dynamic operation graph in memory based on the parsed API metadata, generate MCP tool definitions based on the dynamic operation graph, and provide the MCP tool definitions to the client large language model LLM. The dynamic operation graph includes tool metadata generated from API function descriptions, isomorphic parameter contracts formed by mapping and integrating API path parameters, query parameters, request header parameters and request body parameters, and execution mapping logic for restoring MCP tool call requests to HTTP requests. The session management module, connected to the dynamic mapping module, is used to obtain a session identifier through a dual-channel negotiation mechanism when it receives a request from the LLM's establishment server to send an event SSE long connection. The dual channels include a standard header channel extracted from the HTTP request header and an out-of-band anchor channel extracted from the URL query string. The module also reconstructs and maintains the virtual session context for the obtained session identifier on the server side. The execution proxy module, connected to both the dynamic mapping module and the session management module, is used to receive tool invocation requests from the LLM based on the MCP tool definition within the virtual session context. It then translates the tool invocation requests into target HTTP requests conforming to the OpenAPI description according to the execution mapping logic in the dynamic operation graph, sends the target HTTP requests to the corresponding business system, and encapsulates the business system's response into a tool invocation result object conforming to the MCP protocol standard, returning it to the LLM.

2. The system for dynamically building MCP services based on OpenAPI as described in claim 1, characterized in that, The dynamic mapping module includes: The loading and parsing unit is used to read and parse the OpenAPI specification file when the system starts up or receives a hot update instruction, traverse the paths and component nodes in it, and extract the API's metadata. The graph construction unit is used to construct the dynamic operation graph in memory based on the metadata; The isomorphism mapping unit is used to merge and map the heterogeneous parameters defined in the OpenAPI specification in path parameters, query parameters, request header parameters and request body parameters into a one-dimensional input pattern definition that conforms to a preset structure description specification, so as to form the isomorphism parameter contract.

3. The system for dynamically building MCP services based on OpenAPI as described in claim 1, characterized in that, The session management module includes: The first negotiation unit is used as the standard header channel to extract the session identifier from the HTTP request header for establishing an SSE connection. The second negotiation unit is used as the out-of-band anchor channel. When the first negotiation unit fails to extract the session identifier or the HTTP request is redirected, the session identifier is parsed from the URL query string of the HTTP request. The context reconstruction unit is used to reconstruct and maintain the corresponding virtual session context in the server memory based on the session identifier extracted by the first negotiation unit or the second negotiation unit.

4. The system for dynamically building MCP services based on OpenAPI as described in claim 1, characterized in that, The execution proxy module includes: The multipart request encapsulation unit is used to automatically detect whether the parameter value is a file path according to the homogenization parameter contract in the dynamic operation graph when the media type of the target HTTP request is multipart form data. If it is, the corresponding file content stream is mounted; otherwise, it is encapsulated as a text field. The path self-healing unit is used to clean the complete request URL, which is formed by concatenating the base URL and endpoint path recorded in the dynamic operation graph, before sending the target HTTP request, and remove redundant forward slashes and hidden whitespace characters at the concatenation point. The result encapsulation unit is used to encapsulate the original HTTP response returned by the business system into an MCP standard invocation tool result object containing content and error status.

5. The system for dynamically building MCP services based on OpenAPI as described in claim 1, characterized in that, The system also includes: The traffic learning and analysis module is connected to the dynamic mapping module and the execution proxy module, respectively. The traffic learning and analysis module includes: The traffic collection unit is used to anonymously collect the combination of request parameters and response status codes to form runtime traffic data during the process of the execution agent module sending HTTP requests and receiving responses from the business system. The contract optimization and discovery unit is used to analyze the runtime traffic data and compare and learn it with the homogeneous parameter contract in the dynamic operation graph. The contract optimization and discovery unit is specifically used for: Filter the runtime traffic data to identify request samples with response status codes indicating success; Analyze the co-occurrence frequency of different parameters in the successful request samples; When the co-occurrence frequency of the first parameter and the second parameter in the successful request samples exceeds the preset confidence threshold, it is determined that there is a dependency constraint relationship between the first parameter and the second parameter. The identified dependency constraints are added to the isomorphic parameter contract so that when the LLM calls the tool later, the tool definition generated by the dynamic mapping module can guide the LLM to generate a parameter combination that conforms to the dependency constraints.

6. The system for dynamically building MCP services based on OpenAPI as described in claim 1, characterized in that, The dynamic mapping module also includes: An operation association analysis unit is used to analyze the potential associations between different API operations when constructing the dynamic operation graph. The potential associations include semantic similarity or data structure matching between the output parameters of the first API operation and the input parameters of the second API operation. The system also includes a toolset and orchestration engine, which is connected to the dynamic mapping module, the session management module, and the execution agent module, respectively. The toolset and orchestration engine includes: The intent parsing and matching unit is used to parse tool call requests from LLM and generate task descriptions; match the task descriptions with the isomorphic parameter contracts of each API operation in the dynamic operation graph; when no single API operation has an isomorphic parameter contract that can satisfy all the input parameter requirements of the task description, it is determined that a tool combination is needed. The process generation unit is used to generate an execution sequence containing multiple API operations based on the potential relationships in the dynamic operation graph when it is determined that tool combinations are required. The execution sequence defines the execution order of each API operation and specifies which data from the output parameters of the upstream API operation will be used as the input parameters of the downstream API operation. The process execution and context management unit is used to sequentially call the execution proxy module to execute each API operation according to the execution sequence; during the execution process, according to the specified execution sequence, the corresponding data in the response result of the upstream API operation is filled into the corresponding parameters of the homogenization parameter contract of the downstream API operation; The result output unit is used to collect the output data obtained by the process execution and context management unit after executing the execution sequence, and encapsulate the output data into a call tool result object conforming to the MCP protocol and return it to the LLM.

7. A method for dynamically constructing MCP services based on OpenAPI, characterized in that, The method is applicable to the system for dynamically building MCP services based on OpenAPI as described in any one of claims 1-6, and the method includes: The dynamic mapping module loads and parses the OpenAPI description file at runtime, constructs a dynamic operation graph in memory based on the parsed API metadata, generates MCP tool definitions based on the dynamic operation graph, and provides the MCP tool definitions to the client large language model LLM. When the session management module receives a request from the LLM's establishment server to send an event SSE long connection, it obtains the session identifier through a dual-channel negotiation mechanism. The dual channels include a standard header channel extracted from the HTTP request header and an out-of-band anchor channel extracted from the URL query string. The virtual session context is reconstructed and maintained on the server side for the obtained session identifier. In the virtual session context, the execution agent module receives a tool invocation request from the LLM based on the MCP tool definition, translates the tool invocation request into a target HTTP request that conforms to the OpenAPI description according to the execution mapping logic in the dynamic operation graph, sends the target HTTP request to the corresponding business system, and encapsulates the response of the business system into a tool invocation result object that conforms to the MCP protocol standard and returns it to the LLM.

8. The method for dynamically constructing MCP services based on OpenAPI as described in claim 7, characterized in that, The system includes a traffic learning and analysis module, which includes a traffic acquisition unit and a contract optimization and discovery unit. The method includes: During the process of the execution proxy module sending HTTP requests and receiving responses from the business system, the traffic collection unit anonymously collects the combination of request parameters and response status codes to form runtime traffic data. The contract optimization and discovery unit analyzes the runtime traffic data and compares and learns it with the homogenized parameter contracts in the dynamic operation graph, specifically including: Filter the runtime traffic data to identify request samples with response status codes indicating success; Analyze the co-occurrence frequency of different parameters in the successful request samples; When the co-occurrence frequency of the first parameter and the second parameter in the successful request samples exceeds the preset confidence threshold, it is determined that there is a dependency constraint relationship between the first parameter and the second parameter. The identified dependency constraints are added to the isomorphic parameter contract so that when the LLM calls the tool later, the tool definition generated by the dynamic mapping module can guide the LLM to generate a parameter combination that conforms to the dependency constraints.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method for dynamically constructing MCP services based on OpenAPI as described in claim 7 or 8.

10. An electronic device, characterized in that, It includes a processor and a storage medium, on which a computer program is stored, which, when executed by the processor, implements the method for dynamically constructing an MCP service based on OpenAPI as described in claim 7 or 8.

Images