Database-driven MCP tool dynamically generates and runs runtime synchronization methods

Abstract

The application relates to a database-driven MCP tool dynamic generation and runtime synchronization method, system, computer device and storage medium. The method comprises the following steps: reading configuration records containing tool names, input parameter modes and output formatting rules from a database; constructing a tool definition object according to the input parameter mode; generating a tool callback instance according to the configuration record, which, when called, generates parameter data by verifying and converting incoming parameters, calls an external service to obtain an execution result, and renders a formatted result according to the output formatting rule; registering the callback instance and the tool definition object to an MCP server; when a configuration record is changed, generating an updated callback instance, removing the old registration and adding a new registration, and issuing a change notification through an MCP protocol notification mechanism. The application can complete tool extension and update without modifying the code and restarting the service.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method, system, computer device, and storage medium for dynamically generating and synchronizing MCP tools based on a database-driven approach. Background Technology

[0002] The Model Context Protocol (MCP) is an open protocol introduced by Anthropic, designed to standardize the interaction between large language models and external tools and data sources. Based on the MCP protocol, developers can encapsulate business capabilities into standardized tools for large language models to dynamically discover and invoke during dialogue. The Spring AI framework provides a complete implementation of MCP. Developers declare tools on Java methods using the `@Tool` annotation, and the framework scans and registers these tools with the MCP server when the application starts. The MCP protocol itself supports the server dynamically updating the list of available tools at runtime. The server can manage tools through the `addTool` and `removeTool` methods and notify clients of changes to the tool list using `notifyToolsListChanged`.

[0003] However, in existing Spring AI MCP implementations, although runtime tool updates are supported at the protocol level, tool declarations still rely on static declarations via code annotations. Adding, modifying, or deleting a tool requires modifying the `@Tool` annotated methods in the Java source code, recompiling and packaging, and restarting the MCP server and all connected clients. This method of binding tool definitions to source code results in long and inefficient tool extension and change cycles. Summary of the Invention

[0004] Based on this, it is necessary to provide a database-driven method, system, computer device, and storage medium for dynamically generating and synchronizing MCP tools at runtime without restarting the service, which can achieve dynamic generation of database configuration and hot synchronization of tools at runtime without restarting the service.

[0005] Firstly, this application provides a method for dynamically generating and synchronizing MCP tools based on a database driver. The method includes: Read tool configuration records from the database, the tool configuration records including tool name, input parameter mode and output formatting rules; The tool defines an object based on the input parameter pattern; Generate tool callback instances based on the tool configuration records; In response to the invocation of the tool callback instance, the input parameters are validated and type-converted to generate parameter data. Based on the parameter data, an external service is invoked and the execution result is obtained. Based on the output formatting rules, the execution result is formatted and rendered to generate a formatted result. Register the tool callback instance and the tool definition object to the MCP server, where the MCP server is a server-side component that provides tool invocation services to the outside world based on the Model Context Protocol. In response to detecting a change in the tool configuration record in the database, an updated tool callback instance is generated based on the changed tool configuration record. The registration corresponding to the old tool callback instance generated based on the previous tool configuration record is removed from the MCP server. The updated tool callback instance is registered to the MCP server. A tool list change notification is sent through the notification mechanism of the MCP protocol.

[0006] In one embodiment, the tool configuration record further includes a plugin mapping identifier; the step of calling an external service based on the parameter data and obtaining the execution result includes: The target external service plugin is determined based on the plugin mapping identifier; Obtain the access token of the external service platform to which the target external service plugin belongs; Construct a request message including the plug-in mapping identifier and the parameter data based on the parameter data; The request message is sent to the external service platform; The system receives the execution result returned by the external service platform and extracts the current task identifier and the next task identifier from the execution result to construct task execution chain data. The task execution chain data is used to record the task flow path of this tool call.

[0007] In one embodiment, the validation and type conversion of the input parameters includes: The input parameters are validated for type, numerical range, string length, required fields, and enumeration values. Missing parameters are filled with default values ​​in the input parameter pattern. The input parameters are also converted to the target data type declared in the input parameter pattern.

[0008] In one embodiment, formatting and rendering the execution result according to the output formatting rules includes: Extract the format type identifier and format configuration data from the output formatting rules; In response to the format type identifier being a table format, the data source path, column definition set, and table style identifier are extracted from the format configuration data. Two-dimensional data is extracted from the execution result according to the data source path. The two-dimensional data is column-mapped according to the column definition set. The corresponding table builder is called according to the table style identifier to generate table text. The table builder is a pre-configured formatting component for generating table format text. In response to the format type being identified as a markup language format, a template string is extracted from the format configuration data, and the data from the execution result is filled into the variable placeholders in the template string to generate markup language text. In response to the format type being identified as JSON, the execution result is output as JSON text.

[0009] In one embodiment, removing the registration corresponding to the old tool callback instance generated based on the tool configuration record before the change from the MCP server includes: Get the set of tool names previously registered to the MCP server and define it as the previous tool name set; get the set of tool names corresponding to the updated tool callback instance to be registered and define it as the current tool name set; The difference between the previous set of tool names and the current set of tool names is taken as the set of tool names to be removed; For each tool name in the set of tool names to be removed, the corresponding registration is removed through the tool removal interface of the MCP server.

[0010] In one embodiment, registering the updated tool callback instance to the MCP server includes: The difference between the current set of tool names and the previous set of tool names is used as the set of tool names to be added; The callback instances in the updated tool callback instances that correspond to the set of tool names to be added are converted into synchronous tool specification objects of the MCP server. The synchronous tool specification objects correspond to the tool definition objects and are used to provide the MCP server with the specification information required for tool registration. For each synchronization tool specification object, registration is completed through the add tool interface of the MCP server.

[0011] In one embodiment, the operation of reading tool configuration records from the database and registering the tool callback instance to the MCP server is performed during the application startup phase and the runtime phase, respectively. During the application startup phase, initial registration is performed based on tool configuration records in the database with an enabled status, and incremental synchronization during the runtime phase is disabled after the initial registration is completed. After the application enters the ready state, incremental synchronization during the runtime phase is enabled, and a check for changes to the tool configuration records in the database is performed to synchronize configuration changes occurring after the application startup phase to the MCP server.

[0012] Secondly, this application also provides a database-driven MCP tool dynamic generation and runtime synchronization system. The system includes: A configuration reading module is used to read tool configuration records from the database. The tool configuration records include the tool name, input parameter mode, and output formatting rules. A tool definition construction module is used to construct a tool definition object based on the input parameter pattern; The callback generation module is used to generate tool callback instances based on the tool configuration record. The tool execution module is used to respond to the invocation of the tool callback instance, to validate and convert the input parameters to generate parameter data, to call external services and obtain execution results based on the parameter data, and to format and render the execution results according to the output formatting rules to generate formatted results. The registration module is used to register the tool callback instance and the tool definition object to the MCP server, where the MCP server is a server-side component that provides tool invocation services to the outside world based on the model context protocol. The synchronization management module is used to respond to the detection of a change in the tool configuration record in the database, generate an updated tool callback instance based on the changed tool configuration record, remove the registration corresponding to the old tool callback instance generated based on the tool configuration record before the change from the MCP server, register the updated tool callback instance to the MCP server, and issue a tool list change notification through the notification mechanism of the MCP protocol.

[0013] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the aforementioned database-driven MCP tool dynamic generation and runtime synchronization method.

[0014] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the aforementioned method for dynamically generating and synchronizing the database-driven MCP tool.

[0015] The aforementioned database-driven MCP tool dynamic generation and runtime synchronization methods, systems, computer devices, and storage media achieve configuration-based management of tool definitions by storing tool configurations in the database. Adding or modifying a tool only requires adding or changing configuration records in the database to take effect, without modifying source code, compiling and packaging, or restarting the service, thus shortening the tool expansion cycle. By reading tool configuration records from the database and constructing tool definition objects based on input parameter patterns, automated generation of tool signatures is achieved, avoiding manual writing of tool definition code. By generating tool callback instances based on tool configuration records, and automatically performing parameter validation and type conversion, external service calls, and result formatting and rendering when these instances are invoked, unified template processing of tool execution logic is achieved, eliminating the need to write separate callback implementation classes for each tool. By registering tool callback instances and tool definition objects with the MCP server, large language models can discover and invoke these dynamically generated tools through the MCP protocol. By responding to changes in database configuration records, updated tool callback instances are automatically generated, old tool registrations are removed from the MCP server and new tool registrations are added. At the same time, tool list change notifications are sent through the MCP protocol's notification mechanism, achieving runtime tool hot synchronization. This allows MCP clients to perceive and use the updated tool list without restarting. Attached Figure Description

[0016] Figure 1 This is an application environment diagram of a database-driven MCP tool-based dynamic generation and runtime synchronization method in one embodiment; Figure 2 This is a flowchart illustrating a database-driven MCP tool's dynamic generation and runtime synchronization method in one embodiment. Figure 3 This is a flowchart illustrating the process of obtaining execution results in one embodiment; Figure 4 Here is a block diagram of a database-driven MCP tool-based dynamic generation and runtime synchronization system in one embodiment; Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. First, to facilitate understanding of the technical solutions provided by the embodiments of this application, the background technology involved in the embodiments of this application will be described below.

[0018] The Model Context Protocol (MCP) is an open protocol introduced by Anthropic, designed to standardize the interaction between large language models and external tools and data sources. MCP employs a client-server architecture, using JSON-RPC communication to achieve dynamic tool discovery, secure invocation, and flexible expansion. In the MCP protocol specification, the server announces its available tool capabilities by providing a tool list (tools / list) to the client. The client discovers and invokes the tools provided by the server through this list. When the server's tool list changes, servers that have declared the `listChanged` capability can send a notification (notifications / tools / list_changed) to connected clients, allowing the client to retrieve the tool list again upon receiving the notification.

[0019] The Spring AI framework provides a complete Java implementation of the MCP protocol, allowing developers to declare tools on Java methods using the `@Tool` annotation. The framework scans methods annotated with `@Tool` at application startup, hands these tools over to the MCP server for management via `ToolCallbackProvider`, and automatically registers the tools. Spring AI also provides the `McpToolUtils` utility class, used to convert Spring AI's `ToolCallback` instances into MCP tool registration objects.

[0020] However, in existing Spring AI MCP implementations, tool declarations rely on static declarations via code annotations. Developers need to mark tool methods in the Java source code using the `@Tool` annotation, and the framework completes tool scanning and registration all at application startup. This method of binding tool definitions to source code introduces a series of problems. When adding, modifying, or deleting tools, developers must modify the `@Tool` annotated methods in the Java source code, recompile and package the application, and restart the MCP server and all connected MCP clients for the changes to take effect. The entire process involves multiple steps, including code modification, compilation and building, and service restart, resulting in inefficient tool expansion and changes. This deficiency is particularly prominent in scenarios such as security operations that require frequent updates to tool capabilities, where there is a clear contradiction between the need for rapid deployment of new vulnerability query plugins, new threat intelligence interfaces, and other tools, and the lengthy change cycle.

[0021] Although the MCP protocol specification itself provides runtime management tools such as addTool and removeTool, as well as the notifications / tools / list_changed notification mechanism, and Spring AI's MCP implementation also provides corresponding API support, the existing solutions still remain at the level of statically declaring tools through code annotations, failing to fully utilize the runtime dynamic capabilities provided by the protocol to achieve configurable management and hot synchronization of tool definitions.

[0022] Therefore, embodiments of this application provide a method, system, computer device, and storage medium for dynamically generating and synchronizing MCP tools based on a database driver.

[0023] The database-driven MCP tool dynamic generation and runtime synchronization method provided in this application can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store data that server 104 needs to process, such as tool configuration records. The data storage system can be integrated onto server 104 or located in the cloud or on other network servers. Server 104 reads tool configuration records from the data storage system, constructs tool definition objects based on the input parameter patterns in the tool configuration records, and generates tool callback instances based on the tool configuration records. Server 104 registers the tool definition objects and tool callback instances with the MCP server, enabling the large language model to discover and invoke the corresponding tool functions through the MCP protocol. The MCP server is a server-side component that provides tool invocation services based on the Model Context Protocol. It can be deployed independently on server 104 or on other servers that communicate with server 104. Terminal 102 runs an MCP client, which discovers and invokes the tools registered by server 104 by establishing a connection with the MCP server. When the tool configuration record in the data storage system changes, server 104 generates an updated tool callback instance based on the changed configuration record, removes the old tool registration based on the previous configuration record from the MCP server, registers the updated tool callback instance to the MCP server, and sends a tool list change notification to connected MCP clients through the MCP protocol's notification mechanism. In response to this notification, the MCP client on terminal 102 retrieves the updated tool list from the MCP server to obtain the changed tool invocation capabilities. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, or portable wearable devices, all running an MCP client or a large language model client. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0024] Firstly, as mentioned earlier, in the existing Spring AI MCP implementation, tool declaration relies on static declaration via code annotations. Developers need to mark tool methods in the Java source code using the `@Tool` annotation, and the framework completes tool scanning and registration once at application startup. When adding, modifying, or deleting tools, developers must modify the `@Tool` annotated methods in the Java source code, recompile and package the application, and restart the MCP server and all connected MCP clients for the changes to take effect. This entire process involves multiple steps, including code modification, compilation and building, and service restart, resulting in inefficient tool expansion and changes. Therefore, in one embodiment, such as... Figure 2 As shown, a method for dynamically generating and synchronizing MCP tools based on database drivers is provided, which can be applied to... Figure 1Taking server 104 as an example, the following steps are included: S1: Read the tool configuration record from the database. The tool configuration record includes the tool name, input parameter mode, and output formatting rules. S2: Construct a tool definition object based on the input parameter pattern; S3: Generate tool callback instances based on tool configuration records; S4: In response to the invocation of the tool callback instance, validate and convert the input parameters to generate parameter data, call the external service based on the parameter data and obtain the execution result, and format and render the execution result according to the output formatting rules to generate a formatted result; S5: Register the tool callback instance and the tool definition object to the MCP server. The MCP server is a server-side component that provides tool invocation services to the outside world based on the model context protocol. S6: In response to detecting a change in the tool configuration record in the database, generate an updated tool callback instance based on the changed tool configuration record, remove the registration corresponding to the old tool callback instance generated based on the previous tool configuration record from the MCP server, register the updated tool callback instance to the MCP server, and send a tool list change notification through the notification mechanism of the MCP protocol.

[0025] Specifically, tool configuration records are read from the database. The database can be a relational database, such as MySQL, PostgreSQL, or Oracle. A tool configuration table is pre-created in the database to store the definition information of all tools available for use by the large language model. A tool configuration record is a single data record in this table, with each record corresponding to one MCP tool. The tool configuration record includes the tool name, input parameter pattern, and output formatting rules. The tool name is the unique identifier of the tool in the MCP protocol, used to uniquely identify the tool in the MCP server; the large language model uses this name to call the corresponding tool. The input parameter pattern defines the structure, type, required fields, and default values ​​of the parameters required to call the tool; the input parameter pattern can be defined using JSON Schema format. The output formatting rules define how the tool's execution results are rendered, including the type of output format and the corresponding formatting configuration data. The tool configuration record may also include fields such as a plugin mapping identifier and an activation status. The plugin mapping identifier is used to associate the tool with plugins on external service platforms, and the activation status controls whether the tool is available. When retrieving tool configuration records from the database, you can use Structured Query Language (SQL) queries, such as "SELECT * FROM mcp_methods WHERE is_enabled = 1" to query all tool configuration records with an enabled status. In practical applications, object-relational mapping frameworks such as MyBatis-Plus can also be used to simplify database operations.

[0026] The tool definition object (GDE) is the core object in the MCP protocol that describes the tool signature (including tool name, description, and parameter structure), directly determining whether the large language model can correctly understand and invoke the tool. The construction process of the GDE is as follows: The input parameter pattern is extracted from the tool configuration record; this input parameter pattern is a string in JSON Schema format; the JSON Schema format input parameter pattern is parsed into a parameter structure description that the GDE can recognize; and combined with information such as the tool name and tool description, a complete GDE is generated. The GDE contains the tool's metadata information, such as the tool name, description, and the JSON Schema definition of the input parameters. This GDE will subsequently be used to provide the tool's specification information when registering the tool with the MCP server.

[0027] A tool callback instance is an object that implements a specific callback interface, which defines the execution logic when the tool is invoked. The process of generating a tool callback instance involves extracting information such as the tool name, input parameter pattern, output formatting rules, and plugin mapping identifier from the tool configuration record. Based on this configuration information, an instance object implementing the callback interface is dynamically created. This instance object holds a reference to the tool configuration record, and when the instance is invoked, it will perform the corresponding operation according to the configuration information it holds. In the Spring AI framework, tool callback instances can be created by implementing the ToolCallback interface. The generation of tool callback instances can be implemented using the factory pattern or the builder pattern, generating callback instances with differentiated behaviors through a unified callback class template and different configuration data.

[0028] When the large language model decides to invoke a tool, it sends a tool invocation request to the MCP server via the MCP protocol. This request includes the tool name and input parameters. Upon receiving the request, the MCP server invokes the corresponding tool callback instance. When the tool callback instance is invoked, it first extracts the input parameters from the invocation request. These parameters are typically JSON-formatted strings. Then, it validates and performs type conversion on the input parameters according to the input parameter pattern in the tool configuration record. Validation includes checking whether the input parameters conform to the type, format, and constraints declared in the input parameter pattern. Type conversion involves converting the input parameters from JSON-formatted strings or numbers to the target data type declared in the input parameter pattern, such as converting a string-type number to an integer type. After successful validation and type conversion, validated and converted parameter data is generated. This parameter data is a structured collection of key-value pairs, where the key is the parameter name and the value is the validated and type-converted parameter value.

[0029] After parameter validation and type conversion are completed, the tool callback instance invokes an external service based on the parameter data. This external service can be an automation plugin provided by the SOAR platform, a third-party API, a database query service, or any other callable business service. When invoking an external service, the parameter data is passed as input. The external service executes the corresponding business logic and returns the execution result. The execution result is typically structured data in JSON format, containing the business data processed by the external service.

[0030] After receiving the execution result returned by the external service, the tool callback instance formats and renders the result according to the output formatting rules in the tool configuration record. The output formatting rules define how the execution result is displayed, including the format type identifier (e.g., table format, markup language format, or JSON format) and the corresponding formatting configuration data. Formatting rendering converts the raw execution result data into human-readable formatted text, enabling the large language model to present the tool's execution result to the user in a clear and structured manner.

[0031] The MCP server is a server-side component that provides tool invocation services based on the Model Context Protocol. After generating tool callback instances and tool definition objects, both are registered with the MCP server. The registration process involves: converting the tool definition object into a tool specification object at the MCP protocol layer, which contains the tool's name, description, and parameter structure definition; and associating the tool callback instance with the tool specification object, enabling the MCP server to invoke the corresponding tool callback instance to execute the tool logic when it receives an invocation request for that tool. After registration, the MCP server can then provide the tool discovery and invocation capabilities to connected MCP clients.

[0032] Tool configuration records in the database may change due to additions, deletions, and modifications by operations personnel. The system detects changes to tool configuration records in the database through periodic checks or event triggers. When a change is detected, the system reads the modified tool configuration record from the database and regenerates the tool callback instance based on the modified record. The process of generating the updated tool callback instance is the same as the process described above for generating tool callback instances based on tool configuration records.

[0033] After generating the updated tool callback instance, the registration corresponding to the old tool callback instance needs to be removed from the MCP server to avoid conflicts caused by the coexistence of tools with the same name in both the old and new versions on the MCP server. When removing the registration, the corresponding tool registration is deleted from the MCP server based on the name of the old tool.

[0034] After removing the old tool registration, the updated tool callback instance is registered with the MCP server. The registration process is the same as the previous process of registering the tool callback instance with the MCP server. By removing the old registration and then adding the new registration, a smooth tool update is achieved.

[0035] After removing and adding tools, a tool list change notification is sent to all connected MCP clients via the MCP protocol's notification mechanism. This notification informs the clients that the tool list on the MCP server has changed, and upon receiving the notification, the clients can proactively retrieve the latest tool list from the MCP server. In this way, clients can perceive and use the updated tool list without restarting.

[0036] Based on the above, this embodiment achieves configuration-based management of tool definitions by storing tool configurations in a database. Adding or modifying a tool only requires adding or modifying configuration records in the database to take effect, without modifying source code, compiling and packaging, or restarting the service, thus shortening the tool expansion cycle. By reading tool configuration records from the database and constructing tool definition objects based on input parameter patterns, automated generation of tool signatures is achieved. By generating tool callback instances based on tool configuration records, and enabling these instances to automatically perform parameter validation and type conversion, external service calls, and result formatting and rendering when invoked, unified template processing of tool execution logic is achieved. By registering tool callback instances and tool definition objects with the MCP server, the large language model can discover and invoke these dynamically generated tools through the MCP protocol. By responding to changes in database configuration records, automatically generating updated tool callback instances, removing old tool registrations from the MCP server and adding new tool registrations, and simultaneously issuing tool list change notifications through the MCP protocol's notification mechanism, runtime tool hot synchronization is achieved.

[0037] When encapsulating automation plugins from external service platforms into an MCP tool, the traditional approach requires writing separate adaptation code for each plugin, including authentication logic, request construction logic, and result parsing logic. Each time a new plugin is integrated, a similar set of adaptation code needs to be rewritten, resulting in a large development workload and difficult maintenance. Therefore, in one embodiment, the tool configuration record also includes plugin mapping identifiers. For example... Figure 3 As shown, the process involves calling an external service based on parameter data and obtaining the execution result, including: Identify the target external service plugin based on the plugin mapping identifier; Obtain the access token of the external service platform to which the target external service plugin belongs; Construct a request message that includes the plugin mapping identifier and parameter data based on the parameter data; Send the request message to the external service platform; It receives the execution results returned by the external service platform and extracts the current task identifier and the next task identifier from the execution results to construct task execution chain data. The task execution chain data is used to record the task flow path of this tool call.

[0038] Specifically, the tool configuration record also includes a plugin mapping identifier. In the tool configuration table `mcp_methods`, the `plugin_name` field is the plugin mapping identifier. The plugin mapping identifier is a name used by the external service platform to uniquely identify an automation plugin; for example, "ipReputationQuery" represents an IP reputation query plugin, and "threatIntelQuery" represents a threat intelligence query plugin. The external service platform can be a Security Orchestration Automated Response (SOAR) platform. External service plugins are pre-developed automated function modules on the external service platform, such as IP address lookup plugins, threat intelligence query plugins, or asset scanning plugins.

[0039] The value of the `plugin_name` field is extracted from the tool configuration record and used as a plugin mapping identifier. This identifier is then used to locate the corresponding target external service plugin on the external service platform. There is a one-to-one mapping relationship between the plugin mapping identifier and the external service plugin, allowing for the unique identification of the external service plugin to be invoked.

[0040] Before calling the Application Programming Interface (API) of an external service platform, authentication is required to obtain an access token. The access token is a credential used to prove that the caller has the authority to access the external service platform's API. The process of obtaining an access token involves sending a Hypertext Transfer Protocol (HTTP) request to the external service platform's authentication interface. The authentication request includes a pre-configured username and password (or API key). After the external service platform verifies the authentication information, it returns an access token. Access tokens have a limited validity period and can be reused within that period. In practice, access tokens use the JSON Web Token (JWT) format. A JWT consists of a header, payload, and signature. The payload contains metadata information such as the token's expiration time (exp). After obtaining the access token, it is stored in memory for subsequent calls. When the access token expires (e.g., an HTTP status code 401 indicating unauthorized access), a new access token is obtained.

[0041] The request message is the message body of an HTTP request sent to an external service platform. The construction process of the request message is as follows: the plugin mapping identifier and the validated and type-converted parameter data are assembled according to the format required by the external service platform. The request message format is JSON, and its structure includes a plugin mapping identifier field and a parameter field. Specifically, the request message is constructed as a JSON object of type {"toolFunctionName": pluginName, "params": params}, where the value of the toolFunctionName field is the plugin mapping identifier (i.e., the value of the plugin_name field), and the value of the params field is the validated and type-converted parameter data (i.e., the parameter data, of type Map).<String, Object> ).

[0042] After constructing the request message, an HTTP POST request is sent to the API interface of the external service platform via an HTTP client. The HTTP request header contains the previously obtained access token, specifically placed in the Authorization request header, for example, Authorization: Bearer.<access_token> ,in<access_token> This is the obtained access token string. The HTTP request body is a constructed JSON-formatted request message, with the Content-Type field in the request header set to application / json. When sending the request, use an HTTP client utility such as Java's HttpClient, OkHttp, or Spring's RestTemplate.

[0043] Upon receiving the request message, the external service platform invokes the corresponding external service plugin to execute the relevant function based on the value of the `toolFunctionName` field (i.e., the plugin mapping identifier), and returns the plugin's execution result as an HTTP response. The execution result is structured data in JSON format, containing the business data resulting from the external service plugin's execution. For example, for an IP reputation query plugin, the execution result includes fields such as IP address, reputation level, and threat tag. Upon receiving this HTTP response, the platform extracts the JSON string of the execution result from the response message body and parses it into a Map.<String, Object> Objects of type [type].

[0044] In addition to business data, the execution results returned by the external service platform may also contain task flow information. The current task identifier (currentTaskId) is a unique identifier for the current task corresponding to this tool call. The next task identifier (nextTaskId) is a unique identifier for the next task recommended by the external service platform. The specific method for extracting the current task identifier and next task identifier from the execution result is as follows: search for the currentTaskId and nextTaskId fields in the execution result JSON object; if they exist, extract their values; otherwise, set them to null. The extracted current task identifier and next task identifier are then encapsulated together with the business data into task execution chain data. The task execution chain data is a Map.<String, Object> The object contains the `data` field (raw business data), the `curTask` field (current task name and identifier), the `nextTask` field (next task name and identifier), and the `analysisResult` field (formatted analysis result). The task execution chain data records the task flow path of this tool call, facilitating subsequent task orchestration and process tracking.

[0045] Based on the above, this embodiment achieves configurable invocation of different external service plugins through a unified plugin mapping and identification mechanism, eliminating the need to write separate adaptation code for each plugin and thus reducing development workload. A unified authentication and request message construction process simplifies the integration complexity with external service platforms. By extracting the current task identifier and the next task identifier to construct task execution chain data, a data foundation is provided for subsequent task orchestration and process automation.

[0046] When a tool callback instance is invoked, the parameters passed in from the large language model need to be validated and their types converted to ensure they conform to the tool's definition requirements. Traditionally, parameter validation and type conversion logic is hard-coded into various tool methods, requiring each tool to repeatedly write the same validation code, leading to code redundancy and a high risk of errors. Therefore, in one embodiment, the validation and type conversion of the passed parameters includes: The system performs type validation, numeric range validation, string length validation, required field validation, and enumeration value validation on the input parameters. It also fills in missing parameters according to the default values ​​in the input parameter pattern and converts the input parameters to the target data type declared in the input parameter pattern.

[0047] Specifically, the input parameter is a JSON-formatted parameter string passed in by the large language model via the MCP protocol. Upon receiving the input parameter, a JSON parsing library (such as Jackson or Gson) is first called to parse the JSON-formatted parameter string into a collection of key-value pairs (Map).<String, Object> The key is the parameter name, and the value is the parameter value. If the passed parameter is an empty string or null, an empty key-value pair collection is created as the default value.

[0048] Type validation checks whether the value of an input parameter conforms to the data type declared in the input parameter schema. The input parameter schema (input_schema) is in JSON Schema format, where a type (type field) is defined for each parameter. Types include string, integer, number, boolean, array, and object. During type validation, the actual Java type of the input parameter is compared with the declared JSON Schema type. For integer types, it checks if the input parameter is an integer (Integer or Long); for string types, it checks if the input parameter is a string (String); for number types, it checks if the input parameter is an integer or floating-point number (Integer, Long, Float, or Double); for boolean types, it checks if the input parameter is a boolean (Boolean); for array types, it checks if the input parameter is a collection type (List or Array); and for object types, it checks if the input parameter is a Map type. If the types do not match, a validation exception is thrown, and the exception message includes the parameter name, expected type, and actual type.

[0049] Numeric range validation applies only to numeric parameters (integer or number). The input parameter pattern allows defining minimum and maximum fields for numeric parameters, where minimum represents the minimum allowed value and maximum represents the maximum allowed value. During range validation, the values ​​of the minimum and maximum fields are read from the input parameter pattern. If they exist, the value of the input parameter is checked to ensure that minimum <= value <= maximum (including boundary values). If not, a validation exception is thrown, with the exception message containing the parameter name, the allowed range ([minimum, maximum]), and the actual value.

[0050] String length validation applies only to string parameters. The input parameter pattern can define minimum length (minLength) and maximum length (maxLength) fields for string parameters, where minLength represents the minimum allowed number of characters and maxLength represents the maximum allowed number of characters. During string length validation, the values ​​of the minLength and maxLength fields are read from the input parameter pattern. If they exist, the length of the input parameter string is checked to ensure that minLength <= length <= maxLength (including boundary values). If not, a validation exception is thrown, and the exception message includes the parameter name, the allowed length range, and the actual length.

[0051] In the input parameter pattern, a `required` array declares which parameters are required, where each element is the name of a required parameter. During required parameter validation, each parameter name in the `required` array is iterated over to check if that parameter name exists in the key-value pair set of the input parameters (i.e., whether a corresponding value has been provided). If any required parameter is missing, a validation exception is thrown, and the exception message contains a list of missing required parameter names.

[0052] In the input parameter pattern, an enumeration array can be used to define a set of allowed values ​​for the parameter. Each element in the enumeration array is an allowed value. During enumeration value validation, the values ​​(an array) of the enumeration field are read from the input parameter pattern. If they exist, it is checked whether the value of the input parameter is included in the enumeration value set. If not, a validation exception is thrown, and the exception message includes the parameter name, the list of allowed enumeration values, and the actual value.

[0053] In the input parameter pattern, a default value field can be defined for the parameters. For parameters that are missing from the input parameters (i.e., do not exist in the key-value pair set of the input parameters) but for which a default value is defined in the input parameter pattern, the default value is used to fill the gap; that is, the parameter name and the corresponding default value are added to the key-value pair set of the input parameters. For non-required parameters that are missing from the input parameters and for which no default value is defined, no processing is performed on them (i.e., they are not added to the parameter data).

[0054] After validation and default value population, the values ​​of the input parameters are converted from their original JSON format type to the target data type declared in the input parameter pattern. The specific rules for type conversion are as follows: if the declared target type is integer, the string value is converted to integer using the `Integer.parseInt()` method; if the declared target type is number, the string value is converted to floating-point number using the `Double.parseDouble()` method; if the declared target type is boolean, the string value "true" or "false" is converted to boolean using the `Boolean.parseBoolean()` method; if the declared target type is string, the original value remains unchanged. After type conversion, validated and type-converted parameter data is generated; this parameter data is a Map.<String, Object> The type, where the value of each parameter has been converted to the target data type declared in the input parameter pattern.

[0055] Based on the above, this embodiment ensures the validity and completeness of input parameters by performing type validation, numerical range validation, string length validation, required field validation, and enumeration value validation, thereby avoiding tool execution failures due to parameter errors. By filling in missing parameters with default values ​​from the input parameter pattern, the fault tolerance of tool calls is improved. By converting input parameters to the target data type declared in the input parameter pattern, JSON format parameters passed from the large language model can be correctly converted to the target data type, thus ensuring the correct parameter type for subsequent external service calls.

[0056] After obtaining the execution results from external services, the results need to be rendered according to a predefined format so that the large language model can be presented to the user in a clear and structured manner. Traditionally, the output format is hard-coded into various utility methods, requiring each tool to implement its own formatting logic. Changing the output format necessitates code modification and redeployment, resulting in poor flexibility. Therefore, in one embodiment, the execution results are formatted and rendered according to output formatting rules, including: Extract the format type identifier and format configuration data from the output formatting rules; In response to the format type being identified as a table format, the data source path, column definition set, and table style identifier are extracted from the format configuration data. Two-dimensional data is extracted from the execution result based on the data source path. The two-dimensional data is then mapped to columns based on the column definition set. The corresponding table builder is called based on the table style identifier to generate table text. The table builder is a pre-configured formatting component used to generate table format text. In response to the format type being identified as markup language format, a template string is extracted from the format configuration data, and the data from the execution result is used to fill the variable placeholders in the template string to generate markup language text. In response to the format type being identified as JSON, the execution result will be output as JSON text.

[0057] Specifically, the output formatting rule is the content of the `output_schema` field in the tool configuration record, and its format is a JSON object. The output formatting rule includes a format type identifier (the `format` field) and formatting configuration data. The format type identifier indicates the format type of the output result, and its values ​​include "json", "markdown", "html", "table", and "custom". The formatting configuration data is the configuration information that varies depending on the format type and is stored in other fields of the output formatting rule JSON object.

[0058] A table format (table) is used to render an execution result into text in table form. A data source path (dataSource), a column definition set (columns) and a table style identifier (style) are extracted from formatting configuration data. The data source path is a path expression pointing to the data to be rendered in the execution result. For example, "data.records" indicates obtaining a data object from the execution result, and then obtaining a records array from the data object. If the execution result is {"data": {"records":[{"ip": "1.1.1.1", "reputation": "high"}, {"ip": "2.2.2.2", "reputation": "medium"}]}}, then the two-dimensional data extracted by the data source path "data.records" is an array containing two elements, and each element is a Map object. When two-dimensional data is extracted from the execution result according to the data source path, a path parser is used to access fields in the JSON object of the execution result level by level, and an exception is thrown if a certain intermediate level field does not exist. The two-dimensional data is an array (List<Map<String, Object>>), wherein each element represents a row of data in the table, each element itself is a Map object, the key is a field name, and the value is a field value. The column definition set defines the column structure of the table, and each column definition in the column definition set includes: a table header (header, string type), which represents the name of the table column and is displayed in the first row of the table; a data field name (field, string type), which represents the field name for extracting the column data from the two-dimensional data; a fallback field (fallback, string type, optional), which represents an alternative field name to be used when the value corresponding to the data field name does not exist; a formatter (formatter, string type, optional), which represents the name of a function used to format data; a default value (defaultValue, of any type, optional), which represents a default value to be used when neither the data field name nor the fallback field exists. Column mapping is performed on the two-dimensional data according to the column definition set. The column mapping process is as follows: for each row (i.e., each Map object) in the two-dimensional data, traverse each column definition in the column definition set, extract the corresponding field value from the Map of the current row according to the data field name (field) in the column definition, if the field value does not exist (i.e., the Map does not contain the key), extract with the fallback field (fallback), and if the fallback field also does not exist, use the default value (defaultValue). The extracted and filled data is used to generate table columns according to the table headers (header) in the column definitions, that is, each row of data is converted into a set of column values, and each column value corresponds to one table header.The table style identifier (style) indicates the style of the table, with values ​​including "github" (for a GitHub-style Markdown table) and "html" (for an HTML table). The corresponding table builder is invoked based on the table style identifier to generate the table text. Table builders are pre-configured formatting components for generating table-formatted text, including MarkdownTableBuilder and HtmlTableBuilder. MarkdownTableBuilder generates GitHub-style Markdown tables, which use vertical bars (|) to separate columns and horizontal bars (-) to separate the table header and body. HtmlTableBuilder generates HTML tables, which use... 、 、 、 and HTML tags are used to construct the table structure. The table builder receives the data after column mapping (List). <Map<String,Object> >) and List definition collection (List <columndefinition>This generates a table text string in the corresponding format.

[0059] Markup language formats (Markdown or HTML) are used to render the execution results as markup language text, such as Markdown or HTML. A template string (template field) is extracted from the formatted configuration data. The template string is a text template containing variable placeholders, which indicate the positions where data from the execution results should be filled in. Variable placeholders use double curly braces syntax; for example, {{data.ip}} indicates that the value of the ip field under the data object in the execution result should be filled in that position, and {{analysisResult}} indicates that the value of the analysisResult field in the task execution chain data should be filled in that position. The data from the execution result is then filled into the variable placeholders in the template string to generate markup language text. The filling process is as follows: All variable placeholders in the template string are parsed, and the path expression of each placeholder (i.e., the content between the double curly braces) is identified; for each variable placeholder, the corresponding value is extracted from the rendering context containing the execution results and task execution chain data according to its path expression; the extracted value is then replaced in the position of the variable placeholder (replacing the variable placeholder with the actual value); if the value corresponding to the path expression does not exist, the variable placeholder is replaced with an empty string. After the replacement is complete, a complete markup language text string is generated.

[0060] JSON format is used to output the execution result directly as JSON text; this format does not perform any additional formatting. The execution result will be a Java object (Map).<String, Object> After being serialized into a JSON string using a JSON serialization library (such as Jackson or Gson), it can be output directly. JSON format is suitable for scenarios where the original data structure needs to be preserved for subsequent programmatic processing.

[0061] Based on the above, this embodiment extracts format type identifiers and format configuration data from the output formatting rules, and selects the corresponding formatting branch for rendering based on the format type identifier. This allows the tool's output display method to be flexibly adjusted through database configuration, thus enabling switching of output formats without modifying the code. Through data source path extraction, column mapping, and table builder calls for table formats, flexible customization of complex tables is achieved. Automatic generation of report-type text is achieved through template string variable placeholder replacement in markup language format.

[0062] After detecting a change in the tool configuration record in the database and generating an updated tool callback instance, it is necessary to remove the registration corresponding to the old tool callback instance generated based on the previous tool configuration record from the MCP server. Traditionally, this removal operation typically involves iterating through all registered tools and attempting to remove them one by one, which is inefficient and prone to errors. Therefore, in one embodiment, removing the registration corresponding to the old tool callback instance generated based on the previous tool configuration record from the MCP server includes: Get the set of tool names previously registered to the MCP server and define it as the previous tool name set; get the set of tool names corresponding to the updated tool callback instance to be registered and define it as the current tool name set; The difference between the previous set of tool names and the current set of tool names is used as the set of tool names to be removed; For each tool name in the set of tool names to be removed, the corresponding registration is removed through the tool removal interface of the MCP server.

[0063] Specifically, after each successful tool registration, the system saves all registered tool names as a list. This list is stored in the memory variable `lastRegisteredDynamicToolNames`, which is of type `List`. <string>This list serves as the baseline for the next reload. When a configuration change is detected and a hot reload is triggered, the list of registered tool names is first retrieved from the `lastRegisteredDynamicToolNames` variable. All elements in this list are added to a `HashSet` collection, defined as the `previousToolNames` collection. Each element in the `previousToolNames` collection is a String type tool name, representing the name of all tools that were successfully registered to the MCP server in the last instance. On initial startup, if `lastRegisteredDynamicToolNames` is empty, the `previousToolNames` collection is empty.

[0064] After generating updated tool callback instances based on the modified tool configuration records, all updated tool callback instances are iterated through. The corresponding tool name (i.e., the value of the `method_name` field in the tool configuration record) is extracted from each callback instance. All extracted tool names are added to a HashSet collection, defined as the current tool name collection (`currentToolNames`). Each element in the current tool name collection is a String type tool name, representing the name of all tools to be registered this time.

[0065] The difference operation is defined as follows: for sets A and B, the difference between A and B (denoted as A \ B) is the set of all elements that belong to A but not to B. Specifically, for each tool name in the previous tool name set (previousToolNames), check if that tool name also exists in the current tool name set (currentToolNames). If it exists, it means the tool still exists in this update (the tool name has not changed) and does not need to be removed. If it does not exist, it means the tool has been deleted or its name has changed in this update, and its registration needs to be removed from the MCP server. The set of all tool names that need to be removed is defined as the tool name set to be removed (toRemoveToolNames). This difference operation can be implemented using Java's CollectionUtils or Set's removeAll method, i.e., 'Set...'. <string>toRemoveToolNames = new HashSet<>(previousToolNames);toRemoveToolNames.removeAll(currentToolNames);'.

[0066] The MCP server (McpSyncServer) provides a tool removal interface, the `removeTool(String toolName)` method. This method accepts a tool name as a parameter and removes the corresponding registration from the MCP server. It iterates through the set of tool names to be removed (toRemoveToolNames), and for each tool name in the set, calls the `removeTool(toolName)` method of `McpSyncServer`, passing the tool name as the parameter. After the removal operation is complete, the MCP server no longer provides clients with the ability to discover and invoke that tool. If a tool name does not exist in the MCP server during the removal process, a warning is logged but the process is not interrupted.

[0067] Based on the above, this embodiment obtains the previous tool name set registered to the MCP server and the current tool name set to be registered, and uses the difference between the previous tool name set and the current tool name set as the tool name set to be removed. This achieves the precise location of the tool to be removed through set difference operation, thereby avoiding the inefficient method of traversing all registered tools and trying to remove them one by one, and also avoiding misoperation of static tools.

[0068] After removing the old tool registration from the MCP server, the updated tool callback instance needs to be registered with the MCP server. Traditionally, adding tools typically involves a full re-registration, re-registering all tools, which is inefficient. Therefore, in one embodiment, registering the updated tool callback instance with the MCP server includes: Use the difference between the current set of tool names and the previous set of tool names as the set of tool names to be added; The updated tool callback instances corresponding to the set of tool names to be added are converted into synchronous tool specification objects of the MCP server. The synchronous tool specification objects correspond to the tool definition objects and are used to provide the MCP server with the specification information required for tool registration. For each synchronization tool specification object, registration is completed through the add tool interface of the MCP server.

[0069] Specifically, the difference operation is defined as follows: for sets B and A, the difference between B and A (denoted as B \ A) is the set of all elements that belong to B but not to A. Specifically, for each tool name in the current tool name set (currentToolNames), check if the tool name also exists in the previous tool name set (previousToolNames). If it exists, it means the tool was registered before this update and the tool name has not changed, so it does not need to be re-registered. If it does not exist, it means the tool is a newly added tool or the tool name has changed (equivalent to an old tool being removed and added with a new name), and it needs to be registered with the MCP server. The set of all tool names to be added is defined as the set of tool names to be added (toAddToolNames). This difference operation can be implemented using Java's CollectionUtils or Set's removeAll method, i.e., 'Set...'. <string>toAddToolNames = new HashSet<>(currentToolNames); toAddToolNames.removeAll(previousToolNames);'.

[0070] The SyncToolSpecification object is an object used by the MCP protocol layer to describe tool specifications, corresponding to the ToolDefinition object. The SyncToolSpecification object contains the tool's name, description, and input parameter schema, providing the MCP server with the complete specification information required for tool registration. For each tool name in the set of tool names to be added (toAddToolNames), the callback instance corresponding to that tool name (i.e., the tool name of the callback instance is the same as the tool name to be added) is found from the updated list of tool callback instances. This callback instance is then converted into a SyncToolSpecification object. The conversion process is as follows: the tool definition object is obtained by calling the getToolDefinition() method of the tool callback instance; the JSON schema definition of the tool name, description information, and input parameters is extracted from the tool definition object; and this information is encapsulated into a SyncToolSpecification object. In practical applications, the toSyncToolSpecification method of the McpToolUtils utility class provided by the Spring AI framework is used to complete the conversion from the tool callback instance to the SyncToolSpecification object. This method accepts a ToolCallback object as input and returns the corresponding SyncToolSpecification object.

[0071] The MCP server (McpSyncServer) provides the `addTool(SyncToolSpecification toolSpec)` method, which accepts a `SyncToolSpecification` object as a parameter and registers the corresponding tool with the MCP server. It iterates through all synchronization tool specification objects (i.e., the list of `SyncToolSpecifications` corresponding to `toAddToolNames`), and for each synchronization tool specification object, calls the `addTool(toolSpec)` method of `McpSyncServer`, passing the synchronization tool specification object as a parameter. After registration, the MCP server can provide the ability to discover and invoke the tool to connected MCP clients. If an exception occurs during registration (such as a duplicate tool name conflict), a retry strategy is implemented: first remove the tool, then retry adding it; that is, call `removeTool(toolName)` followed by `addTool(toolSpec)`.

[0072] Based on the above, this embodiment uses the difference between the current tool name set and the previous tool name set as the set of tool names to be added, achieving precise location of the tools to be added through set difference operations, thus avoiding the overhead of full re-registration. By converting the callback instances corresponding to the set of tool names to be added in the updated tool callback instances into synchronous tool specification objects of the MCP server, a mapping from the internal callback model to the MCP protocol layer specification model is achieved, thereby ensuring the integrity and correctness of tool registration information.

[0073] Different processing strategies are needed for tool registration and synchronization during the application startup and runtime phases. In the Spring AI framework, tools are automatically scanned and registered via ToolCallbackProvider during application startup. Performing incremental synchronization during startup might interfere with the framework's automatic registration process, leading to registration status confusion. Therefore, in one embodiment, tool configuration records are read from the database, and the operation of registering tool callback instances to the MCP server is executed separately during the application startup and runtime phases. Specifically, during application startup, initial registration is performed based on tool configuration records in the database with an enabled status, and incremental synchronization during the runtime phase is disabled after initial registration. After the application enters the ready state, incremental synchronization during the runtime phase is enabled, and a check for changes to tool configuration records in the database is performed to synchronize configuration changes occurring after the application startup phase to the MCP server.

[0074] Specifically, the application lifecycle includes a startup phase and a runtime phase. The startup phase is the period from when the application begins to when it is fully ready; in the Spring framework, this corresponds to the period from container initialization to the triggering of the ApplicationReadyEvent. The runtime phase is the period after the application is fully ready, corresponding to the period after the ApplicationReadyEvent is triggered. Tool registration is performed in these two phases, but using different strategies.

[0075] The enabled status is indicated by the `is_enabled` field in the tool configuration record; an enabled value of 1 indicates this field is enabled. During application startup, the process reads tool configuration records from the database, constructs tool definition objects and tool callback instances, and registers them with the MCP server. Specifically, the SQL query "SELECT * FROM mcp_methodsWHERE is_enabled = 1" retrieves all tool configuration records with an enabled status from the database. Based on the retrieved tool configuration records, tool callback instances and tool definition objects are generated and registered with the MCP server using the `addTool` method of `McpSyncServer`. After initial registration, the MCP server contains all enabled tools. Incremental synchronization during runtime is disabled after initial registration. This is achieved by setting a boolean flag variable named `runtimeSyncEnabled` in memory with a value of `false`. Disabling incremental synchronization means that even if changes to the tool configuration records in the database are detected during application startup, no hot reload operations (including removal and addition operations) of runtime tools will be performed. This is to avoid conflicts between the initial registration during startup and the incremental synchronization operations during runtime.

[0076] Once the application enters the ready state, incremental synchronization during the runtime phase is enabled. The application entering the ready state means that the application has completed all startup initialization work and can handle external requests normally. In the Spring framework, this is achieved by implementing ApplicationListener. <applicationreadyevent>The interface or the `@EventListener` annotation can be used to listen for the `ApplicationReadyEvent` event, which is triggered when the application is fully ready. Upon receiving the `ApplicationReadyEvent`, the `runtimeSyncEnabled` flag variable in memory is set to `true` to enable runtime incremental synchronization. Enabling incremental synchronization allows hot reloading of runtime tools (including removing old tool registrations from the MCP server, registering updated tool callback instances with the MCP server, and issuing tool list change notifications). After enabling runtime incremental synchronization, a check for changes to tool configuration records in the database is performed. The purpose of this check is to detect configuration changes that may occur after the application startup phase (i.e., between initial registration and application readiness). If tool configuration records in the database have changed during this period (e.g., operations personnel modify the configuration during application startup), these changes need to be synchronized to the MCP server. Upon detecting a change, the synchronization operation is performed according to the aforementioned incremental synchronization process, including generating an updated tool callback instance based on the changed tool configuration record, removing the old tool registration from the MCP server, registering the updated tool callback instance to the MCP server, and issuing a tool list change notification through the notification mechanism of the MCP protocol.

[0077] Based on the above, this embodiment isolates the initial registration during the startup phase from the incremental synchronization operation during the runtime phase. After the initial registration is completed, the incremental synchronization operation during the runtime phase is disabled, thus avoiding conflicts between the automatic registration logic of the startup phase framework and the manual incremental synchronization logic during the runtime phase, thereby ensuring the stability of the startup phase registration process. By enabling the incremental synchronization operation during the runtime phase and performing a change detection after the application enters the ready state, configuration changes occurring after the startup phase can be promptly synchronized to the MCP server, ensuring that the application has the latest tool configuration immediately after startup.

[0078] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0079] Secondly, based on the same inventive concept, this application also provides a system for implementing the aforementioned database-driven MCP tool dynamic generation and runtime synchronization method. The solution provided by this system is similar to the implementation described in the above method; therefore, the specific limitations in one or more system embodiments provided below can be found in the above-described limitations of the database-driven MCP tool dynamic generation and runtime synchronization method, and will not be repeated here.

[0080] In one embodiment, such as Figure 4 As shown, the system includes: a configuration reading module, a tool definition construction module, a callback generation module, a tool execution module, a registration module, and a synchronization management module. Among them: The configuration reading module is used to read tool configuration records from the database. The tool configuration records include the tool name, input parameter mode, and output formatting rules. The tool definition constructor module is used to construct tool definition objects based on input parameter patterns. The callback generation module is used to generate tool callback instances based on tool configuration records; The tool execution module is used to respond to the invocation of the tool callback instance, validate and convert the input parameters to generate parameter data, call external services based on the parameter data and obtain the execution result, and format and render the execution result according to the output formatting rules to generate a formatted result; The registration module is used to register tool callback instances and tool definition objects with the MCP server. The MCP server is a server-side component that provides tool invocation services to the outside world based on the model context protocol. The synchronization management module is used to respond to the detection of changes in tool configuration records in the database, generate updated tool callback instances based on the changed tool configuration records, remove the registration corresponding to the old tool callback instances generated based on the previous tool configuration records from the MCP server, register the updated tool callback instances to the MCP server, and send tool list change notifications through the notification mechanism of the MCP protocol.

[0081] In the above system, the data flow between modules is as follows: After the configuration reading module reads the tool configuration records from the database, it transmits the tool configuration records to the tool definition construction module and the callback generation module respectively; the tool definition construction module constructs a tool definition object based on the received tool configuration records and transmits the tool definition object to the registration module; the callback generation module generates a tool callback instance based on the received tool configuration records and transmits the tool callback instance to the tool execution module and the registration module respectively; the registration module registers the received tool definition object and tool callback instance to the MCP server; when the synchronization management module detects a configuration change, it triggers the callback generation module to generate an updated tool callback instance and controls the registration module to perform removal and addition operations.

[0082] In one embodiment, the tool configuration record further includes a plugin mapping identifier. The tool execution module includes a result acquisition unit. This result acquisition unit is used to determine the target external service plugin based on the plugin mapping identifier. The result acquisition unit is also used to acquire the access token of the external service platform to which the target external service plugin belongs. The result acquisition unit is used to construct a request message including the plugin mapping identifier and parameter data based on parameter data. The result acquisition unit is used to send the request message to the external service platform. The result acquisition unit is also used to receive the execution result returned by the external service platform and extract the current task identifier and the next task identifier from the execution result to construct task execution chain data. This task execution chain data is used to record the task flow path of this tool call.

[0083] In one embodiment, the tool execution module includes a parameter processing unit. This parameter processing unit performs type validation, numerical range validation, string length validation, required field validation, and enumeration value validation on the input parameters; fills in missing parameters according to the default values ​​in the input parameter pattern; and converts the input parameters into the target data type declared in the input parameter pattern.

[0084] In one embodiment, the tool execution module includes a formatting processing unit. This unit extracts a format type identifier and formatting configuration data from the output formatting rules. In response to the format type identifier being a table format, the unit extracts the data source path, column definition set, and table style identifier from the formatting configuration data. It then extracts two-dimensional data from the execution result based on the data source path, performs column mapping on the two-dimensional data based on the column definition set, and calls the corresponding table builder to generate table text based on the table style identifier. The table builder is a pre-configured formatting component for generating table-formatted text. In response to the format type identifier being a markup language format, the unit extracts a template string from the formatting configuration data and fills the variable placeholders in the template string with data from the execution result to generate markup language text. In response to the format type identifier being JSON format, the unit outputs the execution result as JSON text.

[0085] In one embodiment, the synchronization management module includes a registration and removal unit. This unit retrieves the set of tool names previously registered with the MCP server and defines it as the previous tool name set; it also retrieves the set of tool names corresponding to the updated tool callback instances to be registered and defines it as the current tool name set. The registration and removal unit uses the difference between the previous and current tool name sets as the set of tool names to be removed. For each tool name in the set of tool names to be removed, the registration and removal unit removes the corresponding registration through the MCP server's tool removal interface.

[0086] In one embodiment, the synchronization management module includes an update registration unit. The update registration unit is used to take the difference between the current tool name set and the previous tool name set as the set of tool names to be added. The update registration unit is used to convert the callback instances corresponding to the set of tool names to be added in the updated tool callback instances into synchronization tool specification objects of the MCP server. These synchronization tool specification objects correspond to tool definition objects and are used to provide the MCP server with the specification information required for tool registration. The update registration unit is used to complete the registration for each synchronization tool specification object through the MCP server's add tool interface.

[0087] In one embodiment, the system further includes a runtime control module. The runtime control module controls the execution of operations during the application startup phase and the runtime phase, respectively, to read tool configuration records from the database and register tool callback instances with the MCP server. Specifically, during the application startup phase, initial registration is performed based on tool configuration records in the database with an enabled status, and incremental synchronization operations during the runtime phase are disabled after initial registration. After the application enters the ready state, incremental synchronization operations during the runtime phase are enabled, and a check for changes to tool configuration records in the database is performed to synchronize configuration changes occurring after the application startup phase to the MCP server.

[0088] The modules in the database-driven MCP tool's dynamic generation and runtime synchronization system described above can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the computer device's memory as software, so that the processor can call and execute the corresponding operations of each module.

[0089] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements a database-driven MCP tool dynamic generation and runtime synchronization method. The display screen can be an LCD screen or an e-ink display. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device casing, or an external keyboard, touchpad, or mouse.

[0090] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0091] Thirdly, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described in the above method embodiments.

[0092] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of any of the methods described in the above method embodiments.

[0093] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0094] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0095] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.< / applicationreadyevent> < / string> < / string> < / string> < / columndefinition>

Claims

1. A method for dynamically generating and synchronizing MCP tools based on database drivers, characterized in that, The method includes: S1: Read the tool configuration record from the database. The tool configuration record includes the tool name, input parameter mode, and output formatting rules. S2: Construct a tool definition object based on the input parameter pattern; S3: Generate a tool callback instance based on the tool configuration record; S4: In response to the invocation of the tool callback instance, validate and convert the input parameters to generate parameter data, call the external service based on the parameter data and obtain the execution result, and format and render the execution result according to the output formatting rules to generate a formatted result; S5: Register the tool callback instance and the tool definition object to the MCP server, where the MCP server is a server-side component that provides tool invocation services to the outside world based on the model context protocol; S6: In response to detecting a change in the tool configuration record in the database, an updated tool callback instance is generated based on the changed tool configuration record. The registration corresponding to the old tool callback instance generated based on the previous tool configuration record is removed from the MCP server. The updated tool callback instance is registered to the MCP server. A tool list change notification is sent through the notification mechanism of the MCP protocol.

2. The method according to claim 1, characterized in that, The tool configuration record also includes a plugin mapping identifier; the step of calling an external service and obtaining the execution result based on the parameter data includes: The target external service plugin is determined based on the plugin mapping identifier; Obtain the access token of the external service platform to which the target external service plugin belongs; Construct a request message including the plug-in mapping identifier and the parameter data based on the parameter data; The request message is sent to the external service platform; The system receives the execution result returned by the external service platform and extracts the current task identifier and the next task identifier from the execution result to construct task execution chain data. The task execution chain data is used to record the task flow path of this tool call.

3. The method according to claim 1, characterized in that, The process of validating and converting the input parameters includes: The input parameters are validated for type, numerical range, string length, required fields, and enumeration values. Missing parameters are filled with default values ​​in the input parameter pattern. The input parameters are also converted to the target data type declared in the input parameter pattern.

4. The method according to claim 1, characterized in that, The step of formatting and rendering the execution result according to the output formatting rules includes: Extract the format type identifier and format configuration data from the output formatting rules; In response to the format type identifier being a table format, the data source path, column definition set, and table style identifier are extracted from the format configuration data. Two-dimensional data is extracted from the execution result according to the data source path. The two-dimensional data is column-mapped according to the column definition set. The corresponding table builder is called according to the table style identifier to generate table text. The table builder is a pre-configured formatting component for generating table format text. In response to the format type being identified as a markup language format, a template string is extracted from the format configuration data, and the data from the execution result is filled into the variable placeholders in the template string to generate markup language text. In response to the format type being identified as JSON, the execution result is output as JSON text.

5. The method according to claim 1, characterized in that, The step of removing the registration corresponding to the old tool callback instance generated based on the tool configuration record before the change from the MCP server includes: Get the set of tool names previously registered to the MCP server and define it as the previous tool name set; get the set of tool names corresponding to the updated tool callback instance to be registered and define it as the current tool name set; The difference between the previous set of tool names and the current set of tool names is taken as the set of tool names to be removed; For each tool name in the set of tool names to be removed, the corresponding registration is removed through the tool removal interface of the MCP server.

6. The method according to claim 5, characterized in that, Registering the updated tool callback instance to the MCP server includes: The difference between the current set of tool names and the previous set of tool names is used as the set of tool names to be added; The callback instances in the updated tool callback instances that correspond to the set of tool names to be added are converted into synchronous tool specification objects of the MCP server. The synchronous tool specification objects correspond to the tool definition objects and are used to provide the MCP server with the specification information required for tool registration. For each synchronization tool specification object, registration is completed through the add tool interface of the MCP server.

7. The method according to claim 1, characterized in that, The operation of reading tool configuration records from the database and registering the tool callback instance to the MCP server is performed during the application startup phase and the runtime phase, respectively. During the application startup phase, initial registration is performed based on the tool configuration records in the database with an enabled status, and incremental synchronization during the runtime phase is disabled after the initial registration is completed. After the application enters the ready state, incremental synchronization during the runtime phase is enabled, and a check for changes to the tool configuration records in the database is performed to synchronize configuration changes that occurred after the application startup phase to the MCP server.

8. A database-driven MCP tool dynamic generation and runtime synchronization system, characterized in that, The system includes: A configuration reading module is used to read tool configuration records from the database. The tool configuration records include the tool name, input parameter mode, and output formatting rules. A tool definition construction module is used to construct a tool definition object based on the input parameter pattern; The callback generation module is used to generate tool callback instances based on the tool configuration record. The tool execution module is used to respond to the invocation of the tool callback instance, validate and convert the input parameters to generate parameter data, call external services based on the parameter data and obtain the execution result, and format and render the execution result according to the output formatting rules to generate a formatted result; The registration module is used to register the tool callback instance and the tool definition object to the MCP server, where the MCP server is a server-side component that provides tool invocation services to the outside world based on the model context protocol. The synchronization management module is used to respond to the detection of a change in the tool configuration record in the database, generate an updated tool callback instance based on the changed tool configuration record, remove the registration corresponding to the old tool callback instance generated based on the previous tool configuration record from the MCP server, register the updated tool callback instance to the MCP server, and issue a tool list change notification through the notification mechanism of the MCP protocol.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the database-driven MCP tool dynamic generation and runtime synchronization method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the database-driven MCP tool dynamic generation and runtime synchronization method as described in any one of claims 1 to 7.

Images