Method, device, system and equipment for providing third-party service for large language model

Abstract

The method, device, system and equipment for providing a third-party service for a large language model are disclosed. The method comprises: receiving an MCP service request sent by an MCP client, the MCP service request being a service request generated based on an intention of a large language model, comprising target service information and service parameters; obtaining a registered service description object corresponding to the target service information from an MCP service registry based on the MCP service request; obtaining a target callback function bound to the service description object; triggering execution of the target callback function and inputting the service parameters, so that the target callback function calls a third-party service pointed to by the service description object based on the service parameters; encapsulating a response result returned by the third-party service as an MCP response corresponding to the MCP service request, and returning the MCP response to the MCP client, so that the MCP client provides the MCP response to the large language model.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, specifically to a method, apparatus, system, and device for providing third-party services for large language models. Background Technology

[0002] With the rapid development of Large Language Model (LLM) technology, LLM has evolved from simple text generation into intelligent assistants capable of proactively invoking external capabilities. To enable LLM to read data sources, call interfaces, or perform operations, related technologies provide the Model Context Protocol (MCP), which offers a standardized communication specification for interaction between LLM and external tools.

[0003] However, the business system capabilities accumulated within an enterprise (usually in the form of RESTful APIs) cannot be directly called by the large language model. Instead, they need to be registered as tools conforming to the MCP protocol standard. Specifically, in the MCP architecture, the large language model typically runs within a host application. The MCP client within the host application translates the large language model's calling intent into standardized MCP service requests (e.g., JSON-RPC format requests) and sends them to the MCP server for execution. The MCP server then needs to register each business capability as a tool conforming to the MCP standard. This tool must at least declare metadata such as a tool identifier, functional description, and input parameter schema, and bind it to specific call execution logic to respond to protocol methods such as tool list queries and tool calls. In other words, while the MCP protocol unifies the interaction specifications between the large language model and external tools, the problem of "how to efficiently register existing enterprise business capabilities as tools conforming to the MCP standard" is not solved by the protocol itself and still relies on specific integration implementations. Currently, existing technologies mainly achieve the above registration through the following methods, but all have significant limitations:

[0004] (1) Hard-coded integration method

[0005] Currently, mainstream AI integration frameworks (such as Spring AI) typically require developers to manually write the tool description for each third-party tool in their application code. Specifically, developers need to use mechanisms such as the `@Tool` annotation or the `FunctionToolCallback` builder to write the name, description, and parameter schema for each tool. For example, when defining a tool to "query balance," its parameter schema often needs to be hardcoded into a fixed structure, such as: `inputSchema = {"type": "object", "properties": {"userId": {"type":"string"}}}`. This hard-coding approach has a high maintenance cost. On the one hand, internal enterprise APIs are usually maintained by the backend team and stored as metadata in a database or configuration; if hard-coding is used, the tool description and the underlying API metadata are separated into two different systems, easily leading to inconsistencies and difficulty in synchronization. On the other hand, whenever the API changes (e.g., adding fields, adjusting field types, or modifying interface paths), the application code needs to be modified accordingly, committed to a version control repository (such as Git), and recompiled, packaged, and deployed before the changes take effect. The entire process is lengthy and involves many steps, making it difficult to match the needs of rapid iteration and frequent trial and error in the application of large language models.

[0006] (2) Static file loading method

[0007] To avoid manually writing descriptions for each tool, some MCP implementations use a static file loading method: when the service starts, it reads the local static specification file (such as openapi.json or swagger.yaml), parses the file once, and registers all the interface paths in it as MCP tools.

[0008] While this approach avoids writing tool descriptions individually, it suffers from resource waste. Static file loading typically loads all interfaces at once per process, but in MCP application scenarios, different large language model applications or different tenants often only need to call a small portion of the tools. Loading all tools to runtime consumes significant memory resources (for example, in Java Virtual Machine (JVM) based implementations, a large number of tool objects residing in memory may lead to OutOfMemory (OOM) risks); furthermore, exposing irrelevant tools to the runtime environment introduces unnecessary security risks.

[0009] In summary, existing technologies for registering existing business capabilities as tools compliant with the MCP standard generally suffer from problems such as high maintenance costs and long release cycles due to hard coding, as well as resource waste, memory overflow, and security risks caused by full loading of static files. Therefore, there is an urgent need for a technical solution that can balance registration efficiency and resource consumption, enabling enterprises' existing business capabilities to be efficiently and dynamically registered as tools compliant with the MCP standard, allowing for secure and convenient invocation by large language models. Summary of the Invention

[0010] This disclosure provides a method, apparatus, system, and device for providing third-party services for large language models.

[0011] In a first aspect, this disclosure provides a method for providing third-party services for a large language model, including:

[0012] Receive MCP service requests sent by MCP clients. The MCP service requests are service requests generated based on intents of a large language model, including target service information and service parameters.

[0013] Based on the MCP service request, the registered service description object corresponding to the target service information is obtained by matching from the MCP service registry;

[0014] Retrieve the target callback function bound to the service description object;

[0015] The target callback function is triggered and the service parameters are passed in, so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters;

[0016] The response returned by the third-party service is encapsulated into an MCP response corresponding to the MCP service request and returned to the MCP client so that the MCP client can provide the MCP response to the large language model.

[0017] Further, the target callback function is triggered and the service parameters are passed in, so that the target callback function calls the third-party service pointed to by the service description object based on the service parameters, including:

[0018] After the target callback function is triggered, the service parameters are converted into the input parameter mode required to execute the third-party service according to the preset mapping rules;

[0019] Send a corresponding request to the third-party service, the corresponding request carrying the input parameter pattern.

[0020] Furthermore, the method also includes:

[0021] Obtain the OpenAPI specification description file of the third-party service;

[0022] Parse the OpenAPI specification description file to obtain the setting information in the OpenAPI specification description file;

[0023] The settings information is stored in the database.

[0024] Furthermore, the configuration information includes at least: metadata, service address information, and service interface path information; storing the configuration information in a database includes:

[0025] The metadata, service address information, and service interface path information are stored in three-level data tables in the database. The three-level data tables include a metadata data table, a service address information data table, and a service interface path information table. In the service interface path information table, different service interface path information is stored in different rows.

[0026] Furthermore, the method also includes:

[0027] In response to the tenant's dynamic loading command, register the third-party service corresponding to the tenant with the MCP service registry.

[0028] Furthermore, registering the third-party services corresponding to the tenant with the MCP service registry includes:

[0029] Retrieve the configuration information corresponding to the third-party service from the database;

[0030] A service description object is dynamically constructed in memory based on the aforementioned settings; the service description object conforms to the MCP protocol standard and includes at least the identification information, functional description, and input parameter mode of the third-party service.

[0031] The service description object is registered in the MCP service registry, and the service description object is bound to the corresponding target callback function. The callback function encapsulates a preset mapping rule for converting the MCP service request into a service request required to call the third-party service.

[0032] Furthermore, the third-party services include payment tools and / or payment interfaces.

[0033] Secondly, embodiments of this disclosure provide a method for providing third-party services for large language models, including:

[0034] The large language model receives natural language text input from the user;

[0035] The large language model generates text output based on the natural language text input;

[0036] If the text output indicates that a third-party service needs to be invoked, the MCP client generates an MCP service request based on the text output; the MCP service request includes target service information and service parameters.

[0037] The MCP client sends the MCP service request to the MCP server.

[0038] The MCP server obtains the registered service description object corresponding to the target service information from the MCP service registry based on the MCP service request.

[0039] The MCP server obtains the target callback function bound to the service description object;

[0040] The MCP server triggers the execution of the target callback function and passes in the service parameters, so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters;

[0041] The MCP server encapsulates the response returned by the third-party service into an MCP response corresponding to the MCP service request and returns it to the MCP client.

[0042] The MCP client provides the MCP response to the large language model.

[0043] Furthermore, the MCP server triggers the execution of the target callback function and passes in the service parameters, so that the target callback function calls the third-party service pointed to by the service description object based on the service parameters, including:

[0044] After the target callback function is triggered, the service parameters are converted into the input parameter mode required to execute the third-party service according to the preset mapping rules;

[0045] Send a corresponding request to the third-party service, the corresponding request carrying the input parameter pattern.

[0046] Furthermore, the method also includes:

[0047] The MCP server obtains the OpenAPI specification description file of the third-party service;

[0048] The MCP server parses the OpenAPI specification description file and obtains the setting information in the OpenAPI specification description file;

[0049] The MCP server stores the configuration information in the database.

[0050] Furthermore, the configuration information includes at least: metadata, service address information, and service interface path information; the MCP server stores the configuration information in a database, including:

[0051] The MCP server stores the metadata, service address information, and service interface path information in three-level data tables in the database. The three-level data tables include a metadata data table, a service address information data table, and a service interface path information table. In the service interface path information table, different service interface path information is stored in different rows.

[0052] Furthermore, the method also includes:

[0053] In response to the tenant's dynamic loading command, the MCP server registers the third-party service corresponding to the tenant with the MCP service registry.

[0054] Furthermore, in response to a tenant's dynamic loading command, the MCP server registers the third-party services corresponding to the tenant with the MCP service registry, including:

[0055] The MCP server retrieves the configuration information corresponding to the third-party service from the database;

[0056] The MCP server dynamically constructs a service description object in memory based on the configured information; the service description object conforms to the MCP protocol standard and includes at least the identification information, functional description, and input parameter mode of the third-party service.

[0057] The MCP server registers the service description object in the MCP service registry and binds the service description object to the corresponding target callback function. The callback function encapsulates a preset mapping rule for converting the MCP service request into a service request required to call the third-party service.

[0058] Furthermore, the third-party services include payment tools and / or payment interfaces.

[0059] Thirdly, embodiments of this disclosure provide an apparatus for providing third-party services for large language models, including:

[0060] The receiving module is configured to receive MCP service requests sent by the MCP client. The MCP service requests are service requests generated based on the intent of the large language model, including target service information and service parameters.

[0061] The first acquisition module is configured to obtain a registered service description object corresponding to the target service information by matching the MCP service registry based on the MCP service request.

[0062] The second acquisition module is configured to acquire the target callback function bound to the service description object;

[0063] The triggering module is configured to trigger the execution of the target callback function and pass in the service parameters, so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters;

[0064] The encapsulation module is configured to encapsulate the response returned by the third-party service into an MCP response corresponding to the MCP service request and return it to the MCP client so that the MCP client can provide the MCP response to the large language model.

[0065] Fourthly, embodiments of this disclosure provide a system for providing third-party services for a large language model, including: a large language model, an MCP client, and an MCP server; wherein,

[0066] The large language model receives natural language text input from the user;

[0067] The large language model generates text output based on the natural language text input;

[0068] If the text output indicates that a third-party service needs to be invoked, the MCP client generates an MCP service request based on the text output; the MCP service request includes target service information and service parameters.

[0069] The MCP client sends the MCP service request to the MCP server.

[0070] The MCP server obtains the registered service description object corresponding to the target service information from the MCP service registry based on the MCP service request.

[0071] The MCP server obtains the target callback function bound to the service description object;

[0072] The MCP server triggers the execution of the target callback function and passes in the service parameters, so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters;

[0073] The MCP server encapsulates the response returned by the third-party service into an MCP response corresponding to the MCP service request and returns it to the MCP client.

[0074] The MCP client provides the MCP response to the large language model.

[0075] The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above function.

[0076] In one possible design, the above-described device includes a memory and a processor. The memory stores one or more computer instructions that support the device in performing the corresponding methods described above, and the processor is configured to execute the computer instructions stored in the memory. The device may also include a communication interface for communicating with other devices or communication networks.

[0077] Fifthly, embodiments of this disclosure provide an electronic device, including a memory and a processor. The memory stores one or more computer instructions that support any of the aforementioned devices in executing the corresponding methods described above. The processor is configured to execute the computer instructions stored in the memory. Any of the aforementioned devices may further include a communication interface for communicating with other devices or communication networks.

[0078] In a sixth aspect, embodiments of this disclosure provide a computer-readable storage medium for storing computer instructions used by any of the above-described devices, including computer instructions for performing any of the above-described methods.

[0079] In a seventh aspect, embodiments of this disclosure provide a computer program product comprising computer instructions which, when executed by a processor, are used to implement the steps of the methods described in any of the preceding aspects.

[0080] The technical solutions provided in this disclosure may have the following beneficial effects:

[0081] First, the above solution decouples the "decision intent" of the large model from the "underlying execution" of the third-party service in both physical and logical terms. That is, the large model only needs to output standardized MCP service requests and does not need to be aware of the underlying protocol and parameter structure of the third-party service, which greatly reduces the development threshold of AI applications.

[0082] Secondly, the solution supports dynamic hot-swapping and seamless expansion of services: relying on the dynamic binding mechanism of the MCP service registry and callback functions, when adding or updating third-party services, only the new service description object needs to be registered on the server side, without modifying the code on the large model side or restarting the server, which greatly improves the availability and operation and maintenance efficiency of the system.

[0083] Finally, the solution also improves the standardization and security of communication: by using a unified MCP request and response format for data interaction, it standardizes the communication boundary between the large model and the external world, making the access of third-party services more secure, controllable and easy to manage.

[0084] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the embodiments of this disclosure. Attached Figure Description

[0085] Other features, objects, and advantages of embodiments of this disclosure will become more apparent from the following detailed description of non-limiting implementations, taken in conjunction with the accompanying drawings. In the drawings:

[0086] Figure 1 A flowchart illustrating a method for providing third-party services for a large language model according to an embodiment of the present disclosure is shown.

[0087] Figure 2 This diagram illustrates the structural block diagram of an application system that interacts with an artificial intelligence large language model (LLM) according to an embodiment of the present disclosure and an external third-party service.

[0088] Figure 3 This diagram illustrates the process of interaction between an AI Large Language Model (LLM) according to an embodiment of the present disclosure and an external third-party service.

[0089] Figure 4 A flowchart illustrating a method for providing third-party services for a large language model according to another embodiment of the present disclosure;

[0090] Figure 5 A structural block diagram of an apparatus for providing third-party services for a large language model according to an embodiment of the present disclosure is shown.

[0091] Figure 6 A block diagram of a system for providing third-party services for a large language model according to an embodiment of the present disclosure is shown.

[0092] Figure 7 This is a schematic diagram of the structure of a computer system suitable for implementing a method for providing third-party services for a large language model according to an embodiment of the present disclosure. Detailed Implementation

[0093] Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings to enable those skilled in the art to readily implement them. Furthermore, for clarity, portions unrelated to the description of the exemplary embodiments have been omitted from the drawings.

[0094] In embodiments disclosed herein, it should be understood that terms such as “comprising” or “having” are intended to indicate the presence of features, numbers, steps, behaviors, components, portions or combinations thereof disclosed herein, and are not intended to exclude the possibility that one or more other features, numbers, steps, behaviors, components, portions or combinations thereof are present or added.

[0095] It should also be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings and examples.

[0096] Based on the technical problems described in the background, this disclosure proposes a solution for providing third-party services for large language models. This solution is based on a standardized service invocation architecture using the MCP (Model Context Protocol), with the core idea being "dynamic binding of metadata and execution logic." Specifically, this solution pre-registers service description objects conforming to the MCP protocol in the MCP service registry and encapsulates the specific third-party invocation logic into callback functions, binding them to these objects. When an MCP service request generated by a large model is received, the system accurately locates and triggers the corresponding target callback function by matching the target service information. The callback function then completes the invocation of the actual third-party service.

[0097] First, the above solution decouples the "decision intent" of the large model from the "underlying execution" of the third-party service in both physical and logical terms. That is, the large model only needs to output standardized MCP service requests and does not need to be aware of the underlying protocol and parameter structure of the third-party service, which greatly reduces the development threshold of AI applications.

[0098] Secondly, the solution supports dynamic hot-swapping and seamless expansion of services: relying on the dynamic binding mechanism of the MCP service registry and callback functions, when adding or updating third-party services, only the new service description object needs to be registered on the server side, without modifying the code on the large model side or restarting the server, which greatly improves the availability and operation and maintenance efficiency of the system.

[0099] Finally, the solution also improves the standardization and security of communication: by using a unified MCP request and response format for data interaction, it standardizes the communication boundary between the large model and the external world, making the access of third-party services more secure, controllable and easy to manage.

[0100] Figure 1 A flowchart illustrating a method for providing third-party services for a large language model according to an embodiment of this disclosure is shown, such as... Figure 1 As shown, the method for providing third-party services for large language models includes the following steps:

[0101] In step S101, an MCP service request sent by the MCP client is received. The MCP service request is a service request generated based on the intent of the large language model, including target service information and service parameters.

[0102] In step S102, based on the MCP service request, the registered service description object corresponding to the target service information is obtained by matching from the MCP service registry;

[0103] In step S103, the target callback function bound to the service description object is obtained;

[0104] In step S104, the target callback function is triggered and the service parameters are passed in so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters;

[0105] In step S105, the response result returned by the third-party service is encapsulated into an MCP response corresponding to the MCP service request and returned to the MCP client so that the MCP client can provide the MCP response to the large language model.

[0106] It's important to note that while large language models possess powerful reasoning and understanding capabilities, they have traditionally been limited to text generation based on existing training data. MCP provides a standardized communication protocol for large models, enabling them to securely and systematically call external tools, access data sources, and perform operations (such as querying databases, sending emails, and calling APIs). This transforms large models from simple "question-answering tools" into proactive "intelligent assistants."

[0107] In the MCP architecture, the large language model typically runs within an application called the Host (such as Claude, ChatGPT, or various IDEs). The Host contains an MCP client, which acts as a "translator" between the large model and the external world. When the large model decides to use an external tool, the MCP client translates the model's intent into a standardized MCP service request (JSON-RPC request) and sends it to the corresponding MCP server for execution.

[0108] In this embodiment, the method is executed on the MCP server. When the large language model needs to call external capabilities (i.e., third-party services), it generates a standard MCP service request. This request contains the target service information (e.g., service name or identifier) ​​that the large model intends to call, as well as the service parameters extracted or generated by the large model. After receiving the request, the MCP server matches and obtains the service description object corresponding to the target service information from the service registry maintained in its memory. This service description object is essentially a dynamically constructed tool instance object in memory, conforming to the MCP protocol standard and containing service metadata. Subsequently, the target callback function pre-bound to the service description object can be obtained, and the service parameters passed in by the large model can be used as input parameters to trigger the execution of the callback function. The target callback function acts as the execution engine, responsible for transforming the large model's intent into a call to the actual third-party service. Finally, the response returned by the third-party service is encapsulated by the system into a standard MCP response and returned to the MCP client, which then provides it to the large language model for further inference or for display to the user.

[0109] In some optional embodiments, the execution of the target callback function is triggered, and the service parameters are passed in, so that the target callback function calls the third-party service pointed to by the service description object based on the service parameters, including:

[0110] After the target callback function is triggered, the service parameters are converted into the input parameter mode required to execute the third-party service according to the preset mapping rules;

[0111] Send a corresponding request to the third-party service, the corresponding request carrying the input parameter pattern.

[0112] In this optional implementation, the parameter format generated by the large language model often differs from the strict protocol required by the underlying third-party service during actual execution. Therefore, when the target callback function is triggered, it does not directly pass through the parameters from the large model. Instead, it reassembles and transforms the flattened service parameters from the large model into the input parameter pattern required to execute the third-party service, according to preset mapping rules. For example, specific parameters are extracted and appended to the URL path of the HTTP request, or authentication information is placed in the request header, and core business data is encapsulated in JSON format and placed in the request body. After the transformation is completed, the target callback function sends a corresponding request carrying the input parameter pattern to the third-party service, thereby ensuring that the third-party service can correctly parse and execute it.

[0113] In some alternative implementations, the method further includes:

[0114] Obtain the OpenAPI specification description file for third-party services;

[0115] Parse the OpenAPI specification description file to obtain the setting information in the OpenAPI specification description file;

[0116] The settings information is stored in the database.

[0117] In some optional implementations, the configuration information includes at least: metadata, service address information, and service interface path information; storing the configuration information in a database includes:

[0118] The metadata, service address information, and service interface path information are stored in three-level data tables in the database. The three-level data tables include a metadata data table, a service address information data table, and a service interface path information table. In the service interface path information table, different service interface path information is stored in different rows.

[0119] The aforementioned optional implementation provides an automated mapping scheme from OpenAPI specifications to database table structures. First, the standard OpenAPI specification description file provided by the third-party service is obtained and deeply parsed to extract its configuration information. This configuration information is structured and stored in a three-level database table to achieve fine-grained configuration management. Specifically, metadata (such as service name, version, description, global authentication method, etc.) is stored in the metadata table; service address information (such as base URL, environment address, etc.) is stored in the service address information table; and service interface path information (i.e., each independent Operation in the OpenAPI, including specific HTTP methods, paths, and parameter definitions) is stored in the service interface path information table. It should be noted that a third-party service can include multiple interfaces (i.e., multiple Operations). Correspondingly, in the service interface path information table, each independent interface operation is stored as a separate row. This fine-grained storage design lays the foundation for the subsequent dynamic generation of independent tool instances.

[0120] The following example illustrates how a database hierarchically stores configuration information for third-party services.

[0121] This embodiment no longer stores the complete OpenAPI JSON file, but instead breaks it down into a three-level table structure for storage:

[0122] McpToolMainInfo (Metadata Data Table): Stores metadata (title, version, description) for API documentation.

[0123] McpToolServer (Service Address Information Data Table): Stores storage addresses (Servers).

[0124] McpToolPath (Service Interface Path Information Table): The core table. Each API operation is stored as a single record, containing JSON fragments such as requestBody, responseBody, and components.

[0125] In some alternative implementations, the method further includes:

[0126] In response to the tenant's dynamic loading command, register the third-party service corresponding to the tenant with the MCP service registry.

[0127] Registering the third-party service corresponding to the tenant with the MCP service registry includes:

[0128] Retrieve the configuration information corresponding to the third-party service from the database;

[0129] A service description object is dynamically constructed in memory based on the aforementioned settings; the service description object conforms to the MCP protocol standard and includes at least the identification information, functional description, and input parameter mode of the third-party service.

[0130] The service description object is registered in the MCP service registry, and the service description object is bound to the corresponding target callback function. The callback function encapsulates a preset mapping rule for converting the MCP service request into a service request required to call the third-party service.

[0131] The aforementioned optional implementation provides hot-swappable services in a multi-tenant architecture. When a dynamic loading instruction is received from a tenant (e.g., initial tenant registration, on-demand loading triggered by a business request, or a tenant updating its configuration), the system responds by retrieving the configuration information of the third-party service corresponding to that tenant from the database. Subsequently, the system dynamically constructs a service description object in memory. This construction process includes: generating a JSON Schema conforming to the MCP protocol as input parameter patterns based on the parsed metadata, extracting the functional description, and generating a unique identifier. Most importantly, the system binds this service description object to a specific callback function, which encapsulates the aforementioned preset mapping rules—that is, how to convert MCP service requests into the underlying service requests required to call the third-party service. Finally, the bound utility instance object is registered in the in-memory routing table of the MCP service registry, enabling the large model to immediately discover and call the new service; the entire process requires no server restart.

[0132] The above implementation method is further described below through specific implementation examples.

[0133] When the system starts up or receives an update command, the `SpecUtils.buildOpenAPI()` method can be used to read data from the database and assemble it into a complete OpenAPI object.

[0134] Multi-location parameter normalization: Iterate through the paths of the OpenAPI object, and for each operation, merge the parameters scattered in the four locations of path, query, header, and requestBody of the OpenAPI object into a single JSON Schema object (i.e., the input parameter pattern of the service description object).

[0135] Reference resolution: Recursively resolves `$ref` references, expands oneOf, nested objects, and arrays, and generates an LLM-understandable flat JSON schema.

[0136] Subsequently, the executable MCP tool can be automatically generated using `FunctionToolCallback.builder()` and registered in `McpStatelessSyncServer`.

[0137] The above class names / method names (`SpecUtils.buildOpenAPI()`, `FunctionToolCallback.builder()`, `McpStatelessSyncServer`) are specific implementation examples used to help those skilled in the art understand this implementation method, and do not constitute a limitation on the scope of protection.

[0138] In some alternative implementations, the third-party service includes payment tools and / or payment interfaces.

[0139] The method in this embodiment is applicable to dynamic access in the financial payment field. The third-party service may specifically include various payment tools and / or payment interfaces. Since payment interfaces typically have complex parameter structures and strict signature verification requirements, through the normalization and dynamic binding mechanism of this embodiment, the large language model does not need to understand the complex protocols of the underlying payment gateway; it only needs to complete the invocation of payment tools through standardized MCP requests, greatly improving the feasibility and security of AI implementation in complex financial scenarios.

[0140] This disclosure is further described below with a complete system description of performing the above methods.

[0141] See Figure 2 As shown, this system is applied to the interaction scenario between the large language model (LLM) of artificial intelligence and external third-party services.

[0142] The system mainly includes:

[0143] Large Language Model Host (LLM Host) 201: Used to receive natural language commands from users, perform semantic understanding and intent recognition, and generate structured commands containing tool call intent.

[0144] MCP Server 202: This is the core execution entity of the present invention. It adopts a stateless architecture design and includes a dynamic registration module, a tool management module, and an execution engine.

[0145] External API 203: For example, a payment gateway, used to execute specific business logic and return the execution result.

[0146] Step S301: Dynamic registration of tools based on the OpenAPI specification. When the MCP server starts or runs, it reads the OpenAPI specification document of the third-party service from a pre-set database or configuration center. It parses the OpenAPI specification, extracting the interface path, request method, parameter definitions, and data structure. Based on the extracted information, it dynamically constructs a Tool Description Object in memory. This object conforms to the MCP protocol standard and defines the tool name, function description, and input parameter pattern (JSON Schema).

[0147] In addition, the service description object is registered in the MCP service registry and bound to the corresponding target callback function. The target callback function encapsulates the preset mapping rules for converting MCP request parameters into HTTP request parameters required by the third-party service.

[0148] Step S302: The MCP client sends a JSON-RPC request to the MCP server, the request carrying the target tool name and execution parameters.

[0149] The execution engine of the MCP server receives the request and searches the registry based on the tool name in the request.

[0150] If a matching service description object is found, the target callback function corresponding to that object is locked.

[0151] Step S303: The execution engine triggers the target callback function, passing in the parameters from the JSON-RPC request. The callback function converts the flattened JSON-RPC parameters into a specific format required by the third-party service interface (such as nested JSON bodies, specific header authentication information, etc.) according to preset mapping rules.

[0152] The MCP server sends standardized HTTP / HTTPS requests to third-party service interfaces (such as payment gateways).

[0153] Step S304: After the third-party service interface completes its execution, it returns a response. The MCP server receives this result, encapsulates it into a JSON-RPC response format according to the MCP protocol standard, and sends it back to the large language model via the MCP client. The large language model then generates the final natural language response for the user.

[0154] This embodiment has the following significant advantages:

[0155] Dynamic and scalable: By parsing the OpenAPI specification to dynamically generate tool descriptions, new payment interfaces can be connected or existing interfaces can be updated without modifying the MCP server-side code or restarting the service, greatly reducing operation and maintenance costs.

[0156] Standardized decoupling: By using the MCP protocol as an intermediate layer, the large language model is decoupled from specific payment channels. The large model does not need to be concerned with the specific implementation details of the underlying payment interface, but only needs to interact through the standard protocol.

[0157] High availability: The stateless mode is used to handle requests, enabling the MCP server to support horizontal scaling and adapt to high-concurrency payment call scenarios.

[0158] Figure 4 A flowchart illustrating a method for providing third-party services for a large language model according to another embodiment of this disclosure is shown, such as... Figure 4 As shown, the method includes the following steps:

[0159] In step S401, the large language model receives the user's natural language text input;

[0160] In step S402, the large language model generates text output based on the natural language text input;

[0161] In step S403, if the text output indicates that a third-party service needs to be called, the MCP client generates an MCP service request based on the text output; the MCP service request includes target service information and service parameters.

[0162] In step S404, the MCP client sends the MCP service request to the MCP server;

[0163] In step S405, the MCP server obtains the registered service description object corresponding to the target service information from the MCP service registry based on the MCP service request.

[0164] In step S406, the MCP server obtains the target callback function bound to the service description object;

[0165] In step S407, the MCP server triggers the execution of the target callback function and passes in the service parameters so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters;

[0166] In step S408, the MCP server encapsulates the response result returned by the third-party service into an MCP response corresponding to the MCP service request and returns it to the MCP client.

[0167] In step S409, the MCP client provides the MCP response to the large language model.

[0168] The steps corresponding to this embodiment are Figure 1 The execution subject and processing logic described in the embodiments correspond to each other, with the difference being that... Figure 4 The embodiment describes the complete interactive perspective from "Large Language Model - MCP Client - MCP Server". Details of the various optional implementation methods involved (preset mapping rule conversion, OpenAPI parsing and three-level table storage, dynamic tenant loading and registration, third-party services including payment tools / payment interfaces, etc.) can be found in [link to documentation]. Figure 1 to Figure 3 The description of the corresponding embodiments will not be repeated here.

[0169] In some optional implementations, the MCP server triggers the execution of the target callback function, passing in the service parameters, so that the target callback function calls the third-party service pointed to by the service description object based on the service parameters, including:

[0170] After the target callback function is triggered, the service parameters are converted into the input parameter mode required to execute the third-party service according to the preset mapping rules;

[0171] Send a corresponding request to the third-party service, the corresponding request carrying the input parameter pattern.

[0172] In some alternative implementations, the method further includes:

[0173] The MCP server obtains the OpenAPI specification description file of the third-party service;

[0174] The MCP server parses the OpenAPI specification description file and obtains the setting information in the OpenAPI specification description file;

[0175] The MCP server stores the configuration information in the database.

[0176] In some optional implementations, the configuration information includes at least: metadata, service address information, and service interface path information; the MCP server stores the configuration information in a database, including:

[0177] The MCP server stores the metadata, service address information, and service interface path information in three-level data tables in the database. The three-level data tables include a metadata data table, a service address information data table, and a service interface path information table. In the service interface path information table, different service interface path information is stored in different rows.

[0178] In some alternative implementations, the method further includes:

[0179] In response to the tenant's dynamic loading command, the MCP server registers the third-party service corresponding to the tenant with the MCP service registry.

[0180] In some optional implementations, the MCP server responds to a tenant's dynamic loading command by registering the third-party service corresponding to the tenant with the MCP service registry, including:

[0181] The MCP server retrieves the configuration information corresponding to the third-party service from the database;

[0182] The MCP server dynamically constructs a service description object in memory based on the configured information; the service description object conforms to the MCP protocol standard and includes at least the identification information, functional description, and input parameter mode of the third-party service.

[0183] The MCP server registers the service description object in the MCP service registry and binds the service description object to the corresponding target callback function. The callback function encapsulates a preset mapping rule for converting the MCP service request into a service request required to call the third-party service.

[0184] In some alternative implementations, the third-party service includes payment tools and / or payment interfaces.

[0185] For details of the method for providing third-party services for large language models in the above embodiments, please refer to [link to relevant documentation]. Figures 1-3 The details described in the corresponding embodiments will not be repeated here.

[0186] Figure 5 The diagram illustrates a structural block diagram of an apparatus for providing third-party services for a large language model according to an embodiment of the present disclosure. This apparatus can be implemented as part or all of an electronic device through software, hardware, or a combination of both. Figure 5 As shown, the device includes:

[0187] The receiving module 501 is configured to receive an MCP service request sent by an MCP client. The MCP service request is a service request generated based on the intent of a large language model, including target service information and service parameters.

[0188] The first acquisition module 502 is configured to obtain a registered service description object corresponding to the target service information from the MCP service registry based on the MCP service request.

[0189] The second acquisition module 503 is configured to acquire the target callback function bound to the service description object;

[0190] Trigger module 504 is configured to trigger the execution of the target callback function and pass in the service parameters so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters;

[0191] The encapsulation module 505 is configured to encapsulate the response returned by the third-party service into an MCP response corresponding to the MCP service request and return it to the MCP client so that the MCP client can provide the MCP response to the large language model.

[0192] Figure 6 This diagram illustrates a structural block diagram of a system for providing third-party services for a large language model according to an embodiment of the present disclosure. This device can be implemented as part or all of an electronic device through software, hardware, or a combination of both. Figure 6 As shown, the system includes: a large language model 601, an MCP client 602, and an MCP server 603; wherein,

[0193] The large language model receives natural language text input from the user;

[0194] The large language model generates text output based on the natural language text input;

[0195] If the text output indicates that a third-party service needs to be invoked, the MCP client generates an MCP service request based on the text output; the MCP service request includes target service information and service parameters.

[0196] The MCP client sends the MCP service request to the MCP server.

[0197] The MCP server obtains the registered service description object corresponding to the target service information from the MCP service registry based on the MCP service request.

[0198] The MCP server obtains the target callback function bound to the service description object;

[0199] The MCP server triggers the execution of the target callback function and passes in the service parameters, so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters;

[0200] The MCP server encapsulates the response returned by the third-party service into an MCP response corresponding to the MCP service request and returns it to the MCP client.

[0201] The MCP client provides the MCP response to the large language model.

[0202] The technical features and their corresponding explanations and descriptions involved in the above-described device embodiments or system embodiments are the same as, corresponding to, or similar to the technical features and their corresponding explanations and descriptions involved in the above-described method embodiments. For the technical features and their corresponding explanations and descriptions involved in the above-described device embodiments, please refer to the technical features and their corresponding explanations and descriptions involved in the above-described method embodiments. This disclosure will not repeat them here.

[0203] This disclosure also discloses an electronic device, which includes a memory and a processor; wherein...

[0204] The memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement any of the above method steps.

[0205] Figure 7 This is a schematic diagram of the structure of a computer system suitable for implementing a method for providing third-party services for a large language model according to an embodiment of the present disclosure.

[0206] like Figure 7As shown, the computer system 700 includes a processing unit 701, which can execute various processes described above based on a program stored in a read-only memory (ROM) 702 or a program loaded from a storage section 708 into a random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the computer system 700. The processing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0207] The following components are connected to I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 710 as needed so that computer programs read from it can be installed into storage section 708 as needed. The processing unit 701 can be implemented as a CPU, GPU, TPU, FPGA, NPU, etc.

[0208] In particular, according to embodiments of this disclosure, the methods described above can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program containing program code for performing the methods described above. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711.

[0209] This disclosure also discloses a computer program product, which includes a computer program / instructions that, when executed by a processor, implement any of the above-described method steps.

[0210] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0211] The units or modules described in the embodiments of this disclosure can be implemented in software or hardware. The described units or modules can also be located in a processor, and the names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0212] In another aspect, embodiments of this disclosure also provide a computer-readable storage medium, which may be a computer-readable storage medium included in the apparatus described in the above embodiments; or it may be a standalone computer-readable storage medium not assembled into a device. The computer-readable storage medium stores one or more programs, which are used by one or more processors to perform the methods described in embodiments of this disclosure.

[0213] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for providing third-party services for large language models, comprising: Receive MCP service requests sent by MCP clients. The MCP service requests are service requests generated based on intents of a large language model, including target service information and service parameters. Based on the MCP service request, the registered service description object corresponding to the target service information is obtained by matching from the MCP service registry; Retrieve the target callback function bound to the service description object; The target callback function is triggered and the service parameters are passed in, so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters; The response returned by the third-party service is encapsulated into an MCP response corresponding to the MCP service request and returned to the MCP client so that the MCP client can provide the MCP response to the large language model.

2. The method according to claim 1, characterized in that, Trigger the execution of the target callback function, passing in the service parameters, so that the target callback function calls the third-party service pointed to by the service description object based on the service parameters, including: After the target callback function is triggered, the service parameters are converted into the input parameter mode required to execute the third-party service according to the preset mapping rules; Send a corresponding request to the third-party service, the corresponding request carrying the input parameter pattern.

3. The method according to claim 1, characterized in that, The method further includes: Obtain the OpenAPI specification description file of the third-party service; Parse the OpenAPI specification description file to obtain the setting information in the OpenAPI specification description file; The settings information is stored in the database.

4. The method according to claim 3, characterized in that, The configuration information includes at least: metadata, service address information, and service interface path information; the configuration information is stored in a database, including: The metadata, service address information, and service interface path information are stored in three-level data tables in the database. The three-level data tables include a metadata data table, a service address information data table, and a service interface path information table. In the service interface path information table, different service interface path information is stored in different rows.

5. A method for providing third-party services for large language models, comprising: The large language model receives natural language text input from the user; The large language model generates text output based on the natural language text input; If the text output indicates that a third-party service needs to be invoked, the MCP client generates an MCP service request based on the text output; the MCP service request includes target service information and service parameters. The MCP client sends the MCP service request to the MCP server. The MCP server obtains the registered service description object corresponding to the target service information from the MCP service registry based on the MCP service request. The MCP server obtains the target callback function bound to the service description object; The MCP server triggers the execution of the target callback function and passes in the service parameters, so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters; The MCP server encapsulates the response returned by the third-party service into an MCP response corresponding to the MCP service request and returns it to the MCP client. The MCP client provides the MCP response to the large language model.

6. An apparatus for providing third-party services for large language models, comprising: The receiving module is configured to receive MCP service requests sent by the MCP client. The MCP service requests are service requests generated based on the intent of the large language model, including target service information and service parameters. The first acquisition module is configured to obtain a registered service description object corresponding to the target service information by matching the MCP service registry based on the MCP service request. The second acquisition module is configured to acquire the target callback function bound to the service description object; The triggering module is configured to trigger the execution of the target callback function and pass in the service parameters, so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters; The encapsulation module is configured to encapsulate the response returned by the third-party service into an MCP response corresponding to the MCP service request and return it to the MCP client so that the MCP client can provide the MCP response to the large language model.

7. A system for providing third-party services for large language models, comprising: Large Language Model. MCP client and MCP server; among them, The large language model receives natural language text input from the user; The large language model generates text output based on the natural language text input; If the text output indicates that a third-party service needs to be invoked, the MCP client generates an MCP service request based on the text output; the MCP service request includes target service information and service parameters. The MCP client sends the MCP service request to the MCP server. The MCP server obtains the registered service description object corresponding to the target service information from the MCP service registry based on the MCP service request. The MCP server obtains the target callback function bound to the service description object; The MCP server triggers the execution of the target callback function and passes in the service parameters, so that the target callback function can call the third-party service pointed to by the service description object based on the service parameters; The MCP server encapsulates the response returned by the third-party service into an MCP response corresponding to the MCP service request and returns it to the MCP client. The MCP client provides the MCP response to the large language model.

8. An electronic device comprising a memory and a processor; wherein, The memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the steps of the method according to any one of claims 1-5.

9. A computer-readable storage medium having computer instructions stored thereon, wherein, When executed by a processor, the computer instructions implement the steps of the method according to any one of claims 1-5.

10. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1-5.

Images