Calling method, device and equipment of application program interface, storage medium and program

Abstract

The application discloses an application program interface calling method and device, equipment, storage medium and program, and relates to the computer technical field, which comprises the following steps: obtaining interface rules corresponding to each application program interface in a plurality of application program interfaces, and obtaining a plurality of interface metadata; analyzing the plurality of interface metadata, and obtaining a plurality of interface parameter sets, wherein each interface parameter set at least comprises endpoint information corresponding to the application program interface, a parameter type corresponding to the application program interface, and authentication requirements corresponding to the application program interface; generating a plurality of tool functions based on the plurality of interface parameter sets and a preset function template, and registering the plurality of tool functions on a model context protocol server; and generating a calling request of each application program interface based on a registration result and a corresponding relationship of the plurality of application program interfaces. The application solves the problems that the process of converting the application programming interface specification into the model context protocol tool is complex and inefficient in the related art.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, in particular, relate to a method and apparatus for calling application program interface, a storage medium and a program. BACKGROUND

[0002] With the rapid development and popularization of large artificial intelligence models, how to efficiently call related technical service APIs (Application-Programming-Interface, API for short) by large models has become an important challenge. MCP (Model-Context-Protocol, MCP for short) as a standard protocol connecting large models and external services has been supported and applied by most major model providers. However, the related art usually requires developers to manually write a large amount of code to convert APIs into MCP tools, and lacks a unified and efficient conversion scheme. At the same time, in the conversion process, there are problems such as insufficient support for complex parameter types and dependency relationships, difficulty in accurately mapping API parameter structures, excessive number of registration tools leading to model context length exceeding the limit and affecting the use effect, diverse API response formats lacking a unified processing mechanism affecting the model's understanding of the results, diverse and decentralized API document formats lacking a unified access scheme, and insufficient and incomplete API document semantics leading to difficulty for the model to understand.

[0003] In view of the problems in the related art that the process of converting application programming interface specifications into model context protocol tools is complex and inefficient, no effective solutions have been proposed so far. SUMMARY

[0004] Embodiments of the present application provide a method and apparatus for calling application program interface, a storage medium and a program to at least solve the problem in the related art that the process of converting application programming interface specifications into model context protocol tools is complex and inefficient.

[0005] According to an embodiment of the present application, a method for calling an application program interface is provided, comprising: obtaining interface rules corresponding to each of a plurality of application program interfaces to obtain a plurality of interface metadata; parsing the plurality of interface metadata to obtain a plurality of interface parameter sets, wherein each interface parameter set at least includes endpoint information corresponding to the application program interface, parameter types corresponding to the application program interface, and authentication requirements corresponding to the application program interface; generating a plurality of tool functions based on the plurality of interface parameter sets and a preset function template, and registering the plurality of tool functions on a model context protocol server; and generating a calling request for each application program interface based on the registration result and the corresponding relationship of the plurality of application program interfaces.

[0006] According to another embodiment of the present application, an application program interface calling apparatus is provided, comprising: an acquisition module configured to acquire interface rules corresponding to each of a plurality of application program interfaces, to obtain a plurality of interface metadata; an analysis module configured to analyze the plurality of interface metadata, to obtain a plurality of interface parameter sets, wherein each interface parameter set comprises at least: endpoint information corresponding to the application program interface, a parameter type corresponding to the application program interface, and authentication requirements corresponding to the application program interface; a first generation module configured to generate a plurality of tool functions based on the plurality of interface parameter sets and a preset function template, and to register the plurality of tool functions on a model context protocol server; and a second generation module configured to generate a calling request for each application program interface based on a registration result and a corresponding relationship between the plurality of application program interfaces.

[0007] According to yet another embodiment of the present application, a computer readable storage medium is further provided, and the computer readable storage medium stores a computer program, wherein the computer program is configured to execute the steps in any of the method embodiments when running.

[0008] According to yet another embodiment of the present application, an electronic device is further provided, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the steps in any of the method embodiments when running the computer program.

[0009] According to yet another embodiment of the present application, a computer program product is further provided, comprising a computer program, and the computer program is configured to execute the steps in any of the method embodiments when executed by a processor.

[0010] Through the present application, interface definitions are automatically obtained from multiple application programming interface sources, including remote uniform resource locators or local files, and endpoint information, parameter types and authentication requirements therein are parsed to form interface metadata. The parsed interface metadata is further processed to construct a clear interface parameter set, providing structured data support for subsequent tool function generation. Based on the constructed interface parameter set and preset function templates, tool functions conforming to the model context protocol are automatically generated through an intelligent mapping algorithm. The generated tool functions are registered to the model context protocol server, enabling direct invocation of application programming interfaces by large models, generating invocation requests through the correspondence between the registration results and the application programming interfaces, optimizing the invocation process and improving the invocation efficiency. That is, by automatically parsing the interface rules of multiple application programming interfaces, key metadata information such as endpoint information, parameter types and authentication requirements is extracted, and corresponding tool functions are automatically generated and registered, ultimately enabling efficient invocation of each application programming interface. Thus, the problem of complex and low efficiency in the related art of converting application programming interface specifications into model context protocol tools is solved. The efficiency of converting application programming interface specifications into model context protocol tools is improved. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0012] Figure 1 is a hardware structure block diagram of a server device of an application program interface invocation method according to an embodiment of the present application;

[0013] Figure 2 is a flowchart of an application program interface invocation method according to an embodiment of the present application;

[0014] Figure 3 is a system structure schematic diagram of an automatically generated model context protocol tool system according to an embodiment of the present application;

[0015] Figure 4 is a flowchart of the running process of an automatically generated model context protocol tool system according to an embodiment of the present application;

[0016] Figure 5 is a flowchart of tool semantic enhancement according to an embodiment of the present application;

[0017] Figure 6 is a structure schematic diagram of a multi-source application programming interface fusion subsystem according to an embodiment of the present application;

[0018] Figure 7 is a flowchart of a dynamic adaptive application programming interface agent according to an embodiment of the present application;

[0019] Figure 8 is a structural block diagram of a calling device of an application programming interface according to an embodiment of the present application. DETAILED DESCRIPTION

[0020] The technical solutions in the embodiments of the present application will be clearly and completely described in connection with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0021] It should be noted that, in the description of the present application, the terms "comprise", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms "first", "second" and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0022] In order for those skilled in the art to better understand the present application, the present application will be further described in detail below in connection with the drawings and specific embodiments.

[0023] As an optional implementation, the method embodiments provided in the embodiments of the present application can be executed in a server device or similar computing device. Taking the case of running on a server device, Figure 1 is a hardware structural block diagram of a server device of an application programming interface calling method according to an embodiment of the present application. As shown in Figure 1 , the server device can include one or N (only one is shown in Figure 1 ) processors 102 (the processor 102 can include but is not limited to a processing device such as a microprocessor or programmable logic device) and a memory 104 for storing data, wherein the server device can further include a transmission device 106 for communication function and an input and output device 108. Those skilled in the art can understand that Figure 1 the structure shown is only schematic, which does not limit the structure of the server device. For example, the server device can include more or fewer components than those shown in Figure 1 , or have a different configuration from that shown in Figure 1 .

[0024] The memory 104 can be used to store computer programs, such as software programs of application software and modules, such as a computer program corresponding to the calling method of the application program interface in the embodiments of the present application. The processor 102 performs various functional applications and data processing by running the computer programs stored in the memory 104, that is, implements the above method. The memory 104 can include a high-speed random access memory, and can also include one or N magnetic storage devices, flash memories, or other non-volatile solid-state memories. In some examples, the memory 104 can further include a memory remotely arranged with respect to the processor 102, and the remote memory can be connected to a server device through a network. Examples of the above network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0025] The transmission device 106 is used to receive or send data via a network. The specific example of the above network can include a wireless network provided by a communication provider of the server device. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC) which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (Radio Frequency, RF) module which is used to communicate with the Internet in a wireless manner.

[0026] In the embodiments of the present application, a calling method of an application program interface is provided, Figure 2 The flowchart of the calling method of the application program interface according to the embodiments of the present application is shown in FIG. 2, and the flow includes the following steps: Figure 2

[0027] In step S202, interface rules corresponding to each of the plurality of application program interfaces are obtained, and a plurality of interface metadata are obtained.

[0028] ​Optionally, interface rule information is collected from multiple different API sources. These sources can be uniform resource locators (URLs) of Swagger or OpenAPI specification documents on remote servers, or locally stored specification files in lightweight data interchange format JSON (JavaScript Object Notation, JSON) or data-centric markup language YAML (YAML Ain't Markup Language, YAML). Interface rules contain all key details of APIs, such as endpoint paths, request methods, parameter information, response formats, and possible authentication mechanisms. By reading these rules and converting them into a unified interface metadata format, it helps the consistency and compatibility of subsequent processing stages.

[0029] Step S204, parsing the plurality of interface metadata to obtain a plurality of interface parameter sets, wherein each interface parameter set at least includes: endpoint information corresponding to the application program interface, parameter types corresponding to the application program interface, and authentication requirements corresponding to the application program interface;

[0030] It can be understood that once the interface metadata is collected and converted, the next step is to parse the metadata and extract the necessary parameter information to form the interface parameter set. Each set contains but is not limited to the detailed path of the API endpoint, the parameter types and formats that may be involved in the request process, and the authentication requirements needed to call the API. The work in this stage is to ensure that all API parameters are correctly identified and recorded, so as to generate MCP tool functions that adapt to these parameters in the subsequent stage.

[0031] Step S206, generating a plurality of tool functions based on the plurality of interface parameter sets and a preset function template, and registering the plurality of tool functions on a model context protocol server;

[0032] Optionally, with detailed interface parameter sets, specific tool functions are generated using preset function templates. Tool functions are encapsulations under the MCP protocol, which convert API calls into standard operations that intelligent large models can understand and execute. The preset function template covers common API call patterns, and through parameter set filling, each tool function can accurately reflect the characteristics of the corresponding API. The generated tool functions are then uploaded and registered to the model context protocol server, so that the intelligent large model can directly call these tool functions without worrying about the details of the underlying API, achieving the abstraction and simplification of API calls.

[0033] Step S208, generating a calling request of each application program interface based on the registration result and the corresponding relationship of the plurality of application program interfaces.

[0034] The last step is to confirm the registration status of the tool function and generate a calling request based on this status and the original rules of the API. This means that when the intelligent large model needs to call a certain specific API, it is actually calling a tool function on the model context protocol server, which has been successfully registered and has established a clear correspondence with the original API. Based on this correspondence, the correct calling request is constructed, including the required authentication information, parameter list and formatted data, etc., to ensure that each call can be successfully performed, while also avoiding the need to repeatedly parse API rules, improving the overall calling efficiency and stability.

[0035] Through the above method, the interface definitions are automatically obtained from a plurality of application programming interface sources, including remote uniform resource locators or local files, and the endpoint information, parameter types and authentication requirements therein are parsed to form interface metadata. The parsed interface metadata is further processed to construct a clear interface parameter set, providing structured data support for subsequent tool function generation. Based on the constructed interface parameter set and the preset function template, intelligent mapping algorithms are used to automatically generate tool functions that meet the model context protocol. The generated tool functions are registered on the model context protocol server to enable direct calling of application programming interfaces by the large model, and the calling request is generated based on the correspondence between the registration result and the application programming interface, optimizing the calling process and improving the calling efficiency. That is, by automatically parsing the interface rules of a plurality of application programming interfaces, extracting key metadata information such as endpoint information, parameter types and authentication requirements, and then automatically generating corresponding tool functions and registering them, efficient calling of each application programming interface is ultimately achieved. Thus, the problem of complex and low efficiency in the related art of converting application programming interface specifications into model context protocol tools is solved. The efficiency of converting application programming interface specifications into model context protocol tools is improved.

[0036] In one exemplary embodiment, after parsing the plurality of interface metadata to obtain a plurality of interface parameter sets, the method further comprises: if the authentication requirement carried in the interface metadata meets the preset authentication requirement, filtering the plurality of interface parameter sets based on the endpoint information, wherein the filtering processing is used to identify the interface parameter set as prohibited from using data in the case that the endpoint information is abnormal information prohibited from being called by the intelligent large model; and determining a plurality of target interface parameter sets allowed to participate in tool function generation based on the filtering result.

[0037] It can be understood that after parsing the multiple interface metadata and extracting the interface parameter sets, the authentication requirement information carried in each set is further checked. The authentication requirement refers to the security verification mechanism required for API calling, such as OAuth2, API key, or basic authentication, etc. These authentication requirements are compared with the preset authentication requirement list to determine whether they meet the calling policy and security standards of the intelligent large model. If the authentication requirement does not meet the preset standard, or the endpoint information indicates that the API is an interface that the intelligent large model should not call (such as an interface accessing sensitive data), the corresponding interface parameter set is marked as "prohibited from using data". This marking means that the set will not participate in the subsequent tool function generation process, thereby excluding those non-compliant or unnecessary API calls, reducing potential security risks and unnecessary computational overhead.

[0038] After matching the authentication requirements and filtering the abnormal information, it is determined which interface parameter sets meet the requirements based on the above screening logic, i.e., "target interface parameter sets". These sets are considered as objects that can safely and effectively generate MCP tool functions, as they have passed the necessary security verification and calling policy checks.

[0039] Based on the results of the filtering process, it can be determined which interface parameter sets can be used to generate MCP tool functions. This step is a critical preparatory process, as it ensures that the final generated tool functions will only contain API information that has been verified, complies with the calling policy and security standards. Through the above method, not only the quality of the generated tool functions is improved, but also the unnecessary expansion of the intelligent large model context is reduced, optimizing the performance and calling experience of the model.

[0040] In summary, through the above implementation, by matching the authentication requirements and filtering based on the endpoint information, interface parameter sets that meet the security calling policy can be intelligently screened, laying the foundation for the subsequent generation of MCP tool functions. Not only does it enhance the security of the overall conversion process, but also improves the practicality and efficiency of the tool functions.

[0041] In one example embodiment, based on the plurality of interface parameter sets, a plurality of tool functions are generated based on the plurality of interface parameter sets and a preset function template, including: identifying a parameter type to which each interface parameter set belongs, obtaining a plurality of target parameter types; determining a plurality of target mapping strategies corresponding to the plurality of target parameter types according to a mapping table associated with the preset function template, wherein the mapping table is used to record the conversion relationship between the interface parameter type and the MCP parameter type; executing the plurality of target mapping strategies, and filling the preset function template according to the execution result to obtain a plurality of tool functions.

[0042] In the process of integrating API interfaces into the intelligent large model, the first step is to identify and classify the types of parameters in each interface parameter set. These parameter types can come from the data types defined in the OpenAPI (such as Swagger) specification, such as string, integer, number, boolean, array, object, date-time, binary, etc. Identifying parameter types is the key first step in generating MCP tool functions, ensuring that subsequent mapping and conversion can be accurately performed. A preset mapping table is used, which records the conversion rules between API interface parameter types and MCP protocol parameter types. For example, a string type parameter in the API may need to be converted to a str type in the MCP, and a date-time format string may need to be converted to a datetime object. This mapping table is the basis for smooth conversion of different types of parameters between different protocols, allowing API parameters to be correctly understood and processed in the MCP environment. Next, according to the conversion relationship defined in the mapping table, the target mapping strategy is automatically executed. This includes converting API parameter types to the required format for MCP, and then filling the converted parameter types and other related information into the preset function template. The function template is the skeleton of the MCP tool function, containing the basic structure and calling logic of the function, while the parameter types are the key data to fill in this skeleton. Through the above method, tool functions that meet the MCP protocol can be generated, and these functions can convert the characteristics of API interfaces into a form that can be directly called by the intelligent large model. After executing the mapping strategy, the relevant placeholders in the preset function template are replaced by specific parameter types and their description information, ultimately forming complete tool functions. These tool functions not only contain all the parameter information required for API calls, but also have built-in processing logic for these parameters, such as parameter validation, default value filling, and recursive parsing of complex parameter types, so that the intelligent large model can automatically complete parameter construction and transmission when calling, without manual intervention.

[0043] In summary, through the above method, through the three steps of parameter type identification, mapping table application, and function template filling, the API interface parameter set is automatically converted into tool functions that meet the MCP protocol. This process greatly simplifies the complexity of the intelligent large model calling API, reducing development and maintenance costs.

[0044] In an exemplary embodiment, after executing the plurality of target mapping strategies and filling the preset function template based on the execution results to obtain a plurality of tool functions, the method further comprises: determining the dependency relationship between different processing parameters in the plurality of tool functions; and determining the calling order corresponding to each tool function based on the dependency relationship.

[0045] In simple terms, the generated utility functions undergo in-depth analysis to identify and resolve the dependencies between their parameters. These dependencies may stem from the API interface's own logic; for example, the values ​​of some parameters may depend on the existence or specific values ​​of others, or another endpoint may need to be called before calling a particular API endpoint to obtain necessary authentication information or initialization data. This logical order between parameters is crucial for ensuring the correctness and effectiveness of the entire API call process. Ignoring these dependencies may lead to call failures or unexpected results.

[0046] Once the dependencies between parameters are identified, it can determine the order in which utility functions are called based on this information. For example, if utility function A depends on the output of another utility function B, then function B will be called first, followed by function A, and so on, constructing an ordered call sequence. This ensures the consistency of API call logic, avoids call failures due to missing or inappropriate parameters, and improves call efficiency.

[0047] In summary, the above implementation methods not only automate complex API call processes but also reduce errors caused by confusing parameter dependencies, improving the success rate and response speed of intelligent large-scale model API calls. Even if the API specification changes or new parameter dependencies are added, the call order can be automatically adjusted to maintain correct functionality.

[0048] In an exemplary embodiment, before executing the plurality of target mapping strategies and filling the preset function template according to the execution results to obtain a plurality of tool functions, the method further includes: extracting descriptive information from the plurality of interface parameter sets to obtain a plurality of first texts; performing semantic enhancement processing on the plurality of first texts to obtain a plurality of second texts; and determining to use the plurality of second texts to supplement the descriptive semantics of the preset function template before generating tool functions.

[0049] In other words, before generating utility functions, descriptive information is first extracted from each set of interface parameters. This descriptive information is usually contained in the comments or description fields of the API documentation, explaining the function of the interface, the meaning of the parameters, and the expected effect of the call. Extracting this information is a crucial step in ensuring that the intelligent large model can understand the role of the utility functions.

[0050] Next, the extracted description information undergoes semantic enhancement processing. This process may involve using Natural Language Processing (NLP) techniques to parse and understand the description text, as well as adding additional explanations, interpretations, or examples to enrich and clarify the description information. The goal of semantic enhancement is to generate more clear, accurate, and easily understood description text, i.e., multiple second texts, for large models, thereby reducing the calling errors caused by description ambiguity and improving the effectiveness and success rate of calling.

[0051] Furthermore, it is determined to use the second text after semantic enhancement processing to supplement the description part in the preset function template, that is, the enhanced description information is integrated into the function template before the tool function is generated, so as to ensure that the finally generated tool function not only contains the required parameters and logic of calling, but also contains detailed and accurate description information. This helps the intelligent large model to better understand the scope of action and calling conditions of each tool function, so as to make more appropriate and efficient decisions in actual calling.

[0052] In summary, by enhancing the description information, the intelligent large model reduces the error calls caused by misunderstanding the API function, and also provides developers with more clear tool function descriptions, which facilitates them to design and implement more complex calling scenarios.

[0053] In an example embodiment, a plurality of application program interfaces are obtained, each corresponding to an interface rule, and a plurality of interface metadata are obtained, including: determining a plurality of rule sources corresponding to the plurality of application program interfaces; obtaining a plurality of parsing adapters corresponding to the plurality of rule sources, and using the plurality of parsing adapters to perform standardized parsing on different application program interfaces; performing a unified intermediate representation on the parsing result to obtain a plurality of interface data, wherein the unified intermediate representation is standardized by a preset standardized endpoint definition, a preset unified parameter model, and a preset unified response format; and determining the plurality of interface metadata based on the plurality of interface data.

[0054] First, it is necessary to determine where to obtain the interface rules of the API. These sources can be API specification documents in different formats and locations, such as Swagger or OpenAPI specification URLs on remote servers, locally stored JSON or YAML files, or other types of API descriptions (such as RAML, GraphQL, etc.). Identifying rule sources is the starting point of the entire process, and it ensures that subsequent processing covers all API information that needs to be integrated.

[0055] For different sources and formats of API specifications, corresponding parsing adapters are used to read and parse the interface rules. For example, for Swagger or OpenAPI JSON / YAML files, an OpenAPI parser is used; for query language GraphQL, a GraphQL query language parser is used, etc. Each parsing adapter is specifically designed to understand and extract key information such as endpoints, parameters, authentication mechanisms, etc. described in its corresponding format specification, ensuring that API rules of different formats can be accurately parsed.

[0056] The information extracted by the parsing adapter is converted into a unified intermediate representation. This unified intermediate representation is a standardized data structure that unifies API information from different formats and sources into a consistent structure for subsequent processing. Standardized endpoint definitions, unified parameter models, and unified response formats are key components of the uniform resource locator, which ensures the structured and consistent API information, providing a clear and unified data foundation for the next step of generating tool functions.

[0057] Finally, based on the unified intermediate representation of API information, the final interface metadata set can be determined. These metadata contain the complete description of the API, including but not limited to endpoint path, request method, parameter type and format, response structure, authentication requirements, etc. The metadata of each API is the basis for the generation of its MCP tool function, ensuring that each tool function can accurately reflect the characteristics of its corresponding API.

[0058] In summary, through the above examples, not only can API information be collected from a variety of specification sources, but also through adapter and unified intermediate representation technology, these information can be standardized and structured, providing high-quality data preparation for subsequent tool function generation and registration.

[0059] In one example embodiment, before registering the plurality of tool functions on the model context protocol server, the method further comprises: change detection on the plurality of application program interfaces, wherein the change detection is used to determine version iteration information of application program interfaces and changes in authentication requirements; and determining whether to incrementally update the plurality of tool functions according to the change detection result.

[0060] Change detection is a key link in the automated tool function maintenance, its goal is to monitor and identify any updates or modifications of application program interfaces, including API version iteration information and changes in authentication requirements. This process can be done by periodically or in real time extracting the latest information from the source of API specification (such as Swagger, OpenAPI JSON / YAML file or online documentation), and comparing it with the stored current version API data.

[0061] The detection of version iteration information involves identifying whether the API has been updated to a new version and any changes in endpoints, parameters, response formats, or authentication mechanisms that may be included in the new version. This step is crucial for ensuring that the tool functions are synchronized with the API specifications, especially in environments where APIs are frequently updated.

[0062] The authentication requirement change detection focuses on changes in API security verification mechanisms, such as a migration from OAuth2 ("Open Authorization 2.0", a protocol that allows applications to obtain limited access to user data on another service) to JWT (JSON Web Token, or JWT, web token), or the addition of new authentication parameters. These changes have a direct impact on the correctness and security of tool functions and need to be reflected in the updates to tool functions in a timely manner.

[0063] Based on the results of the change detection, it is determined whether it is necessary to perform incremental updates to the registered tool functions. Incremental updating is an efficient and resource-saving updating strategy that only updates or adds those parts that have actually changed, rather than completely regenerating all tool functions. For example, if only one endpoint is added to the API, only the tool functions related to that endpoint need to be generated and updated, while other unchanged tool functions remain unchanged.

[0064] In summary, by implementing the change detection and incremental updating process, the dynamic changes of the API can be adapted in real time, keeping the tool functions consistent with the latest state of the API, while significantly reducing the time and resources required to update the tool functions. This mechanism ensures that even in scenarios where APIs are frequently iterated, intelligent large models can still call these APIs efficiently and securely without going through the complete tool function regeneration process, improving the flexibility and response speed of subsequent calls.

[0065] In an example embodiment, determining whether to perform incremental updates on the plurality of tool functions according to the change detection result includes: in the case where the change detection result is that there is no change in the application program interface, determining not to perform incremental updates on the plurality of tool functions, and triggering the start registration time of the plurality of tool functions; in the case where the change detection result is that there is a change in the application program interface, determining to perform incremental updates on the plurality of tool functions, and locating the target interface with the change in the plurality of application program interfaces through the intelligent large model.

[0066] In one exemplary embodiment, in the case where the change detection result indicates that there is a change in the application program interface, after determining to perform incremental updates on the plurality of tool functions, the method further comprises: sending interface information of the application program interface with changes to a target object; and obtaining update requirements issued by the target object for the application program interface with changes.

[0067] Change detection is a key checkpoint in the entire process, which evaluates whether the application program interface has undergone updates or changes. Depending on the result, there are two cases:

[0068] API no change case: When the change detection result shows that the API has not changed, the incremental update of the tool function will not be triggered. This means that the status of the related technical tool function is correct and does not need any changes. At this time, the registration process of the tool function will be directly entered, preparing to register these tool functions on the model context protocol server. At the same time, the last registration time of the tool function is recorded or updated, in order to track and audit later.

[0069] API change case: If the change detection reveals that the API has updates, such as adding endpoints, parameter type changes, or adjustments to authentication mechanisms, it will be determined that the related tool functions need to be incrementally updated. Incremental update means only updating those affected tool functions, rather than completely regenerating all tool functions. In order to accurately locate which APIs have changed, a smart large model (such as a pre-trained language model) can be used to perform in-depth analysis on the API specification document. This step ensures the accuracy and pertinence of the update.

[0070] Once the APIs with changes are confirmed, the interface information of these APIs is sent to the target object, which may be the user of the MCP tool, the developer of the API, or an internal update management component. The purpose of this step is to share the details of the API changes, so that multiple parties can understand and participate in the update decision. Subsequently, update requirements are received from the target object. These requirements may include specific update instructions, such as which parameters need to be adjusted, whether new tool functions need to be added, and how to handle changes in security authentication, etc. In this way, based on the feedback from the target object, the update logic of the tool function can be fine-tuned to ensure that the update content not only conforms to the actual changes of the API, but also meets the needs of the calling party, improving the efficiency and accuracy of the entire update process.

[0071] In summary, through the above embodiments, not only can the maintenance burden be reduced, unnecessary complete rewriting can be avoided, but also the synchronization between API and tool function can be promoted, and the latest state of API can be timely reflected. Through effective cooperation with the target object, the dynamic changes of API can be more flexibly dealt with, the need for human intervention is reduced, and at the same time, it is ensured that the update of the tool function is well thought out and demand matched, avoiding over-update or under-update.

[0072] In one example embodiment, after determining to perform incremental updates on the plurality of tool functions, locating the target interface with changes in the plurality of application program interfaces by the intelligent large model, the method further comprises: determining the change range and change type corresponding to the target interface with changes; based on the change range and the change type, instructing the intelligent large model to customize a suitable interface update strategy, wherein the interface update strategy at least includes one of the following: interface partial update, interface complete reconstruction, interface backward compatible conversion; using the interface update strategy to perform incremental updates on the target tool function corresponding to the target interface with changes.

[0073] First, the intelligent large model is used to locate which specific interfaces in the plurality of application program interfaces have changes. This involves comparing the stored current API state with the latest API specification. Through deep analysis and pattern recognition technology, the intelligent large model can quickly locate the specific interfaces or parameters that have changed, rather than blindly checking all interfaces, saving a lot of computing resources and time.

[0074] Next, the specific range and type of these changes will be determined. The change range can be local, affecting only a single interface or parameter, or extensive, requiring the reconstruction of the entire interface. The change type includes but is not limited to the addition or deletion of endpoints, the modification of parameter types, changes in authentication requirements, or adjustments to response formats. Understanding the range and type of changes is a prerequisite for developing an update strategy.

[0075] Based on the change range and type, a suitable interface update strategy is customized. This may include the following: interface partial update, when the change only affects a part of the interface (such as adding a parameter or returning a field), the affected part can be selectively updated, preserving the structure of the tool function that has not changed. Interface complete reconstruction, if the API changes are severe, such as changes in endpoint path or request method, the tool function for the entire interface may need to be regenerated. Interface backward compatible conversion, when API version iterations occur, automatically handle backward compatibility issues to ensure that calls to old versions can still be correctly mapped to new versions of tool functions.

[0076] Finally, the target tool functions with changes are incrementally updated using a customized update strategy. This means that only those functions that actually need to be modified are updated, leaving the rest of the tool functions unchanged. This incremental update method not only reduces unnecessary calculations, but also ensures the efficiency and accuracy of the update process, avoiding potential errors introduced by unnecessary code changes, while also ensuring the continuous stability and efficiency of the AI model calling API.

[0077] In an example embodiment, before generating the calling request of each application program interface based on the correspondence between the registration result and the plurality of application program interfaces, the method further comprises: in the case where there are multiple model context protocol servers, determining the load proportion corresponding to each model context protocol server; in the case where the load proportion is greater than or equal to a preset safe load proportion, identifying the current model context protocol server as a full load state, and prohibiting the registration of subsequent tool functions on the current model context protocol server; in the case where the load proportion is less than the preset safe load proportion, identifying the current model context protocol server as a non-full load state, and allowing the registration of subsequent tool functions on the current model context protocol server.

[0078] In an example embodiment, after determining the load proportion corresponding to each model context protocol server in the case where there are multiple model context protocol servers, the method further comprises: determining a target model context protocol server with the smallest load proportion from the multiple model context protocol servers; and setting the target model context protocol server as a backup server, wherein the backup server is used to backup the registration data existing on the model context protocol servers other than the target model context protocol server among the multiple model context protocol servers.

[0079] In summary, the load proportion of each model context protocol server is monitored and calculated, i.e. the ratio of the current request processing amount to the maximum processing capacity of the server. The working pressure and available capacity of each server are evaluated to provide a basis for subsequent load balancing and failure recovery strategies. The calculation of the load proportion may be based on real-time request processing, CPU (Central Processing Unit) and memory usage, or historical load data to predict future load trends. Then, it is checked whether the load proportion of each model context protocol server exceeds a preset safety threshold. If the load proportion reaches or exceeds this threshold, it indicates that the server is in a high load or full load state, and the system marks the server as "full load state" and temporarily prohibits new tool functions from registering on it. On the contrary, if the load proportion is below the safety threshold, the server is in a low load or normal state, and the system allows tool functions to continue to register on it. This strategy helps to prevent a server from crashing due to overload and ensures the stable operation of the system as a whole.

[0080] After determining the load state of each server, a model context protocol server with the lowest load proportion is selected as the "target model context protocol server" and is set as the backup server. The role of the backup server is to take over the request processing task immediately when the main server encounters problems or is overloaded, ensuring the continuity of the service. In addition, the registration data on other model context protocol servers can also be backed up to the backup server, so that even if a server is down, the service can be quickly restored and continue to process requests using the data on the backup server.

[0081] In summary, the above embodiments consider the load management and failure recovery mechanism in a multi-server environment, and by dynamically monitoring server load and reasonably allocating tool function registration, single point failure and uneven load problems are avoided. At the same time, by setting the server with the lowest load as the backup server and backing up critical data in advance, the server downtime or overload situation can be quickly responded to, ensuring the high availability and stability of the service.

[0082] In an exemplary embodiment, after setting the target model context protocol server as the backup server, the method further comprises configuring switching rules for the backup server, wherein the switching rules at least include one of the following: in the case of failure of other model context protocol servers, migrating all registration data on the failed server in the other model context protocol servers to the backup server; in the case of high load of other model context protocol servers, migrating the registration data of the part exceeding the load proportion in the other model context protocol servers to the backup server.

[0083] That is, the standby server will correspond to set a set of switching rules to guide the registration data (i.e. tool functions) on other model context protocol servers to migrate to the standby server under what circumstances. These switching rules include at least the following two cases:

[0084] Failover: When detecting the failure of other model context protocol servers, automatically migrate all registration data on the failed server to the standby server. This process often needs to be completed quickly and automatically to ensure the continuity of the service and the timely response of user requests. Failures may include server downtime, network failures, or service unavailability due to software errors.

[0085] Load balancing: When the load of other model context protocol servers exceeds the preset safety threshold, migrate the registration data exceeding the threshold to the standby server. This step aims to balance the load in the server cluster by dynamically redistributing tool functions, avoiding overloading of individual servers and affecting system performance. Load balancing is usually performed on demand, and the load of all servers is continuously monitored. Once a server is detected to be overloaded, the switching rule will be activated to migrate part of the tool functions to the standby server with lower load.

[0086] The execution of the switching rule usually involves data migration and function redirection. For failover, the standby server will receive and take over all registration data and their corresponding function load of the failed server, ensuring that user requests can be processed in a timely manner. For load balancing, tool functions are selectively migrated based on the current load of each server to ensure that the load of all servers in the cluster remains within a reasonable range.

[0087] In an example embodiment, after obtaining the update requirements issued by the target object for the changed application program interface, the method further comprises: if the target object does not feedback the update requirements within a preset period, using a predefined default update strategy to process the changed application program interface; if the target object feedbacks multiple update requirements within a preset period, processing with reference to the update requirement with the latest issue time point among the multiple update requirements.

[0088] In an example embodiment, based on the plurality of interface parameter sets and the preset function template to generate a plurality of tool functions, and after registering the plurality of tool functions on the model context protocol server, the method further comprises: recording the registration time of each tool function; if the registration time is greater than or equal to a preset time threshold, determining that the current tool function registration fails, and feeding back a re-registration message; if the registration time is less than the preset time threshold, determining that the current tool function registration is successful, and feeding back a completion registration message.

[0089] In one example embodiment, after generating the invocation request for each application program interface based on the registration result and the corresponding relationship with the plurality of application program interfaces, the method further comprises: monitoring the response time of the invocation request; in the case where the response time is greater than a preset time, determining that the application program interface corresponding to the invocation request has abnormal registration, and sending an alarm prompt information carrying abnormal registration data to the target object; in the case where the response time is less than or equal to the preset time, counting the number of invocations of the same application program interface.

[0090] Optionally, by actively monitoring the changes of the application program interfaces, and after discovering the changes, sending an update request to the target object (which may refer to the development team, operation and maintenance team, or automatic management system) managing these interfaces to inquire whether it is necessary to generate or update the tool function according to the new interface specification. This is a decision assistance mechanism that allows the target object to decide the update strategy based on business needs and change impact.

[0091] If no feedback is received from the target object within a preset time period, a predefined default update strategy will be enabled to process the application program interfaces with changes. This means that even if the target object fails to respond in time, automatic action can be taken to ensure that the tool function is synchronized with the latest API specification. The default strategy here may include automatically updating the tool function, ignoring the changes and continuing to use the original function, or starting a review by senior management, etc.

[0092] When the target object feeds back multiple update requirements within the preset period, the update requirement with the latest timestamp, i.e., the latest issuance time point, is used as the basis for processing. This is to avoid unnecessary confusion in the update process and ensure that each update is based on the latest instructions and information.

[0093] In addition, by recording the time consumption of each tool function in the registration on the model context protocol server, the efficiency of the registration process and possible bottlenecks can be evaluated.

[0094] If the registration time consumption exceeds the preset time consumption threshold, it is determined that this registration fails, and a message for re-registration is automatically fed back to try to register again. This may be caused by slow server response, network delay, or problems in the registration logic itself. On the contrary, if the time consumption is lower than the threshold, it is confirmed that the registration is successful, and a message for completing the registration is sent.

[0095] After the tool function is successfully registered and put into use, the response time of the API invocation request is monitored. This is to evaluate the actual running efficiency of the API, and also a means to detect potential problems.

[0096] If the response time of an API is found to be abnormally long, exceeding the preset time threshold, it is considered that the API may have abnormal registration, i.e., there is a problem in the registration process or parameter configuration, resulting in low calling efficiency. At this time, the target object will be sent an alarm information carrying abnormal registration data, prompting relevant personnel to troubleshoot and repair.

[0097] If the API response time is normal, i.e., within the preset time threshold, the number of calls to the same API is counted. This statistic can be used for various purposes, such as traffic analysis, hot interface identification, performance optimization basis, etc.

[0098] Through the implementation of the above content, the automatic processing of API specification changes, intelligent updating and maintenance of tool functions can be realized. At the same time, through the monitoring of registration time and calling response time, the efficiency and stability of tool function registration and API calling are ensured, and abnormal conditions can be found and handled in the first time, reducing the risk of system failure and improving the overall user experience and system performance. In addition, the statistical calling number helps to optimize resource allocation and improve the quality of API service. These mechanisms together constitute a robust, efficient, and automated system framework, supporting the dynamic integration and efficient interaction of intelligent large models and API services.

[0099] The execution subject of the above steps can be a server, a terminal, etc., but is not limited thereto.

[0100] In order to facilitate the understanding of the embodiments of the present application, the related scenarios are explained and described, but the present application is not limited thereto.

[0101] As an optional implementation, the present application optionally proposes a method and system for automatically generating MCP tools based on Swagger specifications, realizing the automatic, dynamic, and intelligent conversion of APIs to MCP tools. Specifically, by parsing Swagger definitions, tool functions conforming to MCP protocols are automatically generated, realizing seamless conversion of REST-API to MCP tools. This method does not need to modify the original service code, solving the problem of manually writing a large number of adaptation codes in traditional methods, significantly reducing the technical threshold of accessing related technical APIs to intelligent large models. The present application adopts innovative technologies such as multi-level parameter intelligent processing system, progressive authentication and authorization architecture, tool behavior standardization and exception handling mechanism, dynamic adaptive application programming interface proxy, multi-source application programming interface fusion technology, and tool semantic enhancement system, solving technical problems such as high API integration complexity, parameter processing difficulty, single authentication mechanism, and poor user experience in traditional methods. The present application also supports API white list filtering, multiple authentication mechanism integration, and parameter intelligent mapping, and has wide technical application value.

[0102] Optionally, a method for automatically generating MCP tools based on Swagger specifications includes the following steps: loading API metadata from a specified URL or file, including path, request method, parameter structure, and response type; parsing API information to extract endpoint information, parameter type, and authentication requirements; dynamically generating tool functions that comply with the MCP protocol based on the parsed information; registering the generated tool functions with the model context protocol server to support real-time AI model calls; and converting MCP tool calls into HTTP requests for the original API at runtime and processing response data.

[0103] Optionally, it further includes a whitelist filtering step, which only registers API endpoints in the specified whitelist as MCP tools to optimize the context length of AI (Artificial Intelligence) models. An identity authentication step supports Keycloak / OAuth2 authentication, API key authentication, and basic authentication, and dynamically switches authentication methods.

[0104] Optionally, the API parameter types are mapped to target language types, supporting date and time, binary, and nested objects.

[0105] Optionally, tool functions are created through dynamic code generation technology, including building function parameter signatures, generating function bodies, and dynamically executing code.

[0106] Optionally, tool names can be automatically constructed based on API prefixes, mapping API paths to hierarchical tool names.

[0107] Optionally, a semantic enhancement step uses natural language processing technology to analyze the description field of Swagger / OpenAPI documents to generate standardized MCP tool descriptions, improving the accuracy of AI model understanding.

[0108] Optionally, an API version adaptation step automatically updates MCP tool functions to adapt to API changes by comparing version differences in Swagger / OpenAPI definitions.

[0109] Optionally, the above method further includes an error handling step that automatically adjusts MCP tool call logic by analyzing API response status codes and error information, supporting retries, parameter corrections, or error feedback conversion.

[0110] Optionally, a multi-source application programming interface fusion step resolves conflicts between multiple Swagger / OpenAPI definitions through namespace isolation or parameter renaming to generate a unified set of MCP tools.

[0111] Optionally, the context compression step reduces the context length overhead of the AI model by compressing or layering the MCP tool descriptions, improving performance.

[0112] Optionally, the mapping step supports mapping OpenAPI parameter types to multiple programming language types, including Python, JavaScript, and Java, to generate MCP tool functions adapted to different running environments.

[0113] Optionally, the response post-processing step formats or aggregates API response data to adapt to the input requirements of the AI model.

[0114] Further, the above steps achieve the following effects:

[0115] 1. Automatic parsing: Load Swagger definitions from URLs or files, automatically parse API endpoints, parameters, authentication requirements, and other information.

[0116] 2. Dynamic tool generation: Based on dynamic code generation technology, automatically create tool functions that meet the MCP protocol.

[0117] 3. Whitelist filtering: Support API endpoint whitelist configuration, control the number of registered tools, and optimize the context length of the AI model.

[0118] 4. Multi-authentication mechanism: Integrate Keycloak / OAuth2, API key, basic authentication, and other authentication mechanisms to ensure API call security.

[0119] 5. Parameter intelligent mapping: Realize accurate conversion of OpenAPI parameter types to MCP tool parameter types, support complex data structures and special formats (such as date and time, binary).

[0120] 6. Dynamic registration and update: Support real-time detection of API changes, automatically update MCP tools without restarting services.

[0121] 7. Semantic enhancement: Analyze API document descriptions through natural language processing (NLP) technology, generate standardized MCP tool descriptions, and improve the understanding accuracy of the AI model.

[0122] 8. Version adaptation: Automatically detect version differences in Swagger definitions, update MCP tools to adapt to API changes.

[0123] 9. Error handling: Analyze API response status codes and error information, automatically adjust tool call logic, support retries and error feedback conversion.

[0124] 10. Multi-source API fusion: Support generating unified MCP toolset from multiple Swagger definitions, solve parameter naming conflicts, etc.

[0125] 11. Context compression: Reduce the context overhead of AI models through tool description compression and hierarchical registration.

[0126] 12. Cross-language support: Support mapping OpenAPI parameter types to multiple programming languages (such as Python, JavaScript, Java), and adapt to different runtime environments.

[0127] Optionally, Figure 3 is an automatic generation model context protocol tool system structure diagram according to the embodiment of the application, mainly comprising: a parser 301 corresponding to a tool data source, used to load and parse application programming interface definitions from uniform resource locators or files; a model context protocol tool generator 302, used to generate tool functions conforming to the model context protocol; a parameter mapping engine 303, used to map parameter types to model context protocol tool parameter types; an authentication management module 304, used to integrate and manage various authentication mechanisms; a whitelist filter 305, used to filter application programming interface endpoints according to configurations; a tool registration manager 306, used to register the generated tools to the model context protocol server. That is, through the above different components, a parser (such as a Swagger tool corresponding parser) is realized to load and parse application programming interface API definitions from uniform resource locators URL or files; a model context protocol tool generator is used to generate tool functions conforming to the model context protocol according to the parsing results; a parameter mapping engine is used to realize the mapping of Swagger tool (i.e. OpenAPI) parameter types to model context protocol tool parameter types; an authentication management module is used to handle the integration and management of various authentication mechanisms; a whitelist filter is used to filter application programming interface endpoints according to configurations; a tool registration manager is used to register the generated tools to the model context protocol server. In addition, the above system also includes a model context protocol server 308 and a client application 310 (such as a Cursor client, a Cherry studio client), a tool data source 312, which at least includes: a uniform resource locator (URL) corresponding to a remote tool (such as a Swagger tool) and a data format of the data source.

[0128] Optionally, Figure 4 is a flowchart of the running process of the automatic generation model context protocol tool system according to the embodiment of the application, comprising the following steps:

[0129] Step 1, Load the corresponding design tool (such as: Swagger tool) definition from the specified uniform resource locator or file (support HTTPS / HTTPS URL or local file).

[0130] Step 2, Parse the application programming interface path, method, parameter, and description information (including detecting authentication requirements).

[0131] Step 3, Filter the application programming interface endpoints according to the whitelist configuration (optional, control the number of tools).

[0132] Step 4, Dynamically generate model context protocol tool function code (including parameter mapping and type conversion), including: 4.1 Build function parameters, 4.2 Generate function body, 4.3 Dynamically create function objects.

[0133] Step 5, Register the generated tool function to the model context protocol server (automatically build hierarchical tool names).

[0134] Through the implementation of the above process, authentication information needs to be obtained, and the MCP tool call is converted into an actual API request at runtime.

[0135] As an optional implementation, the OpenAPI model and the Python / MCP type establish a corresponding relationship between different parameters through a mapping engine, such as: the string type parameter in the API may need to be converted to the str type in MCP, the integer type parameter in the API may need to be converted to the int type in MCP, the number type parameter in the API may need to be converted to the float type in MCP; The Boolean type parameter in the API may need to be converted to the bool type in MCP; The array type parameter in the API may need to be converted to the List[T] type in MCP; The object type parameter in the API may need to be converted to the Dict[str,Any] type in MCP; The String(format:date-time) type parameter in the API may need to be converted to the datetime type in MCP; The String(format:binary) type parameter in the API may need to be converted to the bytes type in MCP.

[0136] More complex parameter processing logic is achieved through a multi-level parameter intelligent processing system. Mainly includes the following contents: parameter dependency processing: automatically identify the explicit and implicit dependency between parameters, ensure the correct filling order; enumeration value intelligent mapping: provide semantic understanding and mapping for enumeration type parameters, so that the model can correctly select enumeration values; complex object recursive construction: for nested object types, provide recursive parameter construction capability; default value intelligent inference: automatically infer reasonable default parameter values based on historical call data and business rules; parameter verification and correction: perform parameter verification before calling, and automatically correct possible errors.

[0137] Optionally, Figure 5 is a process schematic diagram of tool semantic enhancement according to an embodiment of the application. Through a semantic enhancement system, the API description is automatically optimized to be more suitable for AI model understanding. The API document description is parsed through natural language processing (NLP) technology to generate a standardized MCP tool description, improving the understanding accuracy of the AI model. Specifically, in the case of obtaining an original application programming interface specification (swagger / openAPI definition), the application programming interface description text is extracted. Then, description automatic expansion and example code generation operations are performed on the description text. The description automatic expansion is used to automatically expand short or incomplete descriptions based on API naming and parameter analysis. The example code generation is used to automatically generate example calling code for complex operations. In addition, the description text can be input through an intelligent large model interface, and semantic relationship construction and domain term explanation operations are performed based on a domain knowledge base and an intelligent large model. The semantic relationship construction is used to establish a semantic relationship network between APIs to help the model understand the association between APIs. The domain term explanation is used to add explanations and descriptions of specific domain terms. Then, after all the above operations are completed, a semantic enhanced model context protocol tool is generated. Thus, the problem of model understanding difficulty caused by insufficient API document semantics and incomplete description is solved.

[0138] As an optional implementation, Figure 6is a structural schematic diagram of a multi-source application programming interface fusion subsystem according to an embodiment of the present application, and a multi-source application programming interface fusion technology is used to support unified generation of MCP tools from multiple sources (Swagger, OpenAPI, RAML, GraphQL, etc.). The multi-source application programming interface fusion technology is used to convert API definitions in different sources and formats into unified MCP tools, and includes: a multi-specification parsing adapter that is used to implement parsing adaptation for different API specifications; a unified intermediate representation module that is used to parse specifications of different data sources into a unified intermediate representation form, for example, an Open API V3.0 data source and an e-commerce system API are matched with a corresponding Open API V3.0 parser; a mixed API deduplication and merging module that is used to intelligently process repeated or similar APIs from different sources; and a cross-source reference parsing module that is used to process type reference relationships across different API sources.

[0139] Through the above multi-source application programming interface fusion, the following effects are achieved: complete coverage of modern API definition standards, comprehensive format support, automatic processing of API conflicts using multiple strategies, intelligent conflict resolution, semantic-level fusion of APIs beyond the syntax level, deep semantic understanding, special processing of cross-source reference relationships to ensure data model consistency, support for incremental updates and dynamic changes of API sources, and dynamic evolution support.

[0140] As an optional implementation, Figure 7 is a flowchart of a dynamic adaptability application programming interface proxy according to an embodiment of the present application, and includes:

[0141] Step 1, application programming interface change detection: determine the API specification provided by an application programming interface service provider, regularly detect API specification changes, including changes in paths, parameters, and return values, and synchronize change information to tool definition incremental updates.

[0142] Step 2, tool definition incremental update: support incremental updates to registered tools without completely rebuilding tool definitions, and synchronize change information of registered tools to a large model used to call MCP tools to update MCP tools.

[0143] Step 3, backward compatibility processing: when an API has a destructive change, process the API destructive change and provide a backward compatible processing mechanism; after completing the compatibility processing, the version history and compatibility information corresponding to the API metadata can be stored on an application programming interface metadata storage module, and the information corresponding to the compatibility data is updated to a change notification mechanism.

[0144] In the fourth step, a change notification mechanism is provided to notify the large model and the user of API changes, ensuring that the calling party is aware of the changes. The change notification mechanism synchronizes the corresponding metadata information to the model context protocol tool repository to update the tool definition and documentation based on the metadata information.

[0145] With the above proxy, real-time monitoring of API changes can be achieved, and automatic adaptation to updates in API specifications can be achieved, reducing maintenance costs and ensuring system continuous availability.

[0146] In summary, the present application provides a method and system for automatically generating MCP tools based on Swagger specifications. Through intelligent context awareness, multi-level parameter intelligent processing, progressive authentication and authorization, tool behavior standardization, dynamic adaptability application programming interface proxy, multi-source application programming interface fusion, and tool semantic enhancement, the present application solves various technical challenges in integrating existing RESTful API services into intelligent large models. The present application not only significantly reduces API integration costs, but also significantly improves the accuracy, success rate, and security of AI model API calls, while supporting dynamic adaptation to API changes and enhancing API semantic understanding. The present application has wide technical application value. In particular, the intelligent context awareness mechanism of the present application solves the model context length limitation problem in large-scale API integration scenarios, and the multi-level parameter intelligent processing system solves the problem of complex API parameter structure that is difficult for AI models to accurately process, opening up a new method for efficient integration of APIs and intelligent large models.

[0147] From the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and a general hardware platform as necessary, of course, it can also be realized by hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a ROM / RAM, a magnetic disk, or an optical disk) and includes a plurality of instructions for causing a terminal device (which can be a mobile phone, a computer, a server, or a network device) to execute the methods described in the various embodiments of the present application.

[0148] In this embodiment, an application programming interface calling device is also provided, which is used to implement the above embodiments and preferred embodiments, and will not be described again. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware or a combination of software and hardware is also possible and is contemplated.

[0149] Figure 8is a structural block diagram of a calling device of an application program interface according to an embodiment of the present application, as shown, the device comprises: Figure 8

[0150] The acquisition module 902 is configured to acquire an interface rule corresponding to each of the plurality of application program interfaces, to obtain a plurality of interface metadata.

[0151] The analysis module 904 is configured to analyze the plurality of interface metadata to obtain a plurality of interface parameter sets, wherein each interface parameter set at least includes: endpoint information corresponding to the application program interface, parameter types corresponding to the application program interface, and authentication requirements corresponding to the application program interface.

[0152] The first generation module 906 is configured to generate a plurality of tool functions based on the plurality of interface parameter sets and a preset function template, and register the plurality of tool functions on a model context protocol server.

[0153] The second generation module 908 is configured to generate a calling request for each application program interface based on a registration result and a corresponding relationship of the plurality of application program interfaces.

[0154] Through the above device, the interface definition is automatically obtained from a plurality of API sources, including a remote Swagger URL or a local file, and the endpoint information, parameter types and authentication requirements are parsed to form interface metadata. The parsed interface metadata is further processed to construct a clear interface parameter set, providing structured data support for subsequent tool function generation. Based on the constructed interface parameter set and the preset function template, the tool functions conforming to the MCP protocol are automatically generated through an intelligent mapping algorithm. The generated tool functions are registered to the model context protocol server, realizing the direct calling of the API by the intelligent large model, and the calling request is generated based on the corresponding relationship between the registration result and the API, optimizing the calling process and improving the calling efficiency. That is, by automatically parsing the interface rules of a plurality of APIs, the key metadata information such as endpoint information, parameter types and authentication requirements is extracted, and then the corresponding tool functions are automatically generated and registered, and finally the efficient calling of each API is realized. Thus, the problem of complex process and low efficiency in converting API interface specifications into MCP tools in related technologies is solved. The efficiency of converting API interface specifications into MCP tools is improved.

[0155] ​In an example embodiment, the apparatus further includes a filtering module configured to, after the parsing of the plurality of interface metadata to obtain the plurality of interface parameter sets, and in a case where authentication requirements carried in the interface metadata meet preset authentication requirements, filter the plurality of interface parameter sets based on endpoint information, wherein the filtering is configured to, in a case where the endpoint information is abnormal information that prohibits calling of an intelligent large model, identify the interface parameter set as prohibited from using data; and determine, based on a filtering result, a plurality of target interface parameter sets allowed to participate in tool function generation.

[0156] In an example embodiment, the first generating module is further configured to identify a plurality of target parameter types to which each interface parameter set belongs; determine, according to a mapping reference table associated with the preset function template, a plurality of target mapping strategies corresponding to the plurality of target parameter types, wherein the mapping reference table is configured to record a conversion relationship between an interface parameter type and an MCP parameter type; execute the plurality of target mapping strategies, and fill the preset function template according to an execution result to obtain a plurality of tool functions.

[0157] In an example embodiment, the apparatus further includes a first determining module configured to, after the execution of the plurality of target mapping strategies and the filling of the preset function template according to an execution result to obtain a plurality of tool functions, determine a dependency relationship between different processing parameters in the plurality of tool functions; and determine, based on the dependency relationship, a calling order corresponding to each tool function.

[0158] In an example embodiment, the apparatus further includes a third generating module configured to, before the execution of the plurality of target mapping strategies and the filling of the preset function template according to an execution result to obtain a plurality of tool functions, extract description information in the plurality of interface parameter sets to obtain a plurality of first texts; perform semantic enhancement processing on the plurality of first texts to obtain a plurality of second texts; and determine that the plurality of second texts are used to supplement description semantics of the preset function template before tool function generation.

[0159] In an example embodiment, the obtaining module is further configured to determine a plurality of rule sources corresponding to the plurality of application program interfaces; obtain a plurality of parsing adapters corresponding to the plurality of rule sources, and use the plurality of parsing adapters to perform standard parsing on different application program interfaces; perform uniform intermediate representation on a parsing result to obtain a plurality of interface data, wherein the uniform intermediate representation is standardization of the parsing result by using a preset standardized endpoint definition, a preset uniform parameter model, and a preset uniform response format; and determine the plurality of interface metadata based on the plurality of interface data.

[0160] In an example embodiment, the first generation module further includes a determination unit configured to perform change detection on the plurality of application program interfaces before registering the plurality of tool functions on the model context protocol server, wherein the change detection is configured to determine version iteration information and authentication requirement changes of the application program interfaces; and determine whether to perform incremental updates on the plurality of tool functions according to the change detection result.

[0161] In an example embodiment, the determination unit is further configured to, in a case where the change detection result indicates that there is no change in the application program interfaces, determine not to perform incremental updates on the plurality of tool functions, and trigger a start registration time of the plurality of tool functions; and in a case where the change detection result indicates that there is a change in the application program interfaces, determine to perform incremental updates on the plurality of tool functions, and locate target interfaces having the change in the plurality of application program interfaces by using the intelligent large model.

[0162] In an example embodiment, the determination unit further includes an obtaining subunit configured to, in a case where the change detection result indicates that there is a change in the application program interfaces, determine to perform incremental updates on the plurality of tool functions, and send interface information of the application program interfaces having the change to a target object; and obtain update requirements issued by the target object for the application program interfaces having the change.

[0163] In an example embodiment, the determination unit further includes an updating subunit configured to, in a case where the change detection result indicates that there is a change in the application program interfaces, determine to perform incremental updates on the plurality of tool functions, locate target interfaces having the change in the plurality of application program interfaces by using the intelligent large model, determine a change range and a change type corresponding to the target interfaces having the change, instruct the intelligent large model to customize a suitable interface update strategy based on the change range and the change type, wherein the interface update strategy includes at least one of the following: interface local update, interface complete reconstruction, and interface backward compatible conversion; and perform incremental updates on target tool functions corresponding to the target interfaces having the change by using the interface update strategy.

[0164] In an example embodiment, the apparatus further comprises an identification module configured to, based on the registration result and the correspondence between the plurality of application program interfaces, determine a load proportion corresponding to each model context protocol server in the case that there are a plurality of model context protocol servers; in the case that the load proportion is greater than or equal to a preset safe load proportion, identify the current model context protocol server as a full load state, and prohibit subsequent tool functions from being registered on the current model context protocol server; in the case that the load proportion is less than the preset safe load proportion, identify the current model context protocol server as a non-full load state, and allow subsequent tool functions to be registered on the current model context protocol server.

[0165] In an example embodiment, the identification module further comprises a setting unit configured to, in the case that there are a plurality of model context protocol servers, determine a target model context protocol server with the smallest load proportion from the plurality of model context protocol servers after determining the load proportion corresponding to each model context protocol server; and set the target model context protocol server as a backup server, wherein the backup server is used to back up registration data existing on other model context protocol servers except the target model context protocol server in the plurality of model context protocol servers.

[0166] In an example embodiment, the identification module further comprises a migration unit configured to, after setting the target model context protocol server as a backup server, configure a switching rule for the backup server, wherein the switching rule comprises at least one of: in the case that another model context protocol server fails, migrating all registration data on the failed server in the another model context protocol server to the backup server; and in the case that another model context protocol server has a load that is too high, migrating registration data exceeding the load proportion in the another model context protocol server to the backup server.

[0167] In an example embodiment, the obtaining sub-unit is configured to, after obtaining the update requirement issued by the target object for the application program interface with changes, in the case that the target object does not feed back the update requirement within a preset period, process the application program interface with changes using a predefined default update strategy; and in the case that the target object feeds back a plurality of update requirements within the preset period, process the plurality of update requirements with reference to the update requirement with the latest issue time point.

[0168] In an example embodiment, the apparatus further includes a second determining module configured to generate a plurality of tool functions based on the plurality of interface parameter sets and a preset function template, and record a registration time consumption of each tool function after registering the plurality of tool functions on a model context protocol server; determine that a current tool function registration fails and feed back a re-registration message if the registration time consumption is greater than or equal to a preset time consumption threshold; and determine that the current tool function registration succeeds and feed back a completed registration message if the registration time consumption is less than the preset time consumption threshold.

[0169] In an example embodiment, the apparatus further includes a monitoring module configured to monitor a response time of a calling request of each application program interface after generating the calling request based on a registration result and a corresponding relationship of the plurality of application program interfaces; determine that an abnormal registration exists in the application program interface corresponding to the calling request and send an alarm prompt information carrying abnormal registration data to a target object if the response time is greater than a preset time; and count a calling frequency of a same application program interface if the response time is less than or equal to the preset time.

[0170] It should be noted that each of the above modules can be implemented by software or hardware, and for the latter, the following implementation manners can be used, but are not limited thereto: all of the above modules are located in a same target processor; or each of the above modules is located in a different target processor in an arbitrary combination.

[0171] Embodiments of the present application also provide a computer readable storage medium having a computer program stored therein, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0172] Embodiments of the present application also provide an electronic device including a target memory having a computer program stored therein and a target processor configured to execute the computer program to perform the steps in any of the above method embodiments.

[0173] Embodiments of the present application also provide a computer program product including a computer program, which, when executed by a processor, implements the steps in any of the above method embodiments.

[0174] Embodiments of the present application also provide another computer program product including a non-volatile computer readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above method embodiments.

[0175] The embodiment of the present application further provides a computer program, which comprises computer instructions stored in a computer readable storage medium; a processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in any of the method embodiments.

[0176] The specific examples in the embodiment can refer to the examples described in the above embodiments and exemplary embodiments, and the embodiment will not be described herein again.

[0177] The skilled person can further realize that the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be realized by electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in the above description in general terms. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0178] Obviously, those skilled in the art should understand that the modules or steps of the present application described above can be realized by general computing devices, which can be concentrated on a single computing device or distributed on a network composed of N computing devices, and they can be realized by program codes executable by computing devices, so that they can be stored in storage devices and executed by computing devices, and in some cases, the steps shown or described can be executed in different order, or they can be manufactured into individual integrated circuit modules, or N modules or steps can be manufactured into a single integrated circuit module. Thus, the present application is not limited to any specific combination of hardware and software.

[0179] The above provides a detailed introduction to the calling method, device, equipment, storage medium and program of an application program interface. The principles and implementation manners of the present application are described by applying specific examples. The above embodiment descriptions are only used to help understand the method and core idea of the present application. It should be pointed out that, for those skilled in the art, without departing from the principles of the present application, some improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A method for invoking an application programming interface (API), characterized in that, include: Obtain the interface rules corresponding to each of the multiple application interfaces to obtain multiple interface metadata. Parse the multiple interface metadata to obtain multiple interface parameter sets, wherein each interface parameter set includes at least: endpoint information corresponding to the application interface, parameter type corresponding to the application interface, and authentication requirements corresponding to the application interface; Multiple utility functions are generated based on the multiple sets of interface parameters and preset function templates, and the multiple utility functions are registered on the model context protocol server; A request to call each application interface is generated based on the correspondence between the registration results and the multiple application interfaces. The generation of multiple utility functions based on the multiple interface parameter sets and preset function templates includes: Identify the parameter type to which each set of interface parameters belongs, and obtain multiple target parameter types; Based on the mapping lookup table associated with the preset function template, multiple target mapping strategies corresponding to the multiple target parameter types are determined, wherein the mapping lookup table is used to record the conversion relationship between interface parameter types and MCP parameter types; The multiple target mapping strategies are executed, and the preset function template is filled according to the execution results to obtain multiple utility functions.

2. The method for invoking the application programming interface according to claim 1, characterized in that, After parsing the multiple interface metadata to obtain multiple interface parameter sets, the method further includes: If the authentication requirements carried in the interface metadata meet the preset authentication requirements, the multiple interface parameter sets are filtered based on the endpoint information. The filtering process is used to mark the interface parameter sets as prohibited data when the endpoint information is abnormal information that the intelligent big model prohibits calls. Based on the filtering results, determine the set of multiple target interface parameters that are allowed to participate in the generation of the tool function.

3. The method for invoking the application programming interface according to claim 1, characterized in that, After executing the multiple target mapping strategies and filling the preset function template according to the execution results to obtain multiple utility functions, the method further includes: Determine the dependencies between different processing parameters in the plurality of tool functions; The calling order of each utility function is determined based on the aforementioned dependencies.

4. The method for invoking the application programming interface according to claim 1, characterized in that, Before executing the multiple target mapping strategies and filling the preset function template according to the execution results to obtain multiple utility functions, the method further includes: Extract the descriptive information from the multiple interface parameter sets to obtain multiple first texts; Semantic enhancement processing is performed on the multiple first texts to obtain multiple second texts; It is determined that the multiple second texts are used to supplement the descriptive semantics of the preset function template before generating the tool function.

5. The method for invoking the application programming interface according to claim 1, characterized in that, Retrieve the interface rules corresponding to each of the multiple application interfaces, and obtain multiple interface metadata, including: Determine the multiple rule sources corresponding to the multiple application programming interfaces; Obtain multiple parsing adapters corresponding to the multiple rule sources, and use the multiple parsing adapters to perform specification parsing on different application interfaces; The parsing results are represented in a unified intermediate representation to obtain multiple interface data. The unified intermediate representation is achieved by standardizing the parsing results through a preset standardized endpoint definition, a preset unified parameter model, and a preset unified response format. The metadata of the multiple interfaces is determined based on the data from those multiple interfaces.

6. The method for invoking the application programming interface according to claim 1, characterized in that, Before registering the plurality of utility functions on the Model Context Protocol server, the method further includes: Change detection is performed on the multiple application interfaces, wherein the change detection is used to determine the version iteration information of the application interfaces and changes in authentication requirements; Determine whether to incrementally update the multiple tool functions based on the change detection results.

7. The method for invoking the application programming interface according to claim 6, characterized in that, Determine whether to incrementally update the multiple tool functions based on the change detection results, including: If the change detection result indicates that there are no changes to the application interface, it is determined that no incremental updates will be performed on the multiple utility functions, and the start registration time of the multiple utility functions will be triggered. If the change detection result indicates that the application interface has changed, it is determined to perform incremental updates on the multiple tool functions, and the target interface with the change is located among the multiple application interfaces through the intelligent big model.

8. The method for invoking the application programming interface according to claim 7, characterized in that, If the change detection result indicates a change in the application interface, after determining to incrementally update the plurality of tool functions, the method further includes: Send the changed application interface information to the target object; Obtain the update request issued by the target object for the changed application interface.

9. The method for invoking the application programming interface according to claim 7, characterized in that, After determining that incremental updates are to be performed on the multiple tool functions and locating the target interface with changes among the multiple application interfaces using the intelligent large model, the method further includes: Determine the scope and type of changes corresponding to the target interface that has been modified; Based on the scope and type of change, the intelligent large model is instructed to customize a suitable interface update strategy, wherein the interface update strategy includes at least one of the following: partial interface update, complete interface reconstruction, and backward compatibility conversion of the interface; The interface update strategy is used to incrementally update the target utility function corresponding to the changed target interface.

10. The method for invoking an application programming interface according to claim 9, characterized in that, Before generating a call request for each application interface based on the correspondence between the registration results and the multiple application interfaces, the method further includes: When there are multiple Model Context Protocol (MCP) servers, determine the load percentage for each MCP server. If the load percentage is greater than or equal to the preset safe load percentage, the current model context protocol server will be marked as fully loaded, and subsequent utility functions will be prohibited from registering on the current model context protocol server. If the load percentage is less than the preset safe load percentage, the current model context protocol server is marked as not fully loaded, allowing subsequent utility functions to register on the current model context protocol server.

11. The method for invoking the application programming interface according to claim 10, characterized in that, When there are multiple Model Context Protocol (MCP) servers, after determining the load percentage of each MCP server, the method further includes: The target model context protocol server with the lowest load percentage is determined from multiple model context protocol servers; The target model context protocol server is set as a backup server, wherein the backup server is used to back up the registration data existing on the other model context protocol servers besides the target model context protocol server.

12. The method for invoking an application programming interface according to claim 11, characterized in that, After setting the target model context protocol server as a backup server, the method further includes: Configure a failover rule for the backup server, wherein the failover rule includes at least one of the following: In the event of a failure of other Model Context Protocol (MTP) servers, all registration data on the failed MTP servers will be migrated to the backup server. If other Model Context Protocol (MCP) servers are overloaded, the portion of registration data exceeding the load percentage from those other MCP servers will be migrated to the backup server.

13. The method for invoking the application programming interface according to claim 8, characterized in that, After obtaining the update request issued by the target object for the changed application interface, the method further includes: If the target object does not provide an update request within a preset period, a predefined default update strategy is used to process the changed application interface. If the target object submits multiple update requests within a preset period, the update request with the latest issuance time among the multiple update requests will be used as a reference for processing.

14. The method for invoking the application programming interface according to claim 1, characterized in that, After generating multiple utility functions based on the multiple interface parameter sets and preset function templates, and registering the multiple utility functions on the model context protocol server, the method further includes: Record the registration time for each utility function; If the registration time is greater than or equal to a preset time threshold, it is determined that the current utility function registration has failed, and a re-registration message is sent back. If the registration time is less than a preset time threshold, the current utility function is determined to be successfully registered, and a registration completion message is sent.

15. The method for invoking an application programming interface according to claim 1, characterized in that, After generating a call request for each application interface based on the correspondence between the registration results and the multiple application interfaces, the method further includes: Monitor the response time of the call request; If the response time is greater than a preset time, it is determined that the application interface corresponding to the call request has abnormal registration, and an alarm message carrying abnormal registration data is sent to the target object; If the response time is less than or equal to a preset time, the number of calls to the same application interface is counted.

16. A device for invoking an application programming interface (API), characterized in that, include: The acquisition module is used to obtain the interface rules corresponding to each of the multiple application interfaces and obtain multiple interface metadata. The parsing module is used to parse the multiple interface metadata to obtain multiple interface parameter sets, wherein each interface parameter set includes at least: endpoint information corresponding to the application interface, parameter type corresponding to the application interface, and authentication requirements corresponding to the application interface. The first generation module is used to generate multiple utility functions based on the multiple interface parameter sets and preset function templates, and to register the multiple utility functions on the model context protocol server; The second generation module is used to generate a call request for each application interface based on the correspondence between the registration results and the multiple application interfaces; The first generation module is further configured to identify the parameter type to which each interface parameter set belongs, thereby obtaining multiple target parameter types; determine multiple target mapping strategies corresponding to the multiple target parameter types according to the mapping lookup table associated with the preset function template, wherein the mapping lookup table is used to record the conversion relationship between interface parameter types and MCP parameter types; execute the multiple target mapping strategies, and fill the preset function template according to the execution results, thereby obtaining multiple utility functions.

17. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the method of invoking the application programming interface as described in any one of claims 1 to 15 when executing the computer program.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the method of invoking the application programming interface as described in any one of claims 1 to 15.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of calling the application programming interface as described in any one of claims 1 to 15.

Images