A method and system for API tooling based on model context protocol

Abstract

The application relates to the technical field of artificial intelligence, and provides an API tooling processing method and system based on a model context protocol, which comprises the following steps: responding to a business system access trigger event; acquiring and analyzing an interface document according to a business system access record to generate an interface object set; performing interface data synchronization processing on the interface object set based on a business primary key to generate a synchronized interface record, converting corresponding API interface capability into tool definition to generate a tool record; determining a target tool set from the tool record according to a target AI client or a target business scenario, creating a model context protocol service instance, and establishing a binding relationship between the service instance and the tool record; and performing tool query or tool calling according to a protocol request and returning a calling result, which can automatically access and analyze API interfaces of a business system, synchronously update the API interfaces when the interfaces change, automatically convert the API interfaces into tools that can be called by a large language model, and reduce manual adaptation and repeated configuration.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to an API toolization method and system based on model context protocol. Background Technology

[0002] With the development of large language models and intelligent agent technologies, integrating large language models with existing enterprise business systems to enable them to call the application programming interfaces (APIs) of these systems for information retrieval, business processing, and workflow execution has become a crucial direction for the implementation of intelligent applications. In practical enterprise applications, it is typically necessary to interface with enterprise resource planning systems, customer relationship management systems, configuration centers, and other business platforms to further support intelligent agents in calling and extending internal enterprise business capabilities. Therefore, how to effectively convert the API capabilities of enterprise business systems into processing capabilities that can be called by large language models has become a pressing technical problem that needs to be solved.

[0003] In existing technologies, API integration with different business systems typically requires developers to write adaptation code, parameter mapping logic, and tool definition information separately to meet model call requirements. This approach relies heavily on manual processing, resulting in long development cycles, a large amount of repetitive work, and is prone to affecting integration quality due to inconsistent interface descriptions, inaccurate parameter mappings, or inconsistent call logic. Furthermore, when the interface documentation of a business system is updated, the model caller often still needs to manually modify the relevant configurations and code, easily leading to inconsistencies between the interface documentation version and the actual call implementation, thus affecting system maintenance efficiency and operational stability.

[0004] Furthermore, different business systems typically exhibit significant differences in authentication schemes, timeout controls, access restrictions, and audit monitoring. Existing technologies lack a unified solution, making it difficult to achieve unified management of API calls from multiple business systems. On the other hand, in tool call scenarios targeting large language models, directly exposing numerous business system APIs to the model can easily increase ambiguity in the tool selection process, leading to erroneous calls, invalid calls, or increased tool management complexity. Therefore, there is an urgent need to propose a technical solution that enables automatic discovery and synchronization of business system APIs, automatic conversion of API capabilities into model-callable tools, on-demand organization and release of tool sets, and unified processing of the call process. Summary of the Invention

[0005] To address the problems in existing technologies, such as reliance on manual adaptation for business system API access, difficulty in timely synchronization of interface documentation updates, and the potential for ambiguity and mis-invocation in tool selection due to the direct exposure of numerous APIs to models, this application provides an API toolification processing method and system based on a model context protocol. By automatically discovering, parsing, synchronizing, converting, and publishing business system APIs on demand, it achieves the automatic conversion of API capabilities into model-callable tools, improving interface access efficiency, call consistency, and model tool invocation accuracy. The objective of this invention can be achieved through the following technical solutions: This application provides an API tooling method based on a model context protocol, including: Step S1: In response to the business system access trigger event, register or discover the API access information of the business system to be accessed, and generate a business system access record; Step S2: Obtain and parse the interface document based on the business system access record, and generate an interface object set. Each interface object in the interface object set includes the business primary key, parameter definition information and response definition information. Step S3: Perform interface data synchronization processing on the interface object collection based on the business primary key, generate synchronized interface records, and convert the corresponding API interface capabilities into tool definitions that conform to the model context protocol based on the synchronized interface records, and generate tool records. Step S4: Based on the target AI client or target business scenario, determine the target tool set from the tool record, create a model context protocol service instance based on the target tool set, and establish a binding relationship between the service instance and the tool record; Step S5: Process the protocol request initiated by the AI ​​client based on the service instance and binding relationship, and execute tool query or tool call according to the protocol request. The tool query includes returning the tool information corresponding to the target tool set according to the binding relationship. The tool call includes determining the corresponding tool record according to the binding relationship, constructing an interface call request for the target business system based on the corresponding tool record, and returning the call result.

[0006] Further, step S1 includes, Identify the event type corresponding to the business system access trigger event. The event types include business system registration request events and service resource discovery events. When the event type is a business system registration request event, obtain the system identifier, service address, interface document address, authentication configuration information, and interface call configuration information from the business system registration request event to generate the API access registration result; When the event type is a service resource discovery event, the system listens for service resources with preset annotations through the container orchestration platform interface, extracts the system identifier, service address and interface configuration information from the service resource, determines the interface document address based on the interface configuration information, and generates API access discovery results. Based on the API access registration result or API access discovery result, query the interface description information, business semantic metadata and management attribute information corresponding to the business system to be accessed from the configuration management database to generate basic information of the business system, write the basic information of the business system into the business system repository, and generate business system access record.

[0007] Further, step S2 includes, Extract the system identifier and interface document address from the business system access record, and obtain the interface document corresponding to the business system to be accessed based on the interface document address; Identify the document version type corresponding to the interface document, and determine the target parser from the preset parser set based on the document version type; The target parser parses the interface document and extracts the request method, interface path, parameter definition information, response definition information, interface summary information, media type information and interface description information corresponding to each API interface in the interface document; Map system identifier, request method, interface path, parameter definition information, and response definition information to corresponding unified interface objects; The corresponding business primary key is generated based on the system identifier, request method, and interface path in the interface object. The interface objects with business primary keys are then aggregated to generate an interface object set.

[0008] Further, in step S3, interface data synchronization processing is performed on the interface object set based on the business primary key to generate synchronized interface records, including, Extract the business primary key corresponding to each interface object in the interface object collection, and perform deduplication processing on the interface object collection based on the business primary key to obtain a deduplicated interface object collection; Retrieve pre-stored historical interface records and match the deduplicated set of interface objects with the historical interface records according to the business primary key; When the target business primary key exists in the deduplication interface object set but not in the historical interface records, a new interface record is added based on the interface object corresponding to the target business primary key. When the target business primary key exists in both the deduplication interface object set and the historical interface records, and the corresponding interface content changes, the corresponding historical interface record is updated based on the interface object corresponding to the target business primary key. If the corresponding interface content does not change, the corresponding historical interface record is retained. When the target business primary key exists in the historical interface records but not in the deduplication interface object set, a deletion mark is added to the historical interface record corresponding to the target business primary key. Perform idempotent writes on newly added interface records, updated historical interface records, and historical interface records with added or deleted tags to generate synchronized interface records; The system calculates the total number of interfaces, the number of newly added interfaces, the number of updated interfaces, and the number of deleted interfaces for this data synchronization process, and generates synchronization result information.

[0009] Further, in step S3, based on the synchronized interface records, the corresponding API interface capabilities are converted into tool definitions conforming to the model context protocol, and tool records are generated, including... Receive the tool conversion request, extract the business primary key corresponding to the target API interface from the tool conversion request, and query the target synchronized interface record from the synchronized interface record based on the business primary key; Obtain the corresponding interface object of the target synchronized interface record, and extract the system identifier, request method, interface path, parameter definition information, response definition information, interface summary information, interface description information, and media type information from the interface object; The request method, system identifier, and interface path are concatenated in the order to generate a business primary key name for internal correlation queries. Then, the corresponding historical tool record is queried from the tool repository based on the business primary key name. If a corresponding historical tool record exists, the creation of the current MCP tool is refused, and a tool duplication error message is generated; if no corresponding historical tool record exists, the interface path is normalized, and a protocol tool name is generated based on the request method, system identifier, and normalized interface path. Based on parameter definition information, response definition information, interface summary information, interface description information, and media type information, tool input mode, tool output mode, tool description information, and tool call configuration are generated respectively, and an MCP tool definition conforming to the model context protocol is constructed. Associate the MCP tool definition with the business primary key, business primary key name, and target synchronized interface record. Write the associated MCP tool definition to the tool repository, set the activation status of the corresponding tool record to the enabled status, set the working status of the tool record to the used status, and generate the tool record.

[0010] Furthermore, based on parameter definition information, response definition information, interface summary information, interface description information, and media type information, tool input mode, tool output mode, tool description information, and tool invocation configuration are generated respectively, and an MCP tool definition conforming to the model context protocol is constructed, including, Based on the parameter positions corresponding to each interface parameter in the parameter definition information, the path parameters, query parameters, and request header parameters are mapped to the top-level attributes in the tool input mode, and the request body parameters are mapped to the top-level attributes in the tool input mode represented by the preset request body key name. The parameter modes corresponding to each interface parameter are recursively transformed to generate the tool input mode. Based on the response status code and response mode corresponding to each response in the response definition information, the target response mode is determined according to the preset response selection order, and the target response mode is recursively transformed to generate the tool output mode. Tool description information is generated based on the interface summary information and interface description information, and the tool description information is written into the tool title field and tool description field of the MCP tool definition respectively; Based on the request method, interface path, parameter definition information, and media type information, generate a tool call configuration that includes the request method, target path, path parameter list, query parameter template, request header template, request body template, request media type, and response media type.

[0011] Further, step S4 includes, Receive a Model Context Protocol (MTP) service creation request generated based on the target AI client or target business scenario, and obtain the tenant identifier, service identifier information, service capability declaration, client description information, extended metadata, candidate endpoint path, enable status, authentication switch and tool identifier list from the MTP service creation request. The service identifier information includes the service name, service title and service version. When the Model Context Protocol service creation request does not include a candidate endpoint path, a candidate endpoint path is generated based on the service name; when the Model Context Protocol service creation request includes a candidate endpoint path, the candidate endpoint path is obtained and normalized to obtain the target endpoint path. Based on the tenant identifier, a uniqueness check is performed on the target endpoint path within the corresponding tenant scope. If the target endpoint path fails the uniqueness check, the creation of the model context protocol service instance is terminated, and a duplicate endpoint path warning message is generated. If the target endpoint path passes the uniqueness check, the creation of the model context protocol service instance continues. Based on the tenant identifier and tool identifier list, the corresponding target tool records are queried in batches from the tool records belonging to the tenant identifier, and the queried target tool records are combined into a target tool set. A model context protocol service record is generated based on the service identifier information, service capability declaration, client description information, extended metadata, target endpoint path, enable status, and authentication switch. The model context protocol service record is written to the service repository, a model context protocol service instance is created, and the corresponding service identifier is obtained. When the enable status is not specified, the enable status is set to enable. The service access address corresponding to the Model Context Protocol service instance is generated based on the pre-configured Model Context Protocol service base address, tenant identifier, and target endpoint path, and the service access address is written into the Model Context Protocol service record. Based on the service identifier and the tool identifier corresponding to each target tool record in the target tool set, service tool association records are generated to establish a many-to-many binding relationship between the model context protocol service instance and each target tool record. The tool sorting information corresponding to each target tool record is written into the corresponding service tool association record. When the authentication switch is on, a random number is generated and URL-securely Base64 encoded to obtain the API Key plaintext. The API Key plaintext is then irreversibly hashed, and the generated API Key hash value is written into the model context protocol service record. The API Key plaintext is returned once in the creation response of the model context protocol service instance.

[0012] Further, step S5 includes, Receive protocol requests initiated by AI clients based on service access addresses and access credentials, and determine the corresponding model context protocol service instance based on the tenant identifier and endpoint path in the service access address. The protocol requests include tool query requests and tool invocation requests. The security filter extracts the access credentials carried in the protocol request and performs access verification on the access credentials according to the authentication configuration information corresponding to the model context protocol service instance. When the protocol request passes the access verification, the protocol request performs rate limiting check, access log recording and tracing context writing. Identify the request type corresponding to the protocol request, and route tool query requests to the tool query processing module and tool call requests to the tool call processing module; When the protocol request is a tool query request, the binding tool record is obtained according to the binding relationship corresponding to the model context protocol service instance. The target tool record that is available is filtered from the binding tool record, and a tool information list is generated based on the target tool record. The tool information list is then returned to the AI ​​client. When the protocol request is a tool invocation request, the target tool identifier is extracted from the tool invocation request, the target tool record corresponding to the target tool identifier is queried according to the binding relationship, and the tool invocation configuration is obtained from the target tool record; Based on the tool call parameters and tool call configuration carried in the tool call request, determine the request method, interface path, path parameters, query parameters, request header parameters, and request body parameters, and construct an interface call request for the target business system; Obtain the authentication configuration information, request timeout configuration information, and retry configuration information corresponding to the business system to which the target tool belongs; inject the authentication configuration information into the interface call request; and perform call control processing on the interface call request based on the request timeout configuration information and retry configuration information. A reactive, non-blocking approach is used to send an API call request to the target business system, obtain the API call result returned by the target business system, and then convert the API call result into a Model Context Protocol response and return it to the AI ​​client.

[0013] Furthermore, step S6 is included, which performs unified exception handling and observability monitoring during the operation process. Exceptions generated during the creation of model context protocol service instances, tool queries, tool calls, and access to business system interfaces are uniformly encapsulated and recorded in a structured log including trace identifiers, tool names, call times, and error codes. The operating status of the gateway service and dependent business systems is determined through health checks and collection of operating indicators. The corresponding service status, tool status, interface synchronization status, tool call success rate, exception records, and operating load are sent to the management interface for display.

[0014] Based on the same inventive concept, this application also provides an API tooling processing system based on a model context protocol, employing the API tooling processing method based on the model context protocol as described above, including: The system access module is used to respond to business system access trigger events, register or discover API access information of the business system to be accessed, and generate business system access records. The document parsing module is used to obtain and parse the interface documents based on the access records of the business system, and generate a set of interface objects. Each interface object in the set of interface objects includes a business primary key, parameter definition information and response definition information. The tool record generation module is used to perform interface data synchronization processing on the interface object collection based on the business primary key, generate synchronized interface records, and convert the corresponding API interface capabilities into tool definitions that conform to the model context protocol based on the synchronized interface records, and generate tool records. The tool binding module is used to determine the target tool set from the tool record based on the target AI client or target business scenario, create a model context protocol service instance based on the target tool set, and establish a binding relationship between the service instance and the tool record; The system call module is used to process protocol requests initiated by AI clients based on service instances and binding relationships. It executes tool queries or tool calls according to the protocol requests. Tool queries include returning tool information corresponding to the target tool set based on the binding relationship. Tool calls include determining the corresponding tool record based on the binding relationship, constructing an interface call request for the target business system based on the corresponding tool record, and returning the call result.

[0015] Compared with the prior art, the present invention has at least one of the following technical advantages: This application can automatically access and parse the API interfaces of business systems, and update them in a timely manner when the interfaces change. It can also automatically convert the API interfaces into tools that can be called by large language models, reducing manual adaptation and repetitive configuration. In addition, this application can release corresponding tools according to different AI clients or business scenarios, reducing model misselection and miscall. Through unified authentication, interface call control, exception handling and operation monitoring, it can improve the system's calling efficiency and operational stability. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below: Figure 1 This is a flowchart illustrating the steps of the API tooling method based on the model context protocol in this embodiment of the invention. Figure 2 This is a schematic diagram of the tool binding and calling architecture between the Model Context Protocol Service instance and the business system API in an embodiment of the present invention; Figure 3 This is an interaction sequence diagram of the business system registration and health check method in an embodiment of the present invention; Figure 4 This is an interactive sequence diagram of the business system OpenAPI interface document synchronization process in an embodiment of the present invention; Figure 5 This is an interactive sequence diagram of the batch generation and tool definition configuration process of the MCP tool in an embodiment of the present invention; Figure 6This is an interaction sequence diagram of the model context protocol service instance creation and tool binding process in an embodiment of the present invention; Figure 7 This is an interactive sequence diagram of the Model Context Protocol service publishing and tool invocation process in an embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the specific embodiments described herein are merely some embodiments of the present application, not all embodiments, and are only used to explain the present application and are not intended to limit the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0018] First Embodiment Existing technologies have proposed various solutions to address the application requirements mentioned in the background. For example, client-side call code or interface proxy code can be generated based on the OpenAPI or Swagger interface documentation provided by the business system, reducing the workload of developers manually writing HTTP request code; interface access requests can be uniformly received through an API gateway, and routing, authentication, rate limiting, timeout control, logging, and operation monitoring can be performed within the gateway; some API interfaces in the business system can be converted into Model Context Protocol tools, and the tool query and tool call capabilities can be provided to AI clients through an MCP Server; alternatively, developers can import the OpenAPI interface documentation of the business system into an interface management platform, select the interfaces to be exposed to AI clients, and configure the tool name, tool description, input parameters, and call address for each interface. After configuration, an MCP Server for AI clients is created, and the selected tools are bound to this MCP Server. When an AI client initiates a tool query request, the MCP Server returns a list of bound tools; when an AI client initiates a tool call request, the MCP Server calls the corresponding business system interface according to the tool configuration. This solution can, to a certain extent, realize the conversion of business system APIs into AI client tool capabilities.

[0019] However, the inventors discovered during practical application that the existing solutions primarily address the import, configuration, and invocation of individual API interfaces. When multiple business systems, multiple interface documentation versions, and multiple AI clients exist within an enterprise, a continuous and unified data association mechanism is still lacking between the various processing stages. This problem becomes more pronounced when business system interfaces change. For example, if the request parameter for the member query interface changes from member ID to mobile phone number, the order query interface adds an order status query parameter, or the product query interface adds an inventory field to its response structure, the original tool definitions typically do not automatically recognize the addition, update, or deletion of the corresponding interface. Developers need to re-examine the interface documentation and manually modify the corresponding tool definitions and tool invocation configurations. If not modified in time, the AI ​​client may still initiate tool invocations based on the old parameter structure, leading to parameter validation failures, interface access errors, or incorrect parsing of invocation results.

[0020] While some existing solutions can regenerate tool definitions based on the updated OpenAPI interface documentation, directly regenerating tool definitions may overwrite tool descriptions or parameter descriptions that developers have manually optimized. When the interface documentation is resynchronized, if the newly generated pattern is used to overwrite the original tool records, the aforementioned manually supplemented business semantics may be lost; if the original tool records are completely retained, the tool parameter structure may not be consistent with the updated API interface.

[0021] Furthermore, the relationship between the OpenAPI interface definition and the Model Context Protocol (MCP) tool definition is not a simple field copying relationship. The path parameters, query parameters, request header parameters, and request body parameters in the OpenAPI interface reside in different data structures, while the tool input mode used by the AI ​​client needs to organize these parameters according to a unified structure. The same API interface may also be configured with multiple response status codes and multiple response modes, requiring the determination of the target response used to generate the tool output mode. Simultaneously, during the actual invocation phase, the tool invocation parameters submitted by the AI ​​client need to be re-populated into the interface path, query string, request header, and request body, and authentication information needs to be dynamically injected according to the target business system's configuration, along with timeout and retry control. Moreover, when a large number of API interfaces are directly provided to the AI ​​client, the AI ​​client needs to choose from multiple tools with similar functions. For example, when member query, order query, product query, and inventory query interfaces are all provided by the same MCP Server, for an AI client that only performs member services, most of these tools are irrelevant to the current business scenario. The more irrelevant tools there are, the higher the likelihood that the AI ​​client will encounter ambiguity or select the wrong tool during the tool selection process. Different AI clients may have different interface access permissions. If all tools are provided to the outside world through the same service endpoint, it is not convenient to achieve independent service authentication, independent start and stop, and tenant data isolation.

[0022] Furthermore, relying solely on OpenAPI code generation, API gateway governance, or MCP tool deployment technologies is insufficient to fully address the seamless integration issues between interface discovery, version synchronization, tool definition conversion, tool grouping and deployment, and runtime invocation during the access process of multiple enterprise business systems. This embodiment does not merely encapsulate a single API interface into a tool; rather, it unifies and associates business system access, interface documentation parsing, interface data synchronization, MCP Tool definition generation, MCP Server creation, tool binding, protocol request processing, and business system interface invocation. This ensures that the tool definition maintains a correspondence with the original API interface and controls the scope of tool deployment based on different AI clients or business scenarios. like Figure 2 As shown in the diagram, the tool binding and invocation architecture between the Model Context Protocol (MCP) service instance and the business system API provided in this embodiment includes an AI client, a Hephaestus platform, and multiple business systems. The AI ​​client includes at least one of the following: an MCP client, a Dify agent platform, a Cursor development tool, a Spring AI client, and a LangChain client. At least one MCP service instance is created in the Hephaestus platform, and each MCP service instance is bound to one or more MCP tools. The MCP tools correspond to API interfaces in a customer relationship management system, an order management system, a product management system, or a container orchestration platform. The AI ​​client connects to the MCP service instance through the corresponding service access address and queries or invokes the MCP tools bound to it through the MCP service instance to access the API capabilities provided by the corresponding business system. The specific implementation is as follows. This application provides an API tooling method based on a model context protocol, including: Step S1: In response to the business system access trigger event, register or discover the API access information of the business system to be accessed, and generate a business system access record; Specifically, such as Figure 2As shown, the Hephaestus platform identifies the corresponding event type based on the source of the business system access trigger event. When the event type is a business system registration request event, the Hephaestus platform receives the business system registration request and extracts the system identifier (systemId), service address (baseUrl), interface document address (openapiUrl), authentication configuration information, and interface call configuration information from the request. The system identifier uniquely identifies the business system to be accessed; the service address determines the interface access entry point for the business system; the interface document address retrieves the publicly available OpenAPI interface documentation of the business system; the authentication configuration information records the authentication method and parameters required to access the business system; and the interface call configuration information records the timeout, retry conditions, and request control parameters during the interface call process. The Hephaestus platform performs integrity and format verification on the above information. After successful verification, it generates the API access registration result by manually registering the business system to be accessed through a preset REST interface.

[0023] When the event type is a service resource discovery event, the Hephaestus platform listens for Service resources with predefined annotations via the Kubernetes API. When a Service resource is created or updated, it reads the resource name, namespace, service port, and predefined annotation information. It then extracts the system identifier and interface configuration information from the predefined annotation information. Based on the Service resource's network access configuration and service port, it generates the corresponding service address and determines the interface document address based on the interface document path recorded in the interface configuration information, thus generating the API access discovery result.

[0024] After obtaining the API access registration or discovery results, the Hephaestus platform queries the Configuration Management Database (CMDB) for the interface description information, business semantic metadata, and management attribute information corresponding to the business system to be connected, based on the system identifier. The interface description information describes the business interfaces provided by the business system to be connected and their purpose; the business semantic metadata describes the business domain, business objects, and functional meaning of the business system to be connected; and the management attribute information describes the tenant, deployment environment, management entity, and operating status of the business system to be connected. Subsequently, the information retrieved from the CMDB is correlated with the API access registration or discovery results to generate basic information about the business system.

[0025] Furthermore, such as Figure 2As shown, after the business system access record is generated, the Hephaestus platform can return the business system creation result to the user. The creation result includes at least the record identifier and creation status corresponding to the business system access record. The Hephaestus platform can also send health check requests to the business system to be accessed according to a preset check cycle, based on the service address in the business system access record, and receive the health check results returned by the business system to be accessed. Based on the health check results, it determines whether the business system to be accessed is in an available state, and writes the corresponding availability status and check time into the business system access record. When the business system to be accessed is in an available state, subsequent execution of interface document retrieval and parsing is allowed; when the business system to be accessed is in an unavailable state, the corresponding abnormal status is recorded to avoid continuing to execute interface document retrieval operations when the business system is inaccessible.

[0026] Step S2: Obtain and parse the interface document based on the business system access record, and generate an interface object set. Each interface object in the interface object set includes the business primary key, parameter definition information and response definition information. Specifically, such as Figure 4 As shown, in step S2, the Hephaestus platform performs interface document acquisition and parsing processing based on the business system access records generated in step S1. Users can send OpenAPI synchronization requests to the Hephaestus platform, which carry the system identifier corresponding to the business system to be synchronized. The Hephaestus platform queries the corresponding business system access record from the business system repository based on the system identifier, and extracts the system identifier, service address, and interface document address from the business system access record.

[0027] The Hephaestus platform sends an API documentation retrieval request to the business system to be integrated based on the API documentation address, and receives the API documentation returned by the business system. The API documentation describes the API interfaces provided by the business system and can be in Swagger 2 or OpenAPI 3 format. The API documentation includes the request method, interface path, interface parameters, response status code, response data structure, interface summary, interface description, request media type, and response media type corresponding to the API interface. After retrieving the API documentation, the Hephaestus platform reads the version identifier field in the API documentation to identify the corresponding document version type. For example, if the API documentation contains a version identifier field indicating the Swagger version, the API documentation is identified as Swagger 2 type; if the API documentation contains a version identifier field indicating the OpenAPI version, the API documentation is identified as OpenAPI 3 type. The Hephaestus platform pre-configures parsers corresponding to different document version types, with the pre-set parser set including Swagger 2 parsers and OpenAPI 3 parsers. Based on the identified document version type, the corresponding target parser is selected from the preset parser set so that different versions of interface documents can be converted into interface data with a consistent structure, avoiding the need to set up separate subsequent processing procedures due to different interface document versions.

[0028] After determining the target resolver, the resolver iterates through the interface path nodes in the interface documentation, extracting the corresponding request method and interface path for each node. The request method indicates the HTTP request method used when calling the corresponding API interface, and the interface path indicates the access path of the API interface relative to the business system service address. The target access address of the corresponding API interface can be determined from the service address and interface path. For each API interface, the target resolver further parses the corresponding parameter definition information. Parameter definition information includes the parameter name, parameter location, parameter type, parameter description, whether it is required, and nested parameter structure for each interface parameter. Parameter location distinguishes path parameters, query parameters, request header parameters, and request body parameters, providing a data foundation for converting interface parameters in different locations into the corresponding tool input mode of the MCP Tool. For example, for the member query interface GET / members / {memberId}, the target parser can extract the request method GET, the interface path / members / {memberId}, and determine that memberId is a required path parameter in the interface path. For the order query interface POST / orders / query, the target parser can identify the page number parameter as a query parameter, the access token as a request header parameter, and the order status, query time range, and user identifier as request body parameters. Simultaneously, the target parser parses the response definition information corresponding to each API interface. The response definition information includes the response status code, response description, and response mode. The response mode is used to represent the data type and nested data structure of the interface call result. When the same API interface has multiple response status codes, each response status code and its corresponding response mode are saved separately so that the target response mode used to generate the tool's output mode can be determined according to the preset response selection order.

[0029] The target parser extracts the interface summary information, interface description information, and media type information for each API interface. The interface summary information briefly represents the business function provided by the API interface; the interface description information describes the applicable scenarios, calling conditions, or return content of the API interface; and the media type information includes the request media type and response media type, which are used to determine the data format used for subsequent business system interface call requests and interface call results.

[0030] After information extraction, the Hephaestus platform maps system identifiers, request methods, interface paths, parameter definitions, response definitions, interface summary information, interface description information, and media type information into a unified interface object according to a pre-defined unified interface data structure. Data with the same meaning but different storage locations or field names in different versions of the interface documentation are mapped to the same attributes in the unified interface object, so that Swagger 2 interface documentation and OpenAPI 3 interface documentation can use the same data structure for subsequent synchronization and tool conversion processes.

[0031] For example, in the Swagger 2 API documentation, request body parameters can be represented by the request body type parameter located in the parameter list, while in the OpenAPI 3 API documentation, request body parameters can be represented by a separate request body structure. The target parser extracts the above data respectively and maps it uniformly to the request body parameter definition in a unified API object. Similarly, the request media types and response media types in different documentation versions are also mapped to unified media type information.

[0032] Subsequently, the Hephaestus platform generates a corresponding business primary key based on the system identifier, request method, and interface path in each unified interface object. The business primary key is used to uniquely identify the corresponding API interface across multiple business systems and multiple interface documents, and can be combined according to the order of the system identifier, request method, and interface path.

[0033] For example, for a member query interface with system identifier crm-system, request method GET, and interface path / members / {memberId}, a corresponding business primary key can be generated based on the above three pieces of information. Even if there is an API interface with the same request method and interface path in another business system, the generated business primary key will be different due to the different system identifiers, thus avoiding confusion between interfaces with the same path in different business systems.

[0034] The Hephaestus platform writes the generated business primary key into the corresponding unified interface object, and aggregates all unified interface objects with the business primary key to generate an interface object set. This interface object set represents all API interfaces parsed from the interface documentation of the business system to be integrated, and serves as the basic input for interface data deduplication, historical interface matching, and the identification and processing of additions, updates, and deletions in step S3.

[0035] Step S3: Perform interface data synchronization processing on the interface object collection based on the business primary key, generate synchronized interface records, and convert the corresponding API interface capabilities into tool definitions that conform to the model context protocol based on the synchronized interface records, and generate tool records. Specifically, such as Figure 5 As shown, in step S3, the Hephaestus platform converts the interface capabilities corresponding to the target API interface into MCP tool definitions that conform to the Model Context Protocol based on the synchronized interface records obtained from the interface data synchronization process, and persists the MCP tool definitions as tool records.

[0036] Users can select one or more target APIs from the synchronized API records and send a tool conversion request to the Hephaestus platform. The tool conversion request carries the business primary key corresponding to each target API, which consists of the request method (httpMethod), the system identifier (systemId), and the interface path (path). After receiving the tool conversion request, the Hephaestus platform queries the corresponding target synchronized API record from the reactive API repository based on the business primary key and obtains the unified interface object OpenApiBo associated with the target synchronized API record.

[0037] When no target synchronized interface record corresponding to the business primary key is found, or when the found target synchronized interface record has been set to deleted status, the tool conversion for that target API interface is stopped, and a prompt message indicating that the interface record does not exist or is unavailable is generated. When a target synchronized interface record in an available state is found, the system identifier, request method, interface path, parameter definition information, response definition information, interface summary information, interface description information, and media type information are extracted from the corresponding unified interface object.

[0038] When generating the MCP tool name, the Hephaestus platform generates the business primary key name used for internal relational queries and the protocol tool name provided to the AI ​​client.

[0039] The business primary key name is constructed by concatenating the request method, system identifier, and original API path in the following order: {httpMethod}_{systemId}_{path}. The API path in the business primary key name retains its original form, preserving forward slashes, curly braces, and hyphens to ensure accurate association between the business primary key name and the original API interface. For example, for an API interface with a request method of GET, a system identifier of crm-system, and an API path of / members / {memberId}, the resulting business primary key name could be: GET_crm-system_ / members / {memberId}.

[0040] The Hephaestus platform queries the tool repository to see if a corresponding historical tool record exists based on the business primary key name. If a historical tool record with the same business primary key name already exists in the tool repository, it is determined that the target API interface has already been converted into an MCP tool. The platform refuses to create a duplicate MCP tool and returns a tool duplication error message. During this process, new business primary key names are not automatically generated by adding sequence numbers, random characters, or hash suffixes, further ensuring a clear and stable correspondence between an API interface and a tool record.

[0041] When a corresponding historical tool record is not found in the tool repository, the original interface path is normalized to obtain a normalized interface path called sanitizedPath. Specifically, forward slashes in the original interface path are replaced with hyphens, curly braces on both sides of the path parameters are removed, other characters that do not conform to the preset tool name rules are replaced with hyphens, multiple consecutive separators are merged into a single hyphen, and the beginning and end separators are removed.

[0042] Subsequently, the protocol tool name is generated according to the order of request method, system identifier, and normalized interface path, with the following format: {httpMethod}_{systemId}_{sanitizedPath}.

[0043] For example, for an API interface with a request method of GET, a system identifier of crm-system, and an interface path of / members / {memberId}, the interface path is normalized to members-memberId, and a protocol tool name is generated: GET_crm-system_members-memberId.

[0044] When the length of the protocol tool name exceeds a preset name length threshold, the name prefix consisting of the request method and system identifier is retained first, and the name portion corresponding to the normalized interface path is truncated. In this embodiment, the preset name length threshold can be 64 characters. When the name prefix itself has reached or exceeded the preset name length threshold, the complete protocol tool name is directly truncated. Thus, while limiting the length of the tool name, key identification information used to distinguish the request method and business system is retained as much as possible. After obtaining the protocol tool name, the Hephaestus platform generates the tool input schema (inputSchema) based on the parameter definition information in the unified interface object.

[0045] Specifically, the system iterates through each interface parameter in the parameter definition information and performs categorized mapping based on the parameter position field "in" corresponding to each interface parameter. For path parameters (parameter position: "path"), query parameters (parameter position: "query"), and request header parameters (parameter position: "header"), the corresponding parameter name is used as the attribute key, and they are directly mapped to the top-level attribute in the tool input mode. For the interface request body (requestBody), it is uniformly mapped to the top-level attribute in the tool input mode represented by the preset request body key name "request", and the complete JSON Schema structure corresponding to the request body is set as the attribute value of the "request" attribute.

[0046] For example, for the member query interface GET / members / {memberId}, the path parameter memberId is mapped to the top-level attribute memberId in the tool input pattern; the query parameter includeOrders is mapped to the top-level attribute includeOrders; the request header parameter X-Region is mapped to the top-level attribute X-Region; when the corresponding interface also has a request body containing mobile phone number, membership level, and registration time, the complete pattern of the request body is mapped to the top-level attribute request. When converting the parameter patterns corresponding to each interface parameter, a recursive conversion is performed according to the hierarchical structure of the parameter patterns. For object type parameters, the properties attribute set corresponding to the object type parameter is read, and recursive conversion is performed on each sub-attribute in the properties attribute set; for array type parameters, the items element pattern corresponding to the array type parameter is read, and recursive conversion is performed on the items element pattern; for basic type parameters, their parameter type and corresponding constraint information are extracted. During the recursive conversion process, the following information is retained for each parameter pattern: type, description, example value, enumeration value, format, minimum, maximum, minimum string length, maximum string length, properties, items, and required fields for nested objects.

[0047] When the original parameter description is empty, a pre-defined placeholder text "To be supplemented..." is filled in for the corresponding parameter, so that administrators can identify and supplement the business semantics corresponding to the parameter later. For the additionalProperties field, the corresponding boolean value is retained only when its field value is of boolean type; when the additionalProperties field is of object type or other non-boolean type, it is set to false. For default value fields included in the original parameter pattern, they are not retained when generating the tool input pattern to avoid the AI ​​client directly using default parameters that are not suitable for the current calling scenario.

[0048] For path parameters, query parameters, and request header parameters marked as required in the API documentation, the corresponding parameter names are added to the top-level `required` array of the tool input pattern. When the request body (`requestBody`) is marked as required, the default request body key name (`request`) is added to the top-level `required` array. The required relationships between fields within the request body are preserved in the nested pattern of the `request` attribute. After the above parameter classification, mapping, and recursive transformation processing, a tool input pattern is generated to constrain the parameters for calling AI client tools.

[0049] Furthermore, the Hephaestus platform generates the tool output schema based on the response definition information in the unified interface object.

[0050] Since the same API interface may have multiple response status codes and corresponding response modes, the target response mode is selected from the response definition information according to a preset response selection order. Specifically, the response mode with response status code 200 is selected first; if no response mode with response status code 200 exists, the response modes corresponding to other 2xx successful response status codes are traversed in a preset order; if no valid 2xx response mode exists, the response mode corresponding to the default response is selected; if the target response mode is still not obtained, any response mode with a valid schema is selected from the remaining response definitions as the target response mode.

[0051] After determining the target response pattern, recursive processing is performed on the target response pattern according to the recursive transformation method corresponding to the tool input pattern, preserving the data type, object attributes, array elements, nested structure, field description, and data format in the response pattern. In this embodiment, to adapt to the target MCP client's processing requirements for the tool output pattern, the top-level data type of the generated tool output pattern is set to an object type, and the complete nested object structure in the original response pattern is preserved. When the response definition information is empty, or when there is no valid response schema in the response definition information, the tool output pattern is set to null. For example, when the target API interface is a file download interface, the response media type is application / octet-stream, or the target API interface does not have a response body, the corresponding tool output pattern may not be generated. Subsequently, the Hephaestus platform generates tool description information based on the interface summary information and interface description information in the unified interface object. When only interface summary information exists, it is directly used as the tool description information; when only interface description information exists, it is directly used as the tool description information; when both interface summary and interface description information exist, they are concatenated in the format of "interface summary information: interface description information"; when both interface summary and interface description information are empty, the tool description information is set to an empty string. The generated tool description information is simultaneously written to the tool title field (title) and the tool description field (description) defined in the MCP tool, enabling the AI ​​client to determine the business function of the corresponding tool based on the unified tool description. In this embodiment, the tool description information is generated from the interface summary and interface description information in the OpenAPI operation object, without using business semantic metadata from the CMDB to overwrite the tool description information.

[0052] Furthermore, the Hephaestus platform constructs a corresponding tool invocation configuration (HttpConfig) based on the unified interface object. This configuration is used to convert tool invocation parameters into HTTP interface invocation requests for the target business system upon receiving a tool invocation request from an AI client.

[0053] The tool invocation configuration includes the request method `method`, target path `urlPath`, path parameter list `pathParams`, query parameter template `queryParams`, request header template `headers`, request body template `body`, request media type list `consumes`, and response media type list `produces`. Specifically, the request method `httpMethod` in the unified interface object is converted to uppercase and written into the request method `method`; the original interface path `path` is written into the target path `urlPath`, with the target path retaining path parameter placeholders; and path parameter names enclosed in curly braces are extracted from the target path using preset path parameter extraction rules to generate the path parameter list `pathParams`. For example, regular expressions can be used. Extract the path parameter names from the target path.

[0054] For query parameters located in the query position, a query parameter template is generated based on the name of each query parameter. The corresponding parameter value in the query parameter template uses the parameter placeholder in the form of {{paramName}}. For request header parameters located in the header position, a request header template is generated based on the name of each request header parameter. The corresponding request header parameter value also uses the parameter placeholder in the form of {{paramName}}.

[0055] The request header template also includes three standard request headers: Content-Type, Accept, and User-Agent. The value of the Content-Type header is determined by the request media type (consumes) in the unified interface object, while the value of the Accept header is determined by the response media type (produces). When the unified interface object does not specify a corresponding media type, the request and response media types are set to application / json by default.

[0056] When the target API interface has a request body, the request body template body is set to {{request}}, so that the runtime can read the data corresponding to the request from the tool call parameters submitted by the AI ​​client and write it into the request body of the actual interface call request.

[0057] It should be noted that the authentication method, request timeout configuration, and retry configuration of the business system are not fixedly written into the tool call configuration. Authentication methods can include NONE, BASIC, BEARER, and API_KEY; request timeout configurations can include requestTimeoutMillis; and retry configurations can include retryMaxAttempts and retryBackoffMillis. All of the above configuration information is uniformly stored in the HTTP configuration corresponding to the business system to which the tool record belongs. When the tool call is actually executed, the MCP runtime dynamically obtains and injects the actual interface call request based on the system identifier associated with the target tool record. Therefore, when the authentication credentials, timeout, or retry policy of the business system changes, it is not necessary to modify the corresponding tool records one by one.

[0058] After generating the protocol tool name, tool input mode, tool output mode, tool description information, and tool invocation configuration, the Hephaestus platform constructs the MCP tool information based on the above content, forming an MCP tool definition that conforms to the Model Context Protocol. The MCP tool definition includes at least the protocol tool name, tool title, tool description, tool input mode, tool output mode, and tool invocation configuration.

[0059] Subsequently, the MCP tool definition is associated with the business primary key, business primary key name, and target synchronized interface record corresponding to the target API interface. The associated MCP tool definition is then persistently written to the tool repository, generating a tool record. The tool record may also include a tool identifier, system identifier, synchronized interface record identifier, creation time, update time, activation status (isActive), and working status (status).

[0060] When a tool record is created for the first time, its activation status (isActive) is set to true by default, and its working status (status) is set to USING, indicating that the corresponding tool is enabled and usable by default. Only tool records with an activation status of true, a working status of USING, and whose corresponding synchronized interface records are currently valid can be used as usable tools in subsequent model context protocol service instance creation, tool querying, and tool invocation processes.

[0061] For example, such as Figure 5As shown, users can send a batch creation request for MCP tools containing multiple target interface identifiers to the Hephaestus platform. The Hephaestus platform retrieves the corresponding synchronized interface records and unified interface objects based on each target interface identifier, and sequentially performs duplicate validation, tool name generation, tool input mode conversion, tool output mode conversion, tool description information generation, and tool call configuration construction. It then writes the generated tool records into the tool repository and returns a list of corresponding tool identifiers to the user.

[0062] Furthermore, users can send manual optimization instructions to the Hephaestus platform based on the tool identifier to manually adjust the tool description information or parameter semantic descriptions in the tool record. For example, the parameter description for the parameter "phone" can be changed from "To be supplemented..." to "Registered mobile phone number used to query member information". After receiving the manual optimization instruction, the Hephaestus platform updates the description field in the corresponding tool record and records the manually optimized description information and its attribute path in the tool input mode or tool output mode.

[0063] When the interface documentation of the business system changes and the synchronized interface record generated in step S3 is updated, the Hephaestus platform publishes an interface change event through the in-process reactive event bus OpenApiEventBus. The interface change event carries at least the identifier of the changed synchronized interface record or its corresponding business primary key. The tool update processing module queries the tool record associated with the synchronized interface record based on the interface change event and automatically triggers the synchronization update of the tool record, without requiring the user to re-initiate a tool conversion request.

[0064] During the tool synchronization update, the corresponding unified interface object is re-obtained based on the changed synchronized interface records, and the candidate protocol tool name, candidate tool input mode, candidate tool output mode, candidate tool description information, and candidate tool invocation configuration are regenerated according to the aforementioned tool generation rules. The candidate tool input mode and candidate tool output mode are based on the parameter structure and response structure in the new version of the interface document, and are used to reflect the latest structure of the target API interface.

[0065] Subsequently, manually optimized tool descriptions and parameter descriptions are extracted from the original tool records, and the attribute paths corresponding to each manually optimized description are determined. Based on the attribute paths, the corresponding attributes are recursively queried in the regenerated candidate tool input and output modes. When an attribute corresponding to the attribute path exists in the new version mode structure, the manually optimized description field in the original tool records is migrated and written into the corresponding attribute. Furthermore, while maintaining the latest interface structure, the manually supplemented business semantic descriptions are retained.

[0066] In addition to determining whether the attribute paths are the same, it can also determine whether the data types corresponding to the original attribute and the new attribute are the same, or whether they meet the preset type compatibility relationship; only when the attribute paths are the same and the parameter types are the same or compatible, the corresponding manually optimized description information is migrated, so as to reduce the situation where the old description is incorrectly written into the new parameter after the interface structure changes.

[0067] For the tool name (name), tool title (title), parameter type (type), object nesting structure (properties), array element structure (items), and required field, the structural information regenerated according to the new version of the interface documentation will prevail. Manual modifications to these structural fields in historical tool records will not be retained. The tool record's activation status (isActive) will retain its original state before the update and will not be reset to true due to interface synchronization updates.

[0068] After the differential merging is completed, the updated protocol tool name, tool input mode, tool output mode, tool description information, and tool call configuration are used to overwrite the current tool record in the tool repository. In this embodiment, no separate tool historical version record is generated; each synchronization update directly overwrites the current version of the tool record.

[0069] When a synchronized interface record is marked for deletion or its interface status is set to DELETED, the Hephaestus platform sets the working status of the corresponding tool record to DELETED based on the association between the synchronized interface record and the tool record, without physically deleting the tool record. Subsequent tool list queries, model context protocol service tool bindings, or tool calls will filter tool records with a working status of DELETED to prevent AI clients from continuing to query or call API interfaces that have been deleted by the business system.

[0070] When a deleted API interface reappears in subsequent API documentation and is restored to its current valid state, the corresponding tool record can be regenerated or restored based on the latest synchronized API record. By retaining the tool record and its association with the service instance, the workload of reconfiguring tool binding relationships can be reduced after the interface is restored.

[0071] Step S4: Based on the target AI client or target business scenario, determine the target tool set from the tool record, create a model context protocol service instance based on the target tool set, and establish a binding relationship between the service instance and the tool record; Specifically, such as Figure 6As shown, in step S4, the Hephaestus platform creates a Model Context Protocol Service instance (hereinafter referred to as MCP Server) based on the target AI client or the target business scenario, and binds the target tool record to the MCP Server so that the AI ​​client can query and call the tools configured in the MCP Server through the corresponding service access address.

[0072] Users select one or more target tool records from the tool repository based on the target AI client's business functions, access permissions, or actual application scenarios, and send an MCP Server creation request to the Hephaestus platform. The MCP Server creation request includes tenant identifier, service identifier information, service capability statement, client description information, extended metadata, candidate endpoint paths, enable status, authentication switch, and a list of tool identifiers to be initially bound.

[0073] The service identification information is represented by the `implementation` field, including the service name, service title, and service version; the service capability declaration is represented by the `capabilities` field, including at least one of the following: tool invocation capabilities (`tools`), prompt invocation capabilities (`prompts`), and resource access capabilities (`resources`); the client instruction information is represented by the `instructions` field, which explains to the AI ​​client the purpose, applicable scenarios, or usage constraints of the corresponding MCP Server; the extended metadata is represented by the `meta` field, which stores service categories, business tags, and other extended information; the candidate endpoint path is represented by the `serverPath` field; the enabled status is represented by the `isActive` field, which is set to `true` by default; the authentication switch is represented by the `enableAuth` field; and the tool identifier list is represented by the `mcpToolIds` field.

[0074] After receiving an MCP Server creation request, the Hephaestus platform determines candidate endpoint paths. If the MCP Server creation request does not include candidate endpoint paths, it automatically generates them based on the service name. If the MCP Server creation request includes candidate endpoint paths, it retrieves the candidate endpoint paths submitted by the user. Regardless of whether the candidate endpoint paths are automatically generated by the system or submitted by the user, they are normalized to obtain the target endpoint path.

[0075] When generating the target endpoint path, convert all letters in the service name or candidate endpoint path to lowercase, retaining only letters, numbers, spaces, forward slashes, underscores, and hyphens. Replace spaces, underscores, and forward slashes with hyphens, merge consecutive hyphens into a single hyphen, remove leading and trailing hyphens, and add a leading forward slash to the processed string. For example, if the service name is "Order Management", the generated target endpoint path will be / order-management.

[0076] After obtaining the target endpoint path, the Hephaestus platform performs a uniqueness check on the target endpoint path within the corresponding tenant based on the tenant identifier. If an MCP Server record with the same target endpoint path already exists within the same tenant, the target endpoint path is determined to have failed the uniqueness check, the creation of the current MCP Server is terminated, and a duplicate endpoint path warning message is returned. If no identical target endpoint path exists within the same tenant, the target endpoint path is determined to have passed the uniqueness check, and the MCP Server creation process continues.

[0077] The same target endpoint path is allowed to exist between different tenants. For example, different tenants can all use / order-management as the endpoint path. Since the subsequently generated service access address contains different tenant identifiers, no access conflict will occur. The Hephaestus platform can also provide an endpoint path availability check interface, which allows the management interface to return in real time whether the corresponding path is available within the current tenant scope when the user enters a candidate endpoint path.

[0078] Once the target endpoint path passes the uniqueness check, the Hephaestus platform queries the tool repository in batches for target tool records that belong to the current tenant and match the tool identifier list, based on the tenant identifier and tool identifier list, and then assembles the queried target tool records into a target tool set.

[0079] MCP Server is a manually categorized logical tool grouping container. The target tool set is freely selected by the user based on the target AI client or target business scenario. The Hephaestus platform does not automatically group tools according to business scenario, user role, business system, or system domain. Each tool record is assigned to a system ID (systemId) corresponding to the business system and corresponds to an OpenAPI interface endpoint.

[0080] For example, in a membership service scenario, users can choose from membership information query tools, membership points query tools, and membership level adjustment tools to create a membership service MCP Server; in an order service scenario, they can choose from order query tools, order cancellation tools, and logistics information query tools to create an order service MCP Server. By dividing the service into multiple MCP Servers, different AI clients only receive a small number of tools required for the current business scenario, reducing the decision complexity of the model when choosing from a large number of tools and minimizing accidental calls to interfaces of unrelated business systems.

[0081] After determining the target toolset, the Hephaestus platform generates Model Context Protocol (MCP) service records based on service identification information, service capability declarations, client description information, extended metadata, target endpoint paths, activation status, and authentication switches. These MCP service records are then persistently written to the service repository, and the corresponding MCP Server is created, obtaining its service identifier. When the activation status is not specified in the MCP Server creation request, the activation status `isActive` is set to `true` by default.

[0082] Subsequently, the service access address corresponding to the MCP Server is generated based on the pre-configured Model Context Protocol (MCP) service base address, tenant identifier, and target endpoint path. The MCP service base address is dynamically specified by the configuration item hephaestus.mcp.baseUrl, and is not fixed in the program code.

[0083] In one implementation, the MCP protocol routing takes the form of: / mcp / {tenantId}{serverPath}.

[0084] The corresponding complete service access address takes the following form: {baseUrl} / mcp / {tenantId}{serverPath}.

[0085] For example, when the base address of the Model Context Protocol service is https: / / mcp.example.com, the tenant identifier is tenant-abc, and the target endpoint path is / order-management, the generated service access address is: https: / / mcp.example.com / mcp / tenant-abc / order-management.

[0086] The service access address includes a tenant identifier, isolating MCP Servers for different tenants at the access path level. In this embodiment, a version prefix in the form of / v1 / is not set in the service access address; the service version is recorded through the service version field in the service identifier information. After generating the service access address, it is written to the corresponding Model Context Protocol service record.

[0087] Furthermore, the Hephaestus platform generates service tool association records based on the service identifier corresponding to the MCP Server and the tool identifier corresponding to each target tool record in the target tool set. These service tool association records are then written into the service tool association table hephaestus_mcp_server_tool, establishing a many-to-many binding relationship between the MCP Server record and each target tool record.

[0088] Through many-to-many binding relationships, a single MCP Server can bind to multiple tool records, and the same tool record can also be bound to multiple different MCP Servers simultaneously. For example, a member query tool can be bound to both a member service MCP Server and a comprehensive customer service MCP Server without repeatedly generating tool records with identical content. The tool sorting information for each target tool record in different MCP Servers is stored in the corresponding service tool association record via the `sort_order` field. Therefore, the same tool record can have different sorting orders in different MCP Servers, and the tool sorting in each MCP Server is independent and does not affect each other. During the tool query and service tool association record generation process, both the tenant identifier of the MCP Server and the tenant identifier of the tool record are carried for double filtering, and a binding relationship is established only when the MCP Server and the target tool record belong to the same tenant. Different tenants do not share the same tool record, nor are cross-tenant service tool association relationships established.

[0089] Furthermore, different MCP Servers can be configured with independent authentication credentials and activation status, allowing for the allocation of different access permissions to different AI clients or applications. When any MCP Server is deactivated, only the access service for the corresponding business scenario is stopped; it does not affect the continued operation of other MCP Servers.

[0090] When the authentication switch enableAuth is enabled, the Hephaestus platform generates an API Key for the current MCP Server. In one implementation, a 32-byte random number is generated using the SecureRandom generator, and the random number is then URL-securely Base64 encoded to obtain a plaintext API Key of 43 characters.

[0091] Subsequently, the BCrypt algorithm with a cost parameter of 10 is used to perform irreversible hashing on the API Key plaintext, and the generated API Key hash value is written to the api_key_hash field in the model context protocol service record. Only the API Key hash value is stored in the service repository; the API Key plaintext is not stored.

[0092] The API Key in plaintext is returned to the user only once in the creation response after the MCP Server is successfully created. Subsequent queries to retrieve MCP Server information will set the corresponding API Key field to empty, and the plaintext API Key will no longer be returned or displayed. When the authentication switch is off, no API Key is generated, and the API Key hash value is not written to the Model Context Protocol Service record, allowing the corresponding MCP Server to operate in public access mode.

[0093] Furthermore, the Hephaestus platform supports dynamic binding and unbinding of tools on already created MCP Servers. When a tool binding request is received, the corresponding service-tool association record is queried based on the tenant identifier, service identifier, and tool identifier. If the corresponding service-tool association record does not exist, a new service-tool association record is created. If the corresponding service-tool association record already exists, the original binding result is returned directly without duplicate insertion, thus ensuring the idempotency of the tool binding operation.

[0094] When a tool unbinding request is received, the matching service tool association record is deleted based on the tenant identifier, service identifier, and tool identifier. If no matching service tool association record exists, the number of affected records is returned as zero, without throwing a processing exception, thus ensuring the idempotency of the tool unbinding operation.

[0095] When an MCP Server update request is received, it is determined whether the update request includes the updated tool identifier list. If the tool identifier list is not null, the existing service tool association records of the current MCP Server are first deleted, and then the service tool association records are regenerated based on the updated tool identifier list. If the tool identifier list is null, i.e., no tool identifier list is provided, the existing service tool association records of the current MCP Server remain unchanged.

[0096] Starting and stopping the MCP Server is achieved by updating the `isActive` field in the Model Context Protocol Service record. When a service shutdown request is received, the enabled status of the corresponding MCP Server is set to `false`; when a service enable request is received, the enabled status of the corresponding MCP Server is set to `true`. The security filter queries the enabled status of the corresponding MCP Server in real time each time a new protocol request is received. If the MCP Server is in a disabled state, the new protocol request is immediately rejected and a 403 Access Forbidden response is returned, without using the delayed service state cache.

[0097] It should be noted that when a bound target tool record is deactivated, deleted, or the status of the corresponding synchronized interface record changes, the associated service tool record corresponding to that target tool record is not deleted. During operation, the tool query processing module and the tool call processing module perform triple status filtering on the target tool records bound to the MCP Server, only identifying tool records with an enabled status of isActive (true), a working status of USING, and a corresponding synchronized interface record status of LATEST as available tools.

[0098] If the target tool record does not meet any of the above conditions, the return or invocation of the target tool to the AI ​​client will stop, but the corresponding service tool association record will continue to be retained. When the target tool record meets the conditions of being enabled (true), working (USING), and the corresponding synchronized interface record being in the LATEST state again, the query and invocation of the corresponding tool will be automatically restored based on the retained service tool association record, without the need to re-execute the tool binding operation.

[0099] Furthermore, during the operation of the MCP Server, the security filter McpSecurityWebFilter extracts the access credential to be verified from the X-API-Key header each time a protocol request is received, and verifies the access credential using ApiKeyVerifier. During verification, a SHA-256 digest is calculated on the access credential to be verified to obtain a token digest, and the corresponding authentication cache scope is determined based on the tenant identifier, target endpoint path, and API Key hash version. Subsequently, the token digest is queried in the Caffeine cache set corresponding to the authentication cache scope. When the token digest is found in the Caffeine cache set, the access credential is directly verified. When the token digest is not found in the cache, a ConcurrentHashMap is used to check if there is an in-transit verification task for the same token digest. If an identical in-transit verification task exists, its verification result is reused; otherwise, a new verification task is created, and the access credential to be verified is matched against the API Key hash value in the service record using BCrypt. BCrypt matching is performed only when there is a cache miss and no reusable in-transit verification result exists, reducing the processing overhead caused by repeatedly performing BCrypt calculations in high-concurrency request scenarios. Once the access credential to be verified passes the BCrypt matching verification, its corresponding SHA-256 digest is written to the Caffeine cache set for fast matching in subsequent protocol requests. The TTL and cache capacity of the Caffeine cache can be adjusted through configuration options. During APIKey canary deployment, the authentication cache scope corresponding to the same tenant identifier, target endpoint path, and hash version can simultaneously store token digests corresponding to multiple valid access credentials, ensuring that both the old and new API keys can be verified within the preset canary deployment period.

[0100] Furthermore, the Hephaestus platform supports API Key reset and authentication clearing. Upon receiving an API Key reset request, it regenerates the plaintext API Key and its corresponding hash value, updates the Model Context Protocol Service record with the new API Key hash value, and returns the new plaintext API Key only once in the API Key reset response. Upon receiving an authentication clearing request, it sets the api_key_hash field in the corresponding Model Context Protocol Service record to null and clears the corresponding API Key verification cache, enabling the MCP Server to switch to a public access state that does not require API Key verification.

[0101] Step S5: Process the protocol request initiated by the AI ​​client based on the service instance and binding relationship, and execute tool query or tool call according to the protocol request. The tool query includes returning the tool information corresponding to the target tool set according to the binding relationship. The tool call includes determining the corresponding tool record according to the binding relationship, constructing an interface call request for the target business system based on the corresponding tool record, and returning the call result.

[0102] Specifically, such as Figure 7 As shown, in step S5, the AI ​​client connects to the corresponding Model Context Protocol service instance through the service access address generated in step S4 and initiates a protocol request to the Hephaestus platform. The AI ​​client can be Dify, Cursor, Spring AI client, LangChain client, or other clients that support the Model Context Protocol. The protocol request includes tool query requests and tool invocation requests. The AI ​​client initiates the protocol request based on the pre-configured service access address. When the authentication switch of the corresponding Model Context Protocol service instance is in the on state, the AI ​​client also carries access credentials in the preset request header of the protocol request, such as writing the API Key in the X-API-Key request header; when the authentication switch is in the off state, the protocol request may not carry access credentials.

[0103] Upon receiving a protocol request, the Hephaestus platform parses the tenant identifier and endpoint path from the service access address. Based on these identifiers, it then queries the service repository for the corresponding Model Context Protocol (MTP) service record to determine the MTP service instance that the current request needs to access. By using both the tenant identifier and endpoint path for the query, confusion can be avoided between MTP service instances with the same endpoint path from different tenants.

[0104] After identifying the Model Context Protocol (MCP) service instance, the security filter queries the MCP service instance's enabled status. If the enabled status is disabled, the protocol request is directly rejected and an access denial message is returned; if the enabled status is enabled, the authentication configuration information of the MCP service instance is further read.

[0105] When the authentication switch is on, the security filter extracts the access credentials from the X-API-Key request header of the protocol request and performs access verification on the access credentials according to the aforementioned API Key verification method. If the protocol request does not carry access credentials or the access credentials fail verification, the subsequent processing of the current protocol request is terminated, and an authentication failure message is returned to the AI ​​client; if the access credentials pass verification, the protocol request is allowed to enter the subsequent request processing chain. When the authentication switch is off, access credential verification can be skipped.

[0106] After the protocol request passes access verification, the Hephaestus platform performs rate limiting checks on the protocol request based on preset rate limiting rules corresponding to the tenant identifier, service identifier, or access credentials. When the current number of requests has not reached the corresponding rate limiting threshold, the protocol request is allowed to continue; when the current number of requests reaches the rate limiting threshold, the protocol request is rejected or delayed, and a request frequency limitation information is returned. Simultaneously, a trace ID is generated or extracted for the protocol request, written into the request context, and continuously transmitted during subsequent tool queries, tool calls, and business system interface accesses. The Hephaestus platform also records corresponding access logs, which may include the tenant identifier, service identifier, endpoint path, request type, request time, access result, and trace ID, further establishing the association between AI client protocol requests and subsequent business system interface calls.

[0107] Subsequently, the Hephaestus platform identifies the request type corresponding to the protocol request. When the protocol request is used to obtain tool information provided by the current model context protocol service instance, it is identified as a tool query request and routed to the tool query processing module; when the protocol request is used to invoke a specified tool, it is identified as a tool invocation request and routed to the tool invocation processing module. When the protocol request is a tool query request, the tool query processing module queries the service tool association record corresponding to the model context protocol service instance from the service identifier and tenant identifier corresponding to the model context protocol service instance, and obtains the bound tool record based on the service tool association record.

[0108] After obtaining the bound tool records, the system performs a running status filter on each bound tool record, identifying only tool records with an "isActive" status of true, a "status" status of USING, and a corresponding synchronized interface record status of LATEST as available target tool records. For tool records that do not meet the above conditions, their service tool association records are retained, but they are not returned to the AI ​​client. The tool query processing module sorts the target tool records according to the tool sorting information in each service tool association record, and generates a tool information list based on the protocol tool name, tool title, tool description, tool input mode, and tool output mode in each target tool record. This tool information list is then encapsulated into a model context protocol response and returned to the AI ​​client. Therefore, the AI ​​client can only query tools that are currently bound to and available within the current model context protocol service instance, and cannot query tools from other tenants, other model context protocol service instances, or tools that are currently disabled or deleted.

[0109] When the protocol request is a tool invocation request, the tool invocation processing module extracts the target tool identifier and tool invocation parameters from the request. The target tool identifier can be the protocol tool name or the tool record identifier, and the tool invocation parameters are parameter data generated by the AI ​​client based on the target tool's tool input mode.

[0110] The tool invocation processing module queries the service tool association record based on the tenant identifier, the service identifier corresponding to the model context protocol service instance, and the target tool identifier to determine whether the target tool has been bound to the current model context protocol service instance. If no corresponding service tool association record exists, the tool invocation request is rejected, and a message indicating that the tool is not bound or is inaccessible is returned.

[0111] If a corresponding service tool association record exists, further query the target tool record and determine whether the target tool record meets the availability conditions of being enabled (true), working (USING), and the corresponding synchronized interface record being in the LATEST state. If the target tool record does not meet the availability conditions, stop executing the tool call and return a tool unavailable message; if the target tool record meets the availability conditions, read the tool call configuration HttpConfig from the target tool record.

[0112] The tool invocation configuration includes the request method (method), target path (urlPath), path parameter list (pathParams), query parameter template (queryParams), request header template (headers), request body template (body), request media type (consumes), and response media type (produces). The tool invocation processing module constructs an interface invocation request for the target business system based on the tool invocation configuration and parameters.

[0113] Specifically, the request method is read from the tool call configuration and used as the HTTP request method corresponding to the interface call request; the target path with reserved path parameter placeholders is read, and the corresponding path parameter values ​​are extracted from the tool call parameters according to the path parameter list. The path parameter placeholders in the target path are replaced with the actual parameter values ​​to generate the actual interface path. For example, when the target path is / members / {memberId}, the path parameter list includes memberId, and the value of memberId in the tool call parameters submitted by the AI ​​client is 10001, the target path is converted to / members / 10001.

[0114] For query parameters, the corresponding query parameter values ​​are read from the tool call parameters based on the parameter placeholders in the query parameter template and written into the query string of the API call request. For request header parameters, the corresponding request header parameter values ​​are read from the tool call parameters based on the request header template and written into the request header of the API call request. For example, when the query parameter template includes `status={{status}}`, the parameter value corresponding to `status` is read from the tool call parameters and written into the query string; when the request header template includes `X-Region={{region}}`, the parameter value corresponding to `region` is read from the tool call parameters and written into the `X-Region` request header.

[0115] For the request body parameters, when the request body template in the tool call configuration is {{request}}, the data corresponding to the fixed key name 'request' is extracted from the tool call parameters, and the data is serialized according to the corresponding request media type and written into the request body of the interface call request. The interface call request can also set Content-Type and Accept request headers according to the request media type and response media type, and write the preset User-Agent request header.

[0116] After populating the path parameters, query parameters, request header parameters, and request body parameters, based on the system identifier in the target tool record, the business system access record corresponding to the target business system to which the target tool record belongs is retrieved from the business system repository. The service address, authentication configuration information, request timeout configuration information, and retry configuration information are then read from the business system access record. The service address is concatenated with the actual interface path to generate the actual interface call address corresponding to the target business system. Subsequently, the authentication method adopted by the target business system is determined based on the authentication configuration information, and the corresponding authentication information is dynamically injected into the interface call request. For example, when the authentication method is BASIC, the encoded username and password information is written into the interface call request; when the authentication method is BEARER, an access token is written into the preset authentication request header; when the authentication method is API_KEY, the API Key is written into the specified request header or query parameter according to the authentication configuration; when the authentication method is NONE, no authentication information is injected into the interface call request.

[0117] The Hephaestus platform also sets a maximum waiting time for API call requests based on request timeout configuration information, and determines the maximum number of retries and retry interval based on retry configuration information. When the target business system does not return a result within the preset time, the current call is terminated or the API call request is resent according to the preset retry rules; when a valid call result is still not obtained after the maximum number of retries is reached, retries are stopped and an API call failure result is generated.

[0118] After completing the API call request construction and call control configuration, the Hephaestus platform sends API call requests to the target business system using a reactive, non-blocking processing approach. While waiting for the target business system to return the API call result, the current processing thread is not blocked, allowing the same runtime environment to continue processing protocol requests initiated by other AI clients, further adapting to concurrent tool call scenarios. Upon receiving the API call request, the target business system executes the corresponding business processing based on the request method, API path, and call parameters, and returns the API call result to the Hephaestus platform. The API call result may include a response status code, response headers, and a response body. Upon receiving the API call result, the Hephaestus platform parses the response body according to the response media type recorded by the target tool, and encapsulates the response status, response content, and necessary call information into a Model Context Protocol (MTP) response. When the API call succeeds, the business data returned by the target business system is written into the MTP response and returned to the AI ​​client; when the API call fails, the error information returned by the business system is converted into a unified error message and returned to the AI ​​client, without directly exposing the underlying program stack.

[0119] Second Embodiment Based on the same inventive concept, this application also provides an API tooling processing system based on a model context protocol, employing the API tooling processing method based on the model context protocol as described above, including: The system access module is used to respond to business system access trigger events, register or discover API access information of the business system to be accessed, and generate business system access records. The document parsing module is used to obtain and parse the interface documents based on the access records of the business system, and generate a set of interface objects. Each interface object in the set of interface objects includes a business primary key, parameter definition information and response definition information. The tool record generation module is used to perform interface data synchronization processing on the interface object collection based on the business primary key, generate synchronized interface records, and convert the corresponding API interface capabilities into tool definitions that conform to the model context protocol based on the synchronized interface records, and generate tool records. The tool binding module is used to determine the target tool set from the tool record based on the target AI client or target business scenario, create a model context protocol service instance based on the target tool set, and establish a binding relationship between the service instance and the tool record; The system call module is used to process protocol requests initiated by AI clients based on service instances and binding relationships. It executes tool queries or tool calls according to the protocol requests. Tool queries include returning tool information corresponding to the target tool set based on the binding relationship. Tool calls include determining the corresponding tool record based on the binding relationship, constructing an interface call request for the target business system based on the corresponding tool record, and returning the call result.

[0120] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the foregoing claims.

[0121] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0122] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for API tooling based on model context protocols, characterized in that, include, Step S1: In response to the business system access trigger event, register or discover the API access information of the business system to be accessed, and generate a business system access record; Step S2: Obtain and parse the interface document according to the access record of the business system, and generate an interface object set. Each interface object in the interface object set includes a business primary key, parameter definition information and response definition information. Step S3: Perform interface data synchronization processing on the interface object set based on the business primary key, generate synchronized interface records, and convert the corresponding API interface capabilities into tool definitions that conform to the model context protocol according to the synchronized interface records, and generate tool records. Step S4: Based on the target AI client or target business scenario, determine the target tool set from the tool record, create a model context protocol service instance based on the target tool set, and establish a binding relationship between the service instance and the tool record; Step S5: Based on the service instance and the binding relationship, process the protocol request initiated by the AI ​​client, and perform tool query or tool call according to the protocol request. The tool query includes returning tool information corresponding to the target tool set according to the binding relationship. The tool call includes determining the corresponding tool record according to the binding relationship, constructing an interface call request for the target business system based on the corresponding tool record, and returning the call result.

2. The API tooling method based on the model context protocol according to claim 1, characterized in that, Step S1 includes, Identify the event type corresponding to the business system access trigger event, wherein the event type includes business system registration request event and service resource discovery event; When the event type is the business system registration request event, obtain the system identifier, service address, interface document address, authentication configuration information and interface call configuration information from the business system registration request event to generate the API access registration result; When the event type is the service resource discovery event, the system identifier, the service address and the interface configuration information are extracted from the service resource through the container orchestration platform interface, and the interface document address is determined according to the interface configuration information to generate the API access discovery result. Based on the API access registration result or the API access discovery result, query the interface description information, business semantic metadata and management attribute information corresponding to the business system to be accessed from the configuration management database to generate basic information of the business system, write the basic information of the business system into the business system repository, and generate a business system access record.

3. The API tooling method based on the model context protocol according to claim 2, characterized in that, Step S2 includes, Extract the system identifier and the interface document address from the business system access record, and obtain the interface document corresponding to the business system to be accessed based on the interface document address; Identify the document version type corresponding to the interface document, and determine the target parser from the preset parser set based on the document version type; The target parser parses the interface document and extracts the request method, interface path, parameter definition information, response definition information, interface summary information, media type information, and interface description information corresponding to each API interface in the interface document. The system identifier, the request method, the interface path, the parameter definition information, and the response definition information are mapped to corresponding unified interface objects; The corresponding business primary key is generated based on the system identifier, request method, and interface path in the interface object. The interface objects with the business primary key are then aggregated to generate the interface object set.

4. The API tooling method based on the model context protocol according to claim 3, characterized in that, In step S3, interface data synchronization processing is performed on the interface object set based on the business primary key to generate synchronized interface records, including: Extract the business primary key corresponding to each interface object in the interface object set, and perform deduplication processing on the interface object set based on the business primary key to obtain a deduplicated interface object set; Retrieve pre-stored historical interface records and match the deduplicated interface object set with the historical interface records according to the business primary key; When the target business primary key exists in the deduplication interface object set but does not exist in the historical interface records, an interface record is added based on the interface object corresponding to the target business primary key. When the target business primary key exists in both the deduplication interface object set and the historical interface records, and the corresponding interface content changes, the corresponding historical interface record is updated based on the interface object corresponding to the target business primary key. If the corresponding interface content does not change, the corresponding historical interface record is retained. When the target business primary key exists in the historical interface records but does not exist in the deduplication interface object set, a deletion mark is added to the historical interface record corresponding to the target business primary key. Perform idempotent writing on the newly added interface records, the updated historical interface records, and the historical interface records after adding the deletion mark to generate the synchronized interface records; The system calculates the total number of interfaces, the number of newly added interfaces, the number of updated interfaces, and the number of deleted interfaces for this data synchronization process, and generates synchronization result information.

5. The API tooling method based on the model context protocol according to claim 3, characterized in that, In step S3, based on the synchronized interface record, the corresponding API interface capability is converted into a tool definition conforming to the model context protocol, and a tool record is generated, including... Receive a tool conversion request, extract the business primary key corresponding to the target API interface from the tool conversion request, and query the target synchronized interface record from the synchronized interface record according to the business primary key; Obtain the interface object corresponding to the target synchronized interface record, and extract the system identifier, request method, interface path, parameter definition information, response definition information, interface summary information, interface description information, and media type information from the interface object; The request method, system identifier, and interface path are concatenated in the order described to generate a business primary key name for internal association queries. The corresponding historical tool record is then queried from the tool repository based on the business primary key name. If a corresponding historical tool record exists, the creation of the current MCP tool is refused, and a tool duplication error message is generated. When no corresponding historical tool record exists, the interface path is normalized, and a protocol tool name is generated based on the request method, the system identifier, and the normalized interface path. Based on the parameter definition information, the response definition information, the interface summary information, the interface description information, and the media type information, tool input mode, tool output mode, tool description information, and tool call configuration are generated respectively, and an MCP tool definition conforming to the model context protocol is constructed. Associate the MCP tool definition with the business primary key, the business primary key name, and the target synchronized interface record; write the associated MCP tool definition into the tool repository; set the activation status of the corresponding tool record to the enabled status; set the working status of the tool record to the used status; and generate the tool record.

6. The API tooling method based on the model context protocol according to claim 5, characterized in that, Based on the parameter definition information, response definition information, interface summary information, interface description information, and media type information, tool input mode, tool output mode, tool description information, and tool invocation configuration are generated respectively, and an MCP tool definition conforming to the Model Context Protocol is constructed, including... Based on the parameter positions corresponding to each interface parameter in the parameter definition information, the path parameters, query parameters, and request header parameters are mapped to the top-level attributes in the tool input mode, and the request body parameters are mapped to the top-level attributes in the tool input mode represented by the preset request body key name. The parameter modes corresponding to each interface parameter are recursively transformed to generate the tool input mode. Based on the response status code and response mode corresponding to each response in the response definition information, the target response mode is determined according to the preset response selection order, and the target response mode is recursively transformed to generate the tool output mode; The tool description information is generated based on the interface summary information and the interface description information, and the tool description information is written into the tool title field and tool description field of the MCP tool definition, respectively; Based on the request method, the interface path, the parameter definition information, and the media type information, generate the tool call configuration, which includes the request method, target path, path parameter list, query parameter template, request header template, request body template, request media type, and response media type.

7. The API tooling method based on the model context protocol according to claim 5, characterized in that, Step S4 includes, Receive a Model Context Protocol Service Creation Request generated based on the target AI client or the target business scenario, and obtain tenant identifier, service identifier information, service capability declaration, client description information, extended metadata, candidate endpoint path, activation status, authentication switch and tool identifier list from the Model Context Protocol Service Creation Request. The service identifier information includes service name, service title and service version. When the Model Context Protocol service creation request does not carry the candidate endpoint path, the candidate endpoint path is generated based on the service name; when the Model Context Protocol service creation request carries the candidate endpoint path, the candidate endpoint path is obtained and normalized to obtain the target endpoint path. Based on the tenant identifier, a uniqueness check is performed on the target endpoint path within the corresponding tenant range. When the target endpoint path fails the uniqueness check, the creation of the Model Context Protocol (MTP) service instance is terminated, and a duplicate endpoint path warning message is generated. When the target endpoint path passes the uniqueness check, the creation of the MTP service instance continues. Based on the tenant identifier and the tool identifier list, the corresponding target tool records are queried in batches from the tool records belonging to the tenant identifier, and the queried target tool records are combined into a target tool set. A MTP service record is generated according to the service identifier information, the service capability declaration, the client description information, the extended metadata, the target endpoint path, the enabled status, and the authentication switch. The MTP service record is written to the service repository, the MTP service instance is created, and the corresponding service identifier is obtained. When the enabled status is not specified, the enabled status is set to enabled. The service access address corresponding to the Model Context Protocol service instance is generated based on the pre-configured Model Context Protocol service base address, the tenant identifier, and the target endpoint path, and the service access address is written into the Model Context Protocol service record. Based on the service identifier and the tool identifier corresponding to each target tool record in the target tool set, service tool association records are generated to establish a many-to-many binding relationship between the model context protocol service instance and each target tool record. The tool sorting information corresponding to each target tool record is written into the corresponding service tool association record. When the authentication switch is on, a random number is generated and the random number is URL-securely Base64 encoded to obtain the API Key plaintext. The API Key plaintext is then subjected to irreversible hashing, and the generated API Key hash value is written into the model context protocol service record. The API Key plaintext is returned once in the creation response of the model context protocol service instance.

8. The API tooling method based on the model context protocol according to claim 7, characterized in that, Step S5 includes, The system receives the protocol request initiated by the AI ​​client based on the service access address and access credentials, and determines the corresponding model context protocol service instance based on the tenant identifier and endpoint path in the service access address. The protocol request includes tool query request and tool invocation request. The access credentials carried in the protocol request are extracted by a security filter, and access verification is performed on the access credentials according to the authentication configuration information corresponding to the model context protocol service instance. When the protocol request passes the access verification, rate limiting, access log recording, and tracking context writing are performed on the protocol request. Identify the request type corresponding to the protocol request, and route the tool query request to the tool query processing module and the tool call request to the tool call processing module; When the protocol request is the tool query request, the binding tool record is obtained according to the binding relationship corresponding to the model context protocol service instance, the target tool record that is in an available state is filtered from the binding tool record, and a tool information list is generated according to the target tool record, and the tool information list is returned to the AI ​​client; When the protocol request is the tool invocation request, the target tool identifier is extracted from the tool invocation request, the target tool record corresponding to the target tool identifier is queried according to the binding relationship, and the tool invocation configuration is obtained from the target tool record; Based on the tool invocation parameters and tool invocation configuration carried in the tool invocation request, the request method, the interface path, the path parameters, the query parameters, the request header parameters, and the request body parameters are determined, and the interface invocation request for the target business system is constructed. Obtain the authentication configuration information, request timeout configuration information, and retry configuration information corresponding to the business system to which the target tool record belongs; inject the authentication configuration information into the interface call request; and perform call control processing on the interface call request according to the request timeout configuration information and the retry configuration information. The interface call request is sent to the target business system using a reactive non-blocking processing method. The interface call result returned by the target business system is obtained, and the interface call result is converted into a model context protocol response and returned to the AI ​​client.

9. The API tooling method based on the model context protocol according to claim 8, characterized in that, It also includes step S6, which performs unified exception handling and observability monitoring during the operation process, uniformly encapsulates the exceptions generated during the creation of model context protocol service instances, tool queries, tool calls and access to business system interfaces, records structured logs including tracking identifiers, tool names, call times and error codes, and determines the operating status of gateway services and dependent business systems through health checks and operation indicator collection, and sends the corresponding service status, tool status, interface synchronization status, tool call success rate, exception records and operating load to the management interface for display.

10. An API tooling processing system based on a model context protocol, employing the API tooling processing method based on a model context protocol as described in any one of claims 1 to 9, comprising: The system access module is used to respond to business system access trigger events, register or discover API access information of the business system to be accessed, and generate business system access records. The document parsing module is used to obtain and parse the interface document based on the access record of the business system, and generate an interface object set. Each interface object in the interface object set includes a business primary key, parameter definition information and response definition information. The tool record generation module is used to perform interface data synchronization processing on the interface object set based on the business primary key, generate synchronized interface records, and convert the corresponding API interface capabilities into tool definitions that conform to the model context protocol based on the synchronized interface records, and generate tool records. The tool binding module is used to determine a target tool set from the tool record based on the target AI client or target business scenario, create a model context protocol service instance based on the target tool set, and establish a binding relationship between the service instance and the tool record; The system call module is used to process protocol requests initiated by AI clients based on the service instance and the binding relationship, and to perform tool queries or tool calls according to the protocol requests. The tool query includes returning tool information corresponding to the target tool set according to the binding relationship, and the tool call includes determining the corresponding tool record according to the binding relationship, constructing an interface call request for the target business system based on the corresponding tool record, and returning the call result.

Images