MCP tool calling method and device, equipment and storage medium

Abstract

The invention discloses an MCP tool calling method and device, equipment and a storage medium, and relates to the technical field of large models.The method comprises the steps that when a tool calling request is received, state evaluation parameters corresponding to a target MCP tool are determined based on a tool state monitoring pool; historical detection records and corresponding historical detection timestamps of the MCP tools are stored in the tool state monitoring pool; and generating a calling decision of the target MCP tool according to the state evaluation parameters. The historical data of each MCP tool is stored through the maintenance tool state monitoring pool in advance, state evaluation before calling is achieved, millisecond decision making of target MCP tool calling is achieved according to the state evaluation parameters, a traditional direct calling mode is replaced, the tool calling success rate is guaranteed by dynamically judging the tool availability, and the tool calling efficiency is improved. And resource waste caused by blind calling of the model is avoided.

Description

Technical Field

[0001] This application relates to the field of large model technology, and in particular to an MCP tool invocation method, apparatus, device and storage medium. Background Technology

[0002] With the development of artificial intelligence technology, Large Language Models (LLMs) have demonstrated powerful capabilities in natural language understanding and reasoning generation. To enhance the interaction between models and their external environments, following Retrieval Augmented Generation (RAG) and Function Calling, Model Context Protocol (MCP) has emerged as a standardized protocol and is widely used to connect models with external tools (such as database queries, file operations, and browser operations), thereby extending the capabilities of the models.

[0003] In practical applications, MCP tools often rely on network requests, remote services, or local resources, and their stability directly affects the reliability of the entire model invocation process. If the MCP tool is temporarily unavailable, it will cause the invocation to fail, which in turn will lead to model context interruption, generation of error responses, or task termination, resulting in wasted model resources and seriously affecting the user experience. Summary of the Invention

[0004] The main purpose of this application is to provide a method, apparatus, device and storage medium for calling the MCP tool, aiming to solve the technical problem of how to ensure the success rate of MCP tool calls and avoid resource waste caused by blind model calls.

[0005] To achieve the above objectives, this application proposes an MCP tool invocation method, which includes:

[0006] When a tool invocation request is received, the status evaluation parameters corresponding to the target MCP tool are determined based on the tool status monitoring pool; the tool status monitoring pool stores the historical detection records and corresponding historical detection timestamps of each MCP tool.

[0007] The invocation decision for the target MCP tool is generated based on the state assessment parameters.

[0008] In one embodiment, the step of determining the state assessment parameters corresponding to the target MCP tool based on the tool state monitoring pool includes:

[0009] Based on the tool identifier of the target MCP tool, the target detection timestamp, target detection result, and target detection delay time are obtained from the tool status monitoring pool.

[0010] The state assessment parameters corresponding to the target MCP tool are determined based on the target detection timestamp, target detection result, and target detection delay time.

[0011] In one embodiment, the step of determining the state assessment parameters corresponding to the target MCP tool based on the target detection timestamp, the target detection result, and the target detection delay time includes:

[0012] The state credibility of the target MCP tool is determined based on the target detection timestamp.

[0013] The historical detection success rate of the target MCP tool is determined based on the target detection results.

[0014] Determine the detection delay penalty item corresponding to the target MCP tool based on the target detection delay time;

[0015] The state evaluation parameters corresponding to the target MCP tool are obtained by weighting the state credibility, the historical detection success rate, and the detection delay penalty term.

[0016] In one embodiment, the step of generating the invocation decision for the target MCP tool based on the state evaluation parameters includes:

[0017] When the state evaluation parameter is not greater than the first confidence threshold, the fault isolation mechanism is triggered;

[0018] When the state evaluation parameter is greater than the first confidence threshold and less than the second confidence threshold, an instant detection is triggered, and the target MCP tool is invoked when the instant detection result passes.

[0019] When the state evaluation parameter is not less than the second confidence threshold, the target MCP tool is invoked.

[0020] In one embodiment, the step of triggering the fault isolation mechanism when the state evaluation parameter is not greater than a first confidence threshold includes:

[0021] The target MCP tool is marked as isolated, and the isolation window duration is set, which is determined based on the historical fault recovery time of the target MCP tool.

[0022] During the isolation window period, the call request of the target MCP tool is rejected.

[0023] In one embodiment, after generating the invocation decision for the target MCP tool based on the state evaluation parameters, the method further includes:

[0024] The target MCP tool is subjected to health status detection based on the stated status assessment parameters;

[0025] The tool status monitoring pool is updated based on the health status detection results.

[0026] In one embodiment, the step of performing health status detection on the target MCP tool based on the status assessment parameters includes:

[0027] The current detection window of the target MCP tool is determined based on the state assessment parameters;

[0028] The target detection time is determined based on the current detection window and the state confidence level.

[0029] The target MCP tool performs a health status detection based on the target detection time.

[0030] Furthermore, to achieve the above objectives, this application also proposes an MCP tool invocation device, which includes:

[0031] When the detection module receives a tool invocation request, it determines the status evaluation parameters corresponding to the target MCP tool based on the tool status monitoring pool; the tool status monitoring pool stores the historical detection records and corresponding historical detection timestamps of each MCP tool.

[0032] The calling module is used to generate a calling decision for the target MCP tool based on the state evaluation parameters.

[0033] In addition, to achieve the above objectives, this application also proposes an MCP tool invocation device, the device comprising: a memory, a processor, and an MCP tool invocation program stored in the memory and executable on the processor, the MCP tool invocation program being configured to implement the steps of the MCP tool invocation method as described above.

[0034] Furthermore, to achieve the above objectives, this application also proposes a storage medium storing an MCP tool invocation program. When executed by a processor, the MCP tool invocation program implements the steps of the MCP tool invocation method described above. This application provides an MCP tool invocation method, apparatus, device, and storage medium.

[0035] This application discloses a method, apparatus, device, and storage medium for invoking an MCP tool. The method includes: upon receiving a tool invocation request, determining the status assessment parameters corresponding to the target MCP tool based on a tool status monitoring pool; the tool status monitoring pool stores historical detection records and corresponding historical detection timestamps for each MCP tool; and generating an invocation decision for the target MCP tool based on the status assessment parameters. This application pre-maintains the historical data of each MCP tool stored in the tool status monitoring pool to achieve pre-invocation status assessment, and makes millisecond-level decisions on invoking the target MCP tool based on the status assessment parameters. This replaces the traditional "direct invocation" mode, dynamically judges tool availability to ensure the success rate of tool invocation, and avoids resource waste caused by blind invocation. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0037] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a first flowchart illustrating the first embodiment of the MCP tool invocation method of this application;

[0039] Figure 2 This is a second flowchart illustrating the first embodiment of the MCP tool invocation method of this application;

[0040] Figure 3 This is a schematic diagram of the first process of the second embodiment of the MCP tool invocation method of this application;

[0041] Figure 4 This is a second flowchart illustrating the second embodiment of the MCP tool invocation method of this application;

[0042] Figure 5 This is a simplified flowchart illustrating the MCP tool invocation method of this application;

[0043] Figure 6 This is a schematic diagram of the module structure of the MCP tool calling device according to an embodiment of this application;

[0044] Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the MCP tool invocation method in this application embodiment.

[0045] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0046] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0047] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0048] The main solution of this application is: when a tool invocation request is received, the status assessment parameters corresponding to the target MCP tool are determined based on the tool status monitoring pool; the tool status monitoring pool stores the historical detection records of each MCP tool and the corresponding historical detection timestamps; and the invocation decision of the target MCP tool is generated based on the status assessment parameters.

[0049] Currently, MCP clients typically call registered tool interfaces directly without performing health checks on the MCP tools before the actual call. If the tool service is temporarily unavailable (e.g., due to network interruption or service crash), the call will fail. Before calling the MCP tool, the model may have already allocated or executed significant computational resources while waiting for the MCP tool's response. After the tool call fails, the model may still need to process subsequent logic. Due to the lack of a response from the MCP tool, the illusion problem in the subsequent model's returned results is severe, all of which cause unnecessary resource waste. Therefore, MCP call failures can lead to model context interruption, generation of error responses, or task termination, resulting in wasted model resources and severely impacting the user experience.

[0050] The existing MCP calling process lacks real-time monitoring of tool availability. To address this issue, this application proposes a state management mechanism based on a probe cache pool. Specifically, this application pre-stores historical data of each MCP tool in a tool status monitoring pool to achieve state assessment before calling. Based on the state assessment parameters, it makes millisecond-level decisions on calling the target MCP tool, replacing the traditional "direct calling" mode. By dynamically judging tool availability, it ensures the success rate of tool calls and avoids resource waste caused by blind calling.

[0051] It should be noted that the execution entity in this embodiment can be an MCP tool invocation system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an MCP tool invocation device capable of performing the above functions. This embodiment does not specifically limit this. For example, a built-in invocation controller module in an MCP client; an independent service gateway component that centrally manages the status of multiple MCP tools; an integrated module of an LLM inference engine, etc. The following uses an MCP tool invocation device (hereinafter referred to as the invocation device) as the execution entity to describe this embodiment and the following embodiments.

[0052] Based on this, the embodiments of this application provide a method for calling the MCP tool, referring to... Figure 1 , Figure 1 This is a first flowchart illustrating the first embodiment of the MCP tool invocation method of this application.

[0053] In this embodiment, the MCP tool invocation method includes steps S10 to S20:

[0054] Step S10: When a tool call request is received, the status evaluation parameters corresponding to the target MCP tool are determined based on the tool status monitoring pool; the tool status monitoring pool stores the historical detection records and corresponding historical detection timestamps of each MCP tool.

[0055] It is easy to understand that the aforementioned MCP tools can be external tools implemented based on the Model Context Protocol (MTP), used to extend the capabilities of Large Language Models (LLMs), such as database queries, file operations, and browser interaction. They serve as interfaces for interaction between the model and the external environment. The tool invocation requests can be instructions initiated by the LLM inference engine or MCP client to call the target MCP tool, which may include the globally unique identifier of the target MCP tool and information such as the parameters required for the call.

[0056] It is important to understand that this embodiment decouples the "probing" and "invocation" behaviors. Instead of relying on conventional periodic probing, it establishes a cache pool to store historical operational data for each MCP tool—the aforementioned tool status monitoring pool—to record tool status. This allows the invoking device to quickly make tool invocation decisions based on the status in the tool status monitoring pool before actually invoking the MCP tool. This tool status monitoring pool contains historical probing records for each MCP tool (e.g., availability, response results) and corresponding historical probing timestamps (recording the time the probing occurred). The invoking device can then evaluate the current status of the target MCP tool based on the tool status monitoring pool, obtaining quantitative indicators reflecting the target MCP tool's current availability (e.g., stability, response speed), i.e., the aforementioned status evaluation parameters, and determine the reliability of invoking the target MCP tool based on these parameters.

[0057] Therefore, the calling device can extract a predetermined number of historical probe records (such as the success / failure results of the past 10 probes) and corresponding timestamps from the tool status monitoring pool based on the identifier of the target MCP tool. Then, the calling device can convert the acquired data into status evaluation parameters through a preset algorithm (such as weighted calculation) to quantify the current usability status of the target MCP tool.

[0058] In one feasible implementation, in this embodiment, step S10 includes steps S11 to S12:

[0059] Step S11: Obtain the target detection timestamp, target detection result, and target detection delay time from the tool status monitoring pool based on the tool identifier of the target MCP tool;

[0060] Step S12: Determine the state evaluation parameters corresponding to the target MCP tool based on the target detection timestamp, target detection result, and target detection delay time.

[0061] Understandably, the aforementioned tool identifier can be a unique code (such as an ID, name, or hash value) used to identify the MCP tool, ensuring accurate matching of the target MCP tool's historical data from the tool status monitoring pool. The calling device can use the target MCP tool's tool identifier to perform precise matching within the tool status monitoring pool, extracting the corresponding target detection timestamp, target detection results, and target detection delay time (such as detailed data from the last 5 detections).

[0062] It is easy to understand that the aforementioned target detection results can be the operational status of the target MCP tool recorded in historical detections (such as "successful response," "timeout," or "error return"), reflecting the past availability of the target MCP tool; the aforementioned target detection timestamps can be the specific time corresponding to the target detection results recorded in the tool status monitoring pool (such as "year-month-day, hour: minute: second"), used to determine the timeliness of historical data; and the target detection latency can be the time taken by the target MCP tool from receiving the request to returning the result recorded in historical detection records (such as 500ms), measuring the response speed of the target MCP tool. After acquiring the data, the calling device can combine the timestamp to determine the data freshness (the more recent the data, the higher the weight), combine the detection results to calculate the success rate, and combine the latency to evaluate the response efficiency, performing multi-dimensional historical data extraction and fusion to obtain comprehensive and integrated status evaluation parameters.

[0063] Therefore, in this embodiment, the probe cache pool can be defined as an ordered queue H, where each element contains a probe timestamp t. i The default value is 0; the detection result s i ∈(0,1), where 1 represents success and 0 represents failure (default value); probe delay d i The default value is 0.

[0064] At this point, the probe cache pool H can be represented as follows:

[0065] H=[(t1,s1,d1),(t2,s2,d2),…,(t n s n d n (1)

[0066] If it has not been detected, initialize H to the default value.

[0067] Furthermore, in one feasible implementation, refer to Figure 2 , Figure 2 This is a second flowchart illustrating the first embodiment of the MCP tool invocation method of this application. In this embodiment, step S11 includes steps A1 to A4:

[0068] Step A1: Determine the state credibility of the target MCP tool based on the target detection timestamp;

[0069] It should be noted that the above-mentioned state credibility can be an indicator calculated based on the target detection timestamp, reflecting the reliability of historical data (e.g., the credibility of detection data within 1 hour is 0.9, and that of data older than 24 hours is 0.3), with higher credibility the more recent the time.

[0070] At this point, the calling device can extract the timestamps t of the most recent n probes from the current tool probe cache pool H. last A weighted calculation is performed to calculate the state confidence level C(t):

[0071]

[0072] Where, by default, C(t) = 0.2; n is the total number of recent probe records in the cache pool (including successful and failed probes), which defaults to 5; λ is the decay coefficient (ranging from 0.01 to 0.05); t i w is the timestamp of the successful i-th probe. i The weight for the i-th probe decreases in reverse chronological order.

[0073] For example, if only the last successful probe is counted, then w is calculated if the last probe occurred 3 minutes ago. i =1,tt i =180, substituting into the equation, we get C(t)≈0.17, indicating that the reliability of the state is low.

[0074] Step A2: Determine the historical detection success rate of the target MCP tool based on the target detection results;

[0075] Understandably, the historical detection success rate can be the proportion of times the target MCP tool "successfully responded" in the target detection results to the total number of detections (e.g., 8 out of 10 detections were successful, with a success rate of 80%), which directly reflects the stability of the tool.

[0076] At this point, the calling device can extract the results of the most recent N probes from the current tool probe cache pool H and calculate the historical success rate R(t), as shown below:

[0077] R(t) = Number of successful probes / Total number of probes; (3)

[0078] Example: If 4 out of the last 5 probes are successful, then R(t) = 0.8; if the number of probes is insufficient, pad with zeros or use the default probe success rate.

[0079] Step A3: Determine the detection delay penalty term corresponding to the target MCP tool based on the target detection delay time;

[0080] Understandably, the detection delay penalty can be a negative indicator set based on the target detection delay time (e.g., the penalty is 0.2 when the delay exceeds 1 second, and the smaller the delay, the closer the penalty is to 0), used to weaken the evaluation parameters of tools with slow response.

[0081] At this point, the calling device can retrieve the timestamp t of the last successful probe from the current tool probe cache pool H. lastThe term L(t) is used to calculate the detection delay penalty. The formula for calculating L(t) is as follows:

[0082]

[0083] For example, the above time intervals can be T1 = 60s, T2 = 180s, T3 = 300s, or can be adjusted according to the actual business scenario.

[0084] Step A4: The state evaluation parameters corresponding to the target MCP tool are obtained by weighting the state credibility, the historical detection success rate and the detection delay penalty term.

[0085] It is easy to understand that by calling the device, the state reliability, historical detection success rate, and detection latency penalty can be normalized to the [0, 1] interval according to their respective preset weights, thus obtaining a quantitative indicator for evaluating the usability of the target MCP tool, namely the state evaluation parameter. The calculation formula for this state evaluation parameter is as follows:

[0086] A(t) = w c ·C(t)+w r ·R(t)+w l ·L(t); (5)

[0087] Among them, w c w r w l These are the relevant weight coefficients for state credibility, historical detection success rate, and detection delay penalty, respectively.

[0088] In this implementation, multi-dimensional historical data of the target MCP tool is first extracted from the tool status monitoring pool. Then, the three-dimensional indicators are weighted and fused to achieve a comprehensive evaluation of the tool's "timeliness, stability, and efficiency." This ensures that the status evaluation parameters can fully reflect the tool's timeliness, availability, and response speed, providing a reliable basis for subsequent invocation decisions.

[0089] Step S20: Generate the invocation decision of the target MCP tool based on the state evaluation parameters.

[0090] It should be noted that the calling device can assess the availability of the target MCP based on the calculated status assessment parameters and determine the operation instructions for the target MCP tool, namely the aforementioned calling decision, such as direct calling, determining whether to call after triggering detection, or directly rejecting the call, etc.

[0091] In one feasible implementation, step S20 includes steps S21 to S23:

[0092] Step S21: When the state evaluation parameter is not greater than the first confidence threshold, the fault isolation mechanism is triggered;

[0093] It is easy to understand that this embodiment can generate a call decision corresponding to the target MCP tool based on the comparison between the state evaluation parameters and the preset call threshold, namely the first confidence threshold and the second confidence threshold mentioned above.

[0094] The first confidence threshold can be a critical value (such as 0.3) used to determine whether the tool is faulty. When the status assessment parameter is less than or equal to this value, the target MCP tool is determined to be at high risk or likely to be unusable. The corresponding fault handling method is to trigger the fault isolation mechanism, refuse to call and prompt the tool to be in an abnormal state or untrustworthy state.

[0095] It should be understood that the fault isolation mechanism can be a mechanism that temporarily excludes a tool from the pool of available tools when the tool's status evaluation parameters are too low, in order to avoid invalid calls to high-risk MCP tools. Therefore, in a feasible implementation, in this embodiment, step S21 includes step B1:

[0096] Step B1: Mark the target MCP tool as isolated and set the isolation window duration, which is determined based on the historical fault recovery time of the target MCP tool;

[0097] Step B2: During the isolation window duration, reject the call request of the target MCP tool.

[0098] Understandably, the aforementioned isolation status can be a "temporarily unavailable" status indicator for the MCP tool. If this status indicator is identified as indicating a high risk for the MCP tool, invalid calls to the MCP tool can be avoided. After triggering the fault isolation mechanism, the calling device can update the status field of the target MCP tool to "isolation status" and record the isolation start time.

[0099] The isolation window duration can be the duration the tool remains in isolation (e.g., 5 minutes). Historical fault recovery time can be based on the average time the target MCP tool has taken to recover from a fault in the past. In this case, the calling device can use the historical fault recovery time increased by a certain percentage (e.g., 20%) as the isolation window duration. For example, if the average recovery time across multiple faults is 3 minutes, then the isolation window duration can be set to 5 minutes. Within the isolation window duration, all calls to the target MCP tool will directly return "Tool temporarily unavailable," without executing any actual calls, reducing invalid call attempts to the faulty tool and improving system resource utilization.

[0100] Furthermore, in this embodiment, each MCP tool in the MCP tool library may have a corresponding backup option or prompt message, and resources may be released (i.e., the tool is removed from the MCP tool library). Simultaneously, a joint decision function D∈{1,2} can be defined, as shown below:

[0101]

[0102] Among them, B j D=1 indicates that there is a backup tool; D=1: there is no backup tool, prompting the user to try again later; D=2: there is a backup MCP tool, recommending and switching to the corresponding backup MCP tool.

[0103] In this implementation, the isolation duration is dynamically set based on historical fault recovery data to avoid invalid calls caused by premature release of isolation or idle MCP tools caused by premature release of isolation.

[0104] Step S22: When the state evaluation parameter is greater than the first confidence threshold and less than the second confidence threshold, trigger instant detection, and call the target MCP tool when the instant detection result passes.

[0105] Step S23: When the state evaluation parameter is not less than the second confidence threshold, the target MCP tool is invoked.

[0106] It is easy to understand that the aforementioned second confidence threshold can be a critical value (such as 0.7) used to determine whether a tool can be directly invoked. When the state evaluation parameter is greater than or equal to this value, it is determined that the target MCP tool is currently in a good state and can be invoked directly without isolation.

[0107] When the status assessment parameters are between the first and second confidence thresholds, it indicates that the tool status needs further observation. Therefore, it indicates that the target MCP tool has potential risks and can trigger an immediate probe of the real-time status of the target MCP tool (such as sending a test request). If the probe is successful, the target MCP tool will be invoked; if the probe is successful, the fault isolation mechanism will be triggered.

[0108] In this embodiment, by using dual-threshold hierarchical decision-making, invalid calls to faulty MCP tools are reduced, and the detection cost of stable MCP tools is lowered, thus balancing the efficiency and reliability of MCP calls.

[0109] In summary, in this embodiment, when the calling device receives an MCP tool call request, it first parses the target tool identifier in the request; then it queries the tool status monitoring pool to obtain the tool's historical probe records (such as probe results in the last 24 hours) and corresponding timestamps; based on this historical data, it calculates status evaluation parameters (such as a comprehensive availability score); finally, based on the comparison between the status evaluation parameters and a preset credibility threshold, it decides whether to call the tool, probe first and then call, or isolate it directly. Therefore, this embodiment proposes a tool status management mechanism based on a "tool status cache pool," which decouples probe and call behaviors, constructs a multi-dimensional status evaluation model, and combines dynamic probe frequency adjustment and adaptive fault isolation strategies to achieve intelligent decision-making on the availability of MCP tools, ensuring the success rate of tool calls and avoiding resource waste caused by blind calls.

[0110] This embodiment provides a method for invoking an MCP tool. The method includes: upon receiving a tool invocation request, obtaining a target detection timestamp, target detection result, and target detection delay time from a tool status monitoring pool based on the target MCP tool's tool identifier; determining the state credibility of the target MCP tool based on the target detection timestamp; determining the historical detection success rate of the target MCP tool based on the target detection result; determining the detection delay penalty item of the target MCP tool based on the target detection delay time; and obtaining a state evaluation parameter of the target MCP tool by weighting the state credibility, historical detection success rate, and detection delay penalty item. When the state evaluation parameter is not greater than a first credibility threshold, marking the target MCP tool as isolated and setting an isolation window duration, the isolation window duration being determined based on the historical fault recovery time of the target MCP tool; rejecting the invocation request of the target MCP tool within the isolation window duration; triggering immediate detection when the state evaluation parameter is greater than the first credibility threshold and less than a second credibility threshold, and invoking the target MCP tool when the immediate detection result passes; and invoking the target MCP tool when the state evaluation parameter is not less than the second credibility threshold. This embodiment constructs a tool status credibility model by maintaining historical detection records and their timestamp information, and combines it with an instant detection strategy to achieve status assessment before invocation, replacing the traditional "direct invocation" mode. It dynamically judges the availability of the tool before invocation, solving the problems of high tool invocation failure rate, long user waiting time, and waste of model resources in the prior art.

[0111] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment described above can be referred to the above description, and will not be repeated hereafter.

[0112] It is understandable that historical data in the tool status monitoring pool may be outdated, leading to inaccurate subsequent evaluation results (e.g., the tool status has changed but the data has not been updated). Therefore, based on the first embodiment, please refer to... Figure 3 , Figure 3 This is a first flowchart illustrating the second embodiment of the MCP tool invocation method of this application. In this embodiment, after step S20, the MCP tool invocation method further includes steps S30 to S40:

[0113] Step S30: Perform a health status detection on the target MCP tool based on the status assessment parameters;

[0114] Understandably, the aforementioned health status detection can be an additional check performed on the target MCP tool after the decision is executed (such as sending a lightweight test request) to verify the tool's current actual state. Furthermore, this embodiment can adjust the detection frequency of the health status detection based on the status assessment parameters (e.g., a longer detection interval for higher parameters and a shorter interval for lower parameters), sending test requests to the MCP tool and recording the results.

[0115] At this point, a service health status function S(t)∈{0,1} can be defined to represent whether the tool is available at time t. Here, S(t) = 1 indicates that the tool is currently callable; S(t) = 0 indicates that the tool is abnormal or unreachable.

[0116] Therefore, even after the target MCP tool has been called, if S(t) = 0, the formal call is skipped and the process directly enters the failure degradation process; if S(t) = 1, the formal call continues to be executed.

[0117] In one feasible implementation, refer to Figure 4 , Figure 4 This is a second flowchart illustrating the first embodiment of the MCP tool invocation method of this application. In this embodiment, step S30 includes steps S31 to S33:

[0118] Step S31: Determine the current detection window of the target MCP tool based on the state evaluation parameters;

[0119] Step S32: Determine the target detection time based on the current detection window and the state confidence level;

[0120] Step S33: Perform a health status detection on the target MCP tool based on the target detection time.

[0121] It should be noted that this embodiment may introduce adaptive recovery window adjustment, that is, automatically adjust the detection window size of health status detection according to the status assessment parameters to adapt to different business scenarios. The determined adaptive recovery window, i.e., the current detection window mentioned above, is used to control the time interval of the next detection attempt, and can be represented as W. recover (t), and defined as follows:

[0122]

[0123] As can be seen from formula (7), the lower the score of the state evaluation parameter A(t), the shorter the recovery window W. recover The shorter the (t) value, the more frequent the detection.

[0124] It is easy to understand that the above target detection time can be the next detection time determined by the larger value between the health status detection time interval dynamically adjusted based on the current detection window and the forced detection time interval. The shorter the interval, the more frequent the detection.

[0125] Furthermore, in this embodiment, the target detection time can be dynamically adjusted based on the state confidence level C(t), the current detection window, and the minimum forced detection interval, which can be expressed as follows:

[0126] T next =max(t+W) recover ·e -β·c(t) ,t last_probe +T min_force (8)

[0127] Where t is the current timestamp; β = 2; C(t) is taken from the probe cache pool H; W recover ·e -β·c(t) The original detection interval; t last_probe The timestamp of the last probe is taken from the probe cache pool H; T min_force The minimum forced detection time can be set to 60 seconds.

[0128] For example, suppose the current timestamp t is 1000, and the last probe timestamp t last_probe When C(t) = 940 and C(t) = 0.1, β = 2, T min_force =60, current availability score A(t) = 0.2; original detection interval W recover ·e -β·c(t) =60×e -2v1 ≈49s, so the next detection time is 1000+49≈1049s, and the forced target detection time is 940+60=1000s.

[0129] At this point, the next probe timestamp is T. next =max(1049,1000)=1049s.

[0130] Therefore, after confirming the target detection time, this embodiment can send an adaptive test request to the target MCP tool according to the target detection time, record the detection results, and update the tool status monitoring pool in a timely manner.

[0131] In this embodiment, the detection frequency of health status detection can be dynamically adjusted according to the tool status. The more unstable the status (low parameters, low reliability), the more frequent the detection, ensuring timely detection of changes in the tool's status. At the same time, by dynamically adjusting the detection interval, unnecessary detection overhead is reduced while ensuring timely understanding of the tool's status, thus improving system efficiency.

[0132] Step S40: Update the tool status monitoring pool based on the health status detection results.

[0133] It is easy to understand that in this embodiment, the results of health status detection (success / failure, delay time) can be stored in the tool status monitoring pool with corresponding timestamps to replace old data or add new records. For example, the latest N records (such as the most recent 20 records) can be retained by sorting by time, while old data can be discarded to ensure the freshness of historical data.

[0134] Furthermore, based on the aforementioned health status detection, this embodiment can further define that an isolated MCP tool will trigger a recovery attempt when any of the following conditions are met:

[0135] 1) The current time since the last detection exceeds the isolation window W. recover ;

[0136] 2) The most recent probe result in the probe cache pool was successful;

[0137] 3) The results of the new round of detection show that A(t) ≥ 0.7.

[0138] In summary, after generating and executing a call decision based on the status assessment parameters, this embodiment performs a health status probe on the target MCP tool according to these parameters. The probed timestamps, results, and delay times are then updated to the tool status monitoring pool, replacing or supplementing historical records. Thus, through dynamic probing and data updates after the call, the tool status monitoring pool always reflects the latest status of the tool, providing reliable data for subsequent assessments and forming a closed loop of "assessment-call-update".

[0139] This embodiment discloses determining the current probe window of the target MCP tool based on state assessment parameters; determining the target probe time based on the current probe window and state reliability; and performing health status detection on the target MCP tool based on the target probe time. The tool status monitoring pool is updated based on the health status detection results. After generating and executing a call decision based on the state assessment parameters, a health status detection is performed on the target MCP tool according to these parameters; the detected timestamps, results, and delay times are updated to the tool status monitoring pool, replacing or supplementing historical records. Thus, through dynamic detection and data updates after the call, the tool status monitoring pool always reflects the latest state of the tool, providing reliable data for subsequent evaluations and forming a closed loop of "evaluation-call-update".

[0140] For example, to help understand the technical concept or principle of the MCP tool invocation method after combining this embodiment with the above-described Embodiments 1 and 2, please refer to Figure 5 , Figure 5 The following is a simplified flowchart illustrating the MCP tool invocation method of this application:

[0141] 1) Upon detecting an incoming tool invocation request, query the corresponding tool status cache pool H (i.e., based on the tool identifier of the target MCP tool to be invoked, such as the service ID) Figure 5 (in the probe cache pool);

[0142] 2) Calculate the state assessment parameter A(t) of the target MCP tool based on the historical detection data obtained from the tool condition monitoring pool;

[0143] 3) Determine the invocation decision based on the state evaluation parameter A(t) and the preset confidence threshold:

[0144] a) If A(t) is greater than or equal to the second confidence threshold of 0.7, then directly call the target MCP tool service;

[0145] b) If A(t) is less than the first confidence threshold of 0.7, then determine whether the target MCP tool is in an isolated state, that is, determine whether A(t) is less than or equal to the second confidence threshold of 0.3. If so, then directly trigger isolation and execute the fault isolation mechanism.

[0146] If not, that is, if A(t) is greater than the first confidence threshold of 0.3 and less than the second confidence threshold of 0.7, an instant probe is initiated, and the target MCP tool service is directly called based on the probe result. If the state evaluation parameter corresponding to the new probe result meets the standard (i.e., the new A(t) is greater than or equal to 0.7), the target MCP tool service is directly called; otherwise, the fault isolation mechanism is directly executed.

[0147] 4) Perform health status detection on the target MCP tool based on the status assessment parameters. This explanation mainly focuses on MCP tools that are in a fault isolation mechanism:

[0148] First, the current recovery window is determined based on the state evaluation parameter A(t), and the dynamic detection frequency is determined based on the state evaluation parameter and the current recovery window. Then, health status detection is performed based on the dynamic detection frequency.

[0149] Then, if the health status detection of the MCP tool meets the normal conditions in a certain round, the isolation of the MCP tool is lifted and the tool status cache pool H is updated; otherwise, its isolation status is maintained.

[0150] The normal condition is: the current time since the last detection exceeds the isolation window W.recover The most recent probe result in the probe cache pool is successful; or the new round of probe results show A(t)≥0.7.

[0151] For the MCP tool that is directly invoked, the detection data of its health status detection, which is dynamically adjusted according to the status assessment parameters, should also be updated to the tool status cache pool H.

[0152] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the MCP tool calling method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0153] This application also provides an MCP tool invocation device, please refer to... Figure 6 , Figure 6 This is a schematic diagram of the module structure of the MCP tool invocation device according to an embodiment of this application. In this embodiment, the MCP tool invocation device includes:

[0154] When the detection module 601 receives a tool call request, it determines the status evaluation parameters corresponding to the target MCP tool based on the tool status monitoring pool; the tool status monitoring pool stores the historical detection records and corresponding historical detection timestamps of each MCP tool.

[0155] The calling module 602 is used to generate a calling decision for the target MCP tool based on the state evaluation parameters.

[0156] As one possible implementation, in this embodiment, the detection module 601 is further configured to determine the status evaluation parameters corresponding to the target MCP tool based on the tool status monitoring pool when a tool invocation request is received; the tool status monitoring pool stores historical detection records and corresponding historical detection timestamps for each MCP tool; and generate an invocation decision for the target MCP tool based on the status evaluation parameters.

[0157] As one possible implementation, in this embodiment, the detection module 601 is further configured to obtain the target detection timestamp, target detection result, and target detection delay time from the tool status monitoring pool based on the tool identifier of the target MCP tool; and determine the status evaluation parameters corresponding to the target MCP tool based on the target detection timestamp, target detection result, and target detection delay time.

[0158] As one possible implementation, in this embodiment, the detection module 601 is further configured to determine the state credibility of the target MCP tool based on the target detection timestamp; determine the historical detection success rate of the target MCP tool based on the target detection result; determine the detection delay penalty item of the target MCP tool based on the target detection delay time; and obtain the state evaluation parameters of the target MCP tool by performing a weighted calculation on the state credibility, the historical detection success rate and the detection delay penalty item.

[0159] As one possible implementation, in this embodiment, the calling module 602 is further configured to trigger a fault isolation mechanism when the state evaluation parameter is not greater than a first confidence threshold; trigger instant detection when the state evaluation parameter is greater than the first confidence threshold and less than a second confidence threshold, and call the target MCP tool when the instant detection result passes; and call the target MCP tool when the state evaluation parameter is not less than the second confidence threshold.

[0160] As one possible implementation, in this embodiment, the calling module 602 is further configured to mark the target MCP tool as isolated and set an isolation window duration, the isolation window duration being determined based on the historical fault recovery time of the target MCP tool; within the isolation window duration, the calling request of the target MCP tool is rejected.

[0161] As one possible implementation, in this embodiment, the detection module 601 is further configured to perform health status detection on the target MCP tool according to the status assessment parameters; and update the tool status monitoring pool based on the health status detection results.

[0162] As one possible implementation, in this embodiment, the detection module 601 is further configured to determine the current detection window of the target MCP tool based on the state evaluation parameters; determine the target detection time based on the current detection window and the state confidence level; and perform health status detection on the target MCP tool based on the target detection time.

[0163] The MCP tool invocation device provided in this application, employing the MCP tool invocation method in the above embodiments, can solve the technical problems of low invocation efficiency and poor reliability caused by unclear status during existing MCP tool invocation processes. Compared with the prior art, the beneficial effects of the MCP tool invocation device provided in this application are the same as those of the MCP tool invocation method provided in the above embodiments, and other technical features in the MCP tool invocation device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0164] This application provides an MCP tool invocation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the MCP tool invocation method in the above embodiment 1.

[0165] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a device suitable for implementing the MCP tool invocation device in the embodiments of this application. The MCP tool invocation device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The MCP tool shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0166] like Figure 7As shown, the MCP tool invocation device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the MCP tool invocation device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the MCP tool calling device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows an MCP tool calling device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0167] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in this application include an MCP tool invoking program product, which includes an MCP tool invoking program carried on a computer-readable medium, the MCP tool invoking program containing program code for performing the methods shown in the flowcharts. In such embodiments, the MCP tool invoking program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the MCP tool invoking program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0168] The MCP tool invocation device provided in this application, employing the MCP tool invocation method described in the above embodiments, can solve the technical problems of low invocation efficiency and poor reliability caused by unclear status during existing MCP tool invocation processes. Compared with the prior art, the beneficial effects of the MCP tool invocation device provided in this application are the same as those of the MCP tool invocation method provided in the above embodiments, and other technical features in this MCP tool invocation device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0169] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0170] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0171] This application provides a storage medium having computer-readable program instructions (i.e., an MCP tool invoking program) stored thereon, the computer-readable program instructions being used to execute the MCP tool invoking method in the above embodiments.

[0172] The storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0173] The aforementioned storage medium may be included in the MCP tool invocation device; or it may exist independently and not be assembled into the MCP tool invocation device.

[0174] The aforementioned storage medium carries one or more programs. When the aforementioned one or more programs are executed by the MCP tool invocation device, the MCP tool invocation device can solve the technical problems of low invocation efficiency and poor reliability caused by unclear status during the existing MCP tool invocation process.

[0175] The MCP tool-calling program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, C++, Python, JavaScript, Rust, etc.—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0177] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0178] The readable storage medium provided in this application is a storage medium that stores computer-readable program instructions (i.e., MCP tool calling program) for executing the above-described MCP tool calling method. This solves the technical problem of low calling efficiency and poor reliability caused by unclear status during existing MCP tool calling processes. Compared with the prior art, the beneficial effects of the storage medium provided in this application are the same as those of the MCP tool calling method provided in the above embodiments, and will not be repeated here.

[0179] The above are only some embodiments of this application and do not limit the scope of the solution of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A method for calling an MCP tool, characterized in that, The method includes: When a tool invocation request is received, the status evaluation parameters corresponding to the target MCP tool are determined based on the tool status monitoring pool; the tool status monitoring pool stores the historical detection records and corresponding historical detection timestamps of each MCP tool. The invocation decision for the target MCP tool is generated based on the state assessment parameters.

2. The MCP tool invocation method as described in claim 1, characterized in that, The step of determining the status assessment parameters corresponding to the target MCP tool based on the tool status monitoring pool includes: Based on the tool identifier of the target MCP tool, the target detection timestamp, target detection result, and target detection delay time are obtained from the tool status monitoring pool. The state assessment parameters corresponding to the target MCP tool are determined based on the target detection timestamp, target detection result, and target detection delay time.

3. The MCP tool invocation method as described in claim 2, characterized in that, The step of determining the state assessment parameters corresponding to the target MCP tool based on the target detection timestamp, target detection result, and target detection delay time includes: The state credibility of the target MCP tool is determined based on the target detection timestamp. The historical detection success rate of the target MCP tool is determined based on the target detection results. Determine the detection delay penalty item corresponding to the target MCP tool based on the target detection delay time; The state evaluation parameters corresponding to the target MCP tool are obtained by weighting the state credibility, the historical detection success rate, and the detection delay penalty term.

4. The MCP tool invocation method as described in claim 1, characterized in that, The step of generating the invocation decision for the target MCP tool based on the state assessment parameters includes: When the state evaluation parameter is not greater than the first confidence threshold, the fault isolation mechanism is triggered; When the state evaluation parameter is greater than the first confidence threshold and less than the second confidence threshold, an instant detection is triggered, and the target MCP tool is invoked when the instant detection result passes. When the state evaluation parameter is not less than the second confidence threshold, the target MCP tool is invoked.

5. The MCP tool invocation method as described in claim 4, characterized in that, The step of triggering the fault isolation mechanism when the state evaluation parameter is not greater than the first confidence threshold includes: The target MCP tool is marked as isolated, and the isolation window duration is set, which is determined based on the historical fault recovery time of the target MCP tool. During the isolation window period, the call request of the target MCP tool is rejected.

6. The MCP tool invocation method as described in claim 2, characterized in that, After generating the invocation decision for the target MCP tool based on the state assessment parameters, the method further includes: The target MCP tool is subjected to health status detection based on the stated status assessment parameters; The tool status monitoring pool is updated based on the health status detection results.

7. The MCP tool invocation method as described in claim 6, characterized in that, The step of performing health status detection on the target MCP tool based on the status assessment parameters includes: The current detection window of the target MCP tool is determined based on the state assessment parameters; The target detection time is determined based on the current detection window and the state confidence level. The target MCP tool performs a health status detection based on the target detection time.

8. An MCP tool invocation device, characterized in that, The MCP tool invocation device includes: When the detection module receives a tool invocation request, it determines the status evaluation parameters corresponding to the target MCP tool based on the tool status monitoring pool; the tool status monitoring pool stores the historical detection records and corresponding historical detection timestamps of each MCP tool. The calling module is used to generate a calling decision for the target MCP tool based on the state evaluation parameters.

9. An MCP tool for calling a device, characterized in that, The MCP tool invocation device includes: a memory, a processor, and an MCP tool invocation program stored in the memory and executable on the processor, the MCP tool invocation program being configured to implement the steps of the MCP tool invocation method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a storage medium that stores an MCP tool calling program. When the MCP tool calling program is executed by the processor, it implements the steps of the MCP tool calling method as described in any one of claims 1 to 7.

Images