Communication method and device based on MCP protocol, storage medium and program product

Abstract

The embodiment of the invention provides a communication method and device based on an MCP protocol, a storage medium and a program product. The method comprises the following steps: acquiring publisher information of the MCP service; distributing a unique identifier for the MCP service according to the publisher information; combining the unique identifier with a tool identifier of an MCP tool provided by the MCP service to obtain a combined tool identifier; based on the combined tool identifier, adding an MCP tool in a tool list; wherein the tool list is used for recording the MCP tool which can be called by the first pre-training language model.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a communication method, device, storage medium, and program product based on the MCP protocol. Background Technology

[0002] The Model Context Protocol (MCP) is an open protocol designed to unify the communication protocol between artificial intelligence (AI) models and external data sources and tools. It defines the interaction rules between models and tools and supports dynamic expansion of functionality.

[0003] As MCP is widely used as a core open protocol connecting AI models and external tools, the security risks brought about by its dynamic expansion capabilities are becoming increasingly prominent.

[0004] Therefore, a security protection solution for the MCP protocol is urgently needed. Summary of the Invention

[0005] This specification provides a communication method, device, storage medium, and program product based on the MCP protocol in several aspects to improve system security and execution reliability.

[0006] The first aspect of this specification provides a communication method based on the MCP protocol, including: Obtain information about the publisher of MCP services; A unique identifier is assigned to the MCP service based on the publisher information; The unique identifier is combined with the tool identifier of the MCP tool provided by the MCP service to obtain the combined tool identifier; Based on the combined tool identifier, add the MCP tool to the tool list; The tool list is used to record the MCP tools that the first pre-trained language model can call.

[0007] The second aspect of this specification provides a communication method based on the MCP protocol, including: Obtain a tool invocation request sent by the MCP client. The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool. Using a second pre-trained language model, the intent of the tool call request is identified, and a risk verification result is generated based on the intent identification result. Based on the risk verification result, determine whether to forward the tool call request to the target MCP service.

[0008] A third aspect of this specification provides a communication method based on the MCP protocol, comprising: Obtain a tool invocation request sent by the MCP client. The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool. Obtain the second service content and second digital signature of the target MCP service from the target MCP service; The second digital signature is used to verify the signature of the second service content; When the verification is successful, the tool invocation request is forwarded to the target MCP service; If the verification fails, the tool call request is rejected.

[0009] The fourth aspect of this specification provides a communication method based on the MCP protocol, including: Obtain a tool invocation request sent by the MCP client. The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool. Forward the tool invocation request to the target MCP service; Receive the return result from the target MCP service in response to the tool invocation request; Using a second pre-trained language model, the returned result is subjected to intent recognition, and a second risk recognition result is generated based on the intent recognition result; When the second risk identification result meets the preset requirements, the return result is sent to the MCP client; If the second risk identification result does not meet the preset requirements, the returned result is discarded.

[0010] The fifth aspect of this specification provides a communication device based on the MCP protocol, comprising: The acquisition module is used to obtain information about the publisher of the MCP service; The allocation module is used to allocate a unique identifier to the MCP service based on the publisher information; The combination module is used to combine the unique identifier with the tool identifier of the MCP tool provided by the MCP service to obtain the combined tool identifier. An add module is used to add the MCP tool to the tool list based on the combined tool identifier; The tool list is used to record the MCP tools that the first pre-trained language model can call.

[0011] A sixth aspect of this specification provides a communication device based on the MCP protocol, comprising: The acquisition module is used to acquire tool call requests sent by the MCP client. The tool call request is generated by the MCP client based on the tool call instruction output by the first pre-trained language model. The tool call instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool call request is used to request the invocation of the target MCP tool. The identification module is used to identify the intent of the tool call request using a second pre-trained language model, and generate a risk verification result based on the intent identification result. The determination module is used to determine, based on the risk verification result, whether to forward the tool call request to the target MCP service.

[0012] The seventh aspect of this specification provides a communication device based on the MCP protocol, comprising: The first acquisition module is used to acquire a tool call request sent by the MCP client. The tool call request is generated by the MCP client based on the tool call instruction output by the first pre-trained language model. The tool call instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool call request is used to request the invocation of the target MCP tool. The second acquisition module is used to acquire the second service content and the second digital signature of the target MCP service from the target MCP service. The verification module is used to verify the signature of the second service content using the second digital signature; The forwarding module is used to forward the tool call request to the target MCP service when the verification is successful; The rejection module is used to reject the tool call request when the verification fails.

[0013] The eighth aspect of this specification provides a communication device based on the MCP protocol, comprising: The acquisition module is used to acquire tool call requests sent by the MCP client. The tool call request is generated by the MCP client based on the tool call instruction output by the first pre-trained language model. The tool call instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool call request is used to request the invocation of the target MCP tool. The forwarding module is used to forward the tool invocation request to the target MCP service; A receiving module is used to receive the return result of the target MCP service in response to the tool invocation request; The identification module is used to perform intent identification on the returned result using a second pre-trained language model, and generate a second risk identification result based on the intent identification result; The sending module is used to send the return result to the MCP client when the second risk identification result meets the preset requirements; The discard module is used to discard the returned result when the second risk identification result does not meet the preset requirements.

[0014] A ninth aspect of this specification provides an electronic device, comprising: a memory and a processor, wherein, The memory is used to store programs; The processor, coupled to the memory, is configured to execute the program stored in the memory to implement the method described in any of the preceding embodiments.

[0015] A tenth aspect of this specification provides a computer-readable storage medium storing a computer program that, when executed by a computer, enables the implementation of any of the methods described above.

[0016] The eleventh aspect of this specification provides a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the preceding descriptions.

[0017] In the technical solution provided in the embodiments of this specification, when adding an MCP tool provided by an MCP service to the tool list accessible to the pre-trained language model, a globally unique identifier is assigned to the MCP service based on the publisher information of the MCP service. This unique identifier is then combined with the tool identifier of the MCP tool provided by the MCP service to obtain a combined tool identifier. The MCP tool is then added to the tool list based on this combined tool identifier. In this way, the MCP tools in the tool list can be uniquely identified using this combined tool identifier, thereby helping the pre-trained language model effectively distinguish between various tools. This solves the technical problems of tool naming conflicts and call confusion in multi-service environments, prevents cross-service tool overwriting, reduces the invocation of forged or tampered tools, reduces the risk of tool shadow attacks, lowers the possibility of legitimate operation flows being maliciously hijacked, and improves system security and execution reliability.

[0018] The technical solution provided in the embodiments of this specification utilizes a pre-trained language model to perform semantic understanding on tool call requests sent by MCP clients, obtaining the true intent of the tool call request. Based on the true intent, it determines whether the tool call request poses a risk, and then decides whether to forward the tool call request to the target MCP service. Semantic scanning can effectively identify concealed attack content in tool call requests, such as concealed attack instructions described in natural language or malicious executable code blocks. Semantic scanning can effectively improve the detection rate of attack content and can also effectively deal with new types of attack content, making the solution highly adaptable.

[0019] In the technical solution provided in the embodiments of this specification, after obtaining the tool invocation request sent by the MCP client, the service content and digital signature of the MCP service invoked by the tool invocation request are obtained. The service content is then verified using the digital signature. This not only verifies the identity of the MCP service provider but also verifies the data integrity of the service content, thereby ensuring that the current MCP service is provided by a legitimate provider and has not been tampered with. Digital signatures effectively improve the security of tool invocations.

[0020] The technical solution provided in the embodiments of this specification utilizes a pre-trained language model to perform semantic understanding on the return results of the MCP service, obtain the true intent of the return results, determine whether the return results pose a risk based on the true intent, and then decide whether to return the return results to the MCP client. Semantic scanning can effectively identify covert attack content in the return results, such as: covert instructions described in natural language and variant attacks (including: encoded data obtained by semantically encoding malicious attack content). Semantic scanning can effectively improve the recognition rate of attack content and can also effectively deal with new types of attack content, making the solution highly adaptable. Attached Figure Description

[0021] The accompanying drawings, which are provided to further illustrate this specification, form part of this specification.

[0022] Figure 1 A schematic diagram of the MCP protocol architecture provided for an exemplary embodiment of this specification; Figure 2 A schematic diagram of the MCP protocol architecture provided as yet another exemplary embodiment of this specification; Figures 3-8 A flowchart illustrating the communication methods provided for different exemplary embodiments of this specification; Figure 9 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this specification. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments, and not all of the embodiments. Based on these embodiments, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0024] It should be noted that, in the cases involving user information in the embodiments of this specification, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this specification (including but not limited to language models or large models) comply with relevant laws and standards.

[0025] In the embodiments of this specification, the AI ​​model refers to a Language Model (LM), a deep learning model trained on data, which typically possesses broad task adaptability and reasoning capabilities, such as the Transformer architecture model. These models can understand complex contextual information and generate accurate predictions and suggestions in scenarios such as data analysis and decision support. The embodiments of this specification do not limit the number of model parameters supported by the language model, aiming to meet application requirements. If the model has relatively more parameters, the language model will be relatively larger in scale and have relatively better performance; however, it will consume more time and resources during inference and training. If the model has relatively fewer parameters, the language model will be relatively smaller in scale, and while meeting performance requirements, it will be more lightweight, consuming relatively less time and resources during inference and training. When the number of model parameters of a language model is greater than or equal to a preset threshold, the language model can be called a Large Language Model (LLM).

[0026] The working principle of the MCP protocol is explained below. MCP works based on a client-server architecture, using a standardized communication protocol to achieve seamless integration of AI models (e.g., LLM) with external tools and data sources.

[0027] like Figure 1 As shown, the MCP architecture may include: MCP Client 2 (Client) refers to the protocol client that connects to the MCP server and serves as an extended interface for the LLM model, used to receive user queries, process context information, and call external tools.

[0028] MCP Server 3 (Server), or MCP Service for short, refers to a lightweight program that exposes specific functions through a standardized model context protocol.

[0029] MCP Client 2 is the core bridge connecting LLM and external tools. Its core function is to convert LLM's natural language instructions (such as tool call instructions) into standardized protocol requests and coordinate the MCP server to perform specific operations.

[0030] MCP Server 3 is the core execution layer that enables seamless interaction between AI models and external tools / data sources. It encapsulates specific functionalities into callable units through standardized protocols, supporting both lightweight operations on local devices and the construction of distributed systems. MCP Server 3 can include a local MCP server running on a local machine and / or a remote MCP server running on a remote machine (e.g., in the cloud). The MCP server can provide multiple MCP tools.

[0031] In practical applications, the MCP server can provide three main types of functions: Tools: Functions that can be called by the LLM, such as retrieving weather forecasts and querying databases. In this article, they are referred to as MCP tools.

[0032] Resources: File-like data that can be read by clients, such as API responses or file content.

[0033] Prompts: Preset templates to help users complete specific tasks and optimize LLM output.

[0034] The MCP workflow includes: the MCP client constructs a tool invocation request based on the LLM tool invocation instructions and sends it to the MCP server. Upon receiving the request, the MCP server parses the request content and performs the corresponding operation (such as querying the database or reading a file). The MCP server then encapsulates the processing result into a response message and sends it back to the MCP client.

[0035] In practical applications, communication schemes based on the MCP protocol have the following security risks: 1. Cross-server tool overwriting: Malicious services can tamper with function definitions through tools with the same name (such as "tool shadow attacks"), hijacking legitimate operation flows.

[0036] Tool shadowing attack refers to an attacker registering a tool with the same name (such as forging ns:attacker / tool:stock) to override the definition of a legitimate tool and induce AI to perform malicious operations.

[0037] 2. Content poisoning: Injecting malicious commands (such as hiding shell commands) by tampering with tool descriptions or returned data.

[0038] Currently, content poisoning methods are becoming more covert. Attackers are injecting malicious commands (such as hiding shell commands) using natural language descriptions or structured parameters, bypassing traditional regular expression filtering, and causing AI to perform dangerous behaviors (such as data leakage).

[0039] 3. Abuse of permissions and user deception: The lack of fine-grained permission isolation and dynamic verification mechanisms makes users easily tricked into authorizing sensitive operations (such as file deletion and database export).

[0040] 4. Silent Redefinition (Rug Pull): Malicious MCP Servers hide high-risk changes (such as adding exec() parameters) during tool upgrades, tricking users into using the tool and triggering an attack.

[0041] To solve or partially solve the above-mentioned technical problems, this specification provides a security protection scheme for the MCP protocol. For example... Figure 2 As shown, this solution adds a security proxy module 13 between the MCP client 12 and the MCP service 14, and the security protection is implemented by the security proxy module 13.

[0042] The following is combined with Figure 3 This specification provides a detailed description of the communication method based on the MCP protocol provided in the embodiments. Figure 3 This is a flowchart illustrating the communication method based on the MCP protocol provided in the embodiments of this specification. The execution entity of this method can be... Figure 2 The security proxy module 13 in the example. Figure 3 As shown, the method includes: 100. Obtain information about the publisher of the MCP service.

[0043] 102. Assign a unique identifier to the MCP service based on the publisher information.

[0044] 104. Combine the unique identifier with the tool identifier of the MCP tool provided by the MCP service to obtain the combined tool identifier.

[0045] 106. Based on the combined tool identifier, add the MCP tool to the tool list.

[0046] The tool list is used to record the MCP tools that the first pre-trained language model can call.

[0047] In the above 100, the publisher information may include the publisher's organizational identity information, such as: organization name, registered domain name, unified social credit code of the enterprise, digital certificate information or organization ID assigned by the publishing platform, to ensure the uniqueness of service identifiers between different organizations.

[0048] In some embodiments, the security proxy module may obtain publisher information from the MCP service from the publisher of the MCP service.

[0049] In some embodiments of 102 above, the publisher information and the service name of the MCP service can be combined as a unique identifier and assigned to the MCP service.

[0050] Optionally, a unique namespace can be assigned to the MCP service based on the publisher information. For example, if the publisher's registered domain name is XXX and the service name of the MCP service is "map service", then the unique namespace would be XXX.mapservice.

[0051] In some embodiments of the above 104, the unique identifier can be added as a prefix before the tool identifier of the MCP tool to obtain a combined tool identifier. In this embodiment, the unique identifier can be referred to as a unique namespace.

[0052] In other embodiments, the unique identifier can be added as a suffix before the tool identifier of the MCP tool to obtain a combined tool identifier.

[0053] The specific combination method can be designed according to actual needs, and the embodiments in this specification do not impose specific limitations on it.

[0054] As can be seen, this solution achieves the binding between the MCP tool and the unique namespace.

[0055] In step 106 above, the security agent module can add the MCP tool to the tool list using the MCP client based on the combined tool identifier. For example, the security agent module can send the combined tool identifier to the MCP client, and the MCP client can add the combined tool identifier, tool description information, etc., of the MCP tool to the tool list.

[0056] In some embodiments, the security proxy module replaces the tool identifier of the MCP tool in the tool description information of the MCP service with the combined tool identifier to obtain modified tool description information; the modified tool description information is sent to the MCP client so that the MCP client can add the MCP tool to the tool list based on the modified tool description information.

[0057] In the embodiments described in this specification, the tool list is a list maintained by the MCP client, which determines which MCP tools the first pre-trained language model can call. That is, when you want to add more MCP tools that the pre-trained language model can call, you need to first add the corresponding MCP tool to this tool list. The pre-trained language model will then use this tool list to determine which MCP tool to call.

[0058] In the technical solution provided in the embodiments of this specification, when adding an MCP tool provided by an MCP service to the tool list accessible to the pre-trained language model, a globally unique identifier is assigned to the MCP service based on the publisher information of the MCP service. This unique identifier is then combined with the tool identifier of the MCP tool provided by the MCP service to obtain a combined tool identifier. The MCP tool is then added to the tool list based on this combined tool identifier. In this way, the MCP tools in the tool list can be uniquely identified using this combined tool identifier, thereby helping the pre-trained language model effectively distinguish between various tools. This solves the technical problems of tool naming conflicts and call confusion in multi-service environments, prevents cross-service tool overwriting, reduces the invocation of forged or tampered tools, reduces the risk of tool shadow attacks, lowers the possibility of legitimate operation flows being maliciously hijacked, and improves system security and execution reliability.

[0059] In some embodiments, the MCP service may be verified to determine its trustworthiness before obtaining publisher information from it. If the MCP service is trustworthy, the publisher information is obtained from it.

[0060] In another embodiment, the above method may further include: 108. Obtain the first service content and the first digital signature of the MCP service from the MCP service.

[0061] 110. Use the first digital signature to verify the signature of the first service content.

[0062] 112. Based on the signature verification result, determine whether the MCP service is trustworthy.

[0063] Accordingly, "assigning a unique identifier to the MCP service based on the publisher information" in section 102 above may include: 1021. When the MCP service is trusted, a unique identifier is assigned to the MCP service based on the publisher information.

[0064] When an MCP service is untrusted, it is ignored. That is, a unique identifier is no longer assigned to it, and the MCP tools provided by that MCP service are not added to the tool list.

[0065] In step 108 above, the security proxy module can send a signature retrieval request to the MCP service. After receiving the signature retrieval request, the MCP service sends the first service content and the first digital signature of the MCP service to the security proxy module. In practical applications, before publishing the MCP service, the publisher generates a digest of the service content of the MCP service using a preset hash function, and then encrypts the digest using a private key to obtain the first digital signature.

[0066] The first service content may include: service code and / or tool description information.

[0067] In step 110 above, the first digital signature is decrypted using the public key of the MCP service to obtain a first digest; a second digest of the first service content is generated using a preset hash function; when the first digest and the second digest are consistent, the verification is determined to be successful; when the first digest and the second digest are inconsistent, the verification is determined to be unsuccessful.

[0068] The public key for the MCP service is published by the publisher of the MCP service through certain channels.

[0069] The aforementioned preset hash function can be negotiated in advance between the MCP client and the MCP service.

[0070] If the first and second digests are identical, it indicates that the MCP service was not tampered with by an attacker after the publisher released it. If the first and second digests are inconsistent, it indicates that the MCP service was tampered with by an attacker after the publisher released it.

[0071] In some embodiments of 112 above, if the signature verification passes, the MCP service is determined to be trustworthy; if the signature verification fails, the MCP service is determined to be untrustworthy.

[0072] In other embodiments, further judgments may be made after signature verification.

[0073] In some specific implementations, the step 112 above, "determining whether the MCP service is trustworthy based on the signature verification result," can be achieved using the following steps: 1120. If the signature verification passes, the digital signature record of the MCP service is obtained from the immutable data source.

[0074] 1121. When the digital signature record includes the first digital signature, the MCP service is determined to be trustworthy.

[0075] 1122. When the digital signature record does not include the first digital signature, the MCP service is determined to be untrustworthy.

[0076] In practical applications, successful signature verification demonstrates that the MCP service has not been tampered with by an attacker after its publication, but it cannot verify the publisher's trustworthiness. Therefore, publishers can be required to store their publisher information and the digital signature of the published or updated MCP service on an immutable data source after publishing or updating the service, forming a digital signature record. In other words, the digital signature record includes the publisher's publisher information and the digital signatures of the published MCP service under different versions. The digital signatures of the same MCP service will differ across different versions. Once stored in this immutable data source, the data cannot be tampered with. For example, an immutable data source could include a blockchain.

[0077] Therefore, after the above signature verification is successful, the digital signature record of the publisher of the MCP service can be obtained from an immutable data source based on the publisher's publisher information. When the digital signature record includes the first digital signature, it indicates that the digital signature of the current version of the MCP service has been recorded by the publisher on an immutable data source. Therefore, the publisher is also trustworthy, and the current version of the MCP service is trustworthy.

[0078] When the first digital signature is not included in the digital signature record, it means that the publisher did not leave a record on the immutable data source after publishing the current version of the MCP service. Therefore, the publisher is considered untrustworthy, and the MCP service published by the publisher is also untrustworthy.

[0079] In the embodiments described in this specification, technologies such as digital signatures and blockchain can be used to determine that the MCP service is published by a legitimate publisher and has not been tampered with. This reduces the probability of adding MCP tools provided by untrusted MCP services to the tool list, thereby improving the overall security of the system.

[0080] In some other specific implementations, the first service content includes: tool description information. The step 112 above, "determining whether the MCP service is trustworthy based on the signature verification result," can be implemented using the following steps: 1123. If the signature verification is successful, the second pre-trained language model is used to perform semantic recognition on the tool description information, and a first risk recognition result is generated based on the semantic recognition result.

[0081] 1124. When the first risk identification result does not meet the preset requirements, the MCP service is determined to be untrustworthy.

[0082] 1125. When the first risk identification result meets the preset requirements, the MCP service is determined to be trustworthy.

[0083] The second pre-trained language model can be the same language model as the first pre-trained language model, or they can be different language models. In some embodiments, the second pre-trained language model can be obtained by fine-tuning the pre-trained language model based on the collected attack corpus. Tool description information can be input into the second pre-trained language model so that the second pre-trained language model can perform semantic recognition on the tool description information and generate a first risk identification result based on the semantic recognition result.

[0084] The above preset requirements can be set according to actual needs, and the embodiments in this specification do not impose specific limitations on them.

[0085] For example, the risk identification result may include a risk score. When the risk score is greater than or equal to a preset scoring threshold, the MCP service is determined to be untrustworthy. When the risk score is less than the preset scoring threshold, the MCP service is determined to be trustworthy.

[0086] In the embodiments of this specification, semantic understanding of the tool description information enables the identification of covert attack content within the tool description information, such as covert attack instructions described in natural language or malicious executable code blocks. Semantic scanning can effectively identify whether an MCP service is trustworthy.

[0087] The above embodiments describe the security protection operations performed when a new MPC tool is added to the tool list. The following describes how this solution performs security protection during tool invocation. The above method may also include: 114. Obtain the tool call request sent by the MCP client.

[0088] The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool.

[0089] 116. Perform risk verification based on the tool call request.

[0090] 118. Based on the risk verification results, determine whether to forward the tool call request to the target MCP service that provides the target MCP tool.

[0091] In 114 above, the MCP client can receive user queries input by the user and send the user query and the tool list maintained by the MCP client to the first pre-trained language model, so that the first pre-trained language model can generate tool call instructions based on the user query and the tool list maintained by the MCP client.

[0092] The MCP client generates a tool invocation request based on the tool invocation instruction.

[0093] In section 116 above, after receiving the tool invocation request, risk verification can be performed on the tool invocation request, and / or on the target MCP service. Risk verification of the tool invocation request is performed to determine if there is any malicious content in the request. Risk verification of the target MCP service is performed to determine if the target MCP service is trustworthy.

[0094] When the tool is invoked, the target MCP service is verified for trustworthiness, which can prevent silent redefinition attacks (RugPull).

[0095] In step 118 above, if the risk verification of the tool invocation request itself passes and / or the trust verification of the target MCP service passes, the tool invocation request is forwarded to the target MCP service that provides the target MCP tool. Otherwise, the tool invocation request is discarded / rejected.

[0096] In the technical solution provided in this embodiment, risk verification is performed every time the tool is called, which can effectively enhance the security of the system.

[0097] In some embodiments, the "performing risk verification based on the tool invocation request" in step 116 above can be implemented using the following steps: 1160. Using the second pre-trained language model, perform intent recognition on the tool call request, and generate risk verification results based on the intent recognition results.

[0098] The tool call request is input into a second pre-trained language model, which then performs intent recognition on the tool call request and generates a risk verification result, such as a risk score, based on the intent recognition result.

[0099] When the risk score is higher than the preset score threshold, the tool call request is rejected.

[0100] When the risk score is lower than the preset score threshold, a tool invocation request is sent to the target MCP service that provides the target MCP tool.

[0101] In some embodiments, the "performing risk verification based on the tool invocation request" in step 116 above can be implemented using the following steps: 1161. Obtain the preset risk rules.

[0102] 1162. Using the risk rules, determine whether the tool call request involves a high-risk operation.

[0103] In section 1161 above, the preset risk rules include: predefined high-risk operations. For example: file system writing, code execution, etc.

[0104] In step 1162 above, the request content of the tool invocation request is compared with the risk rules. If a risk rule is matched, the tool invocation request is determined to involve a high-risk operation; if no risk rule is matched, the tool invocation request is determined not to involve a high-risk operation. High-risk operations may include API key access, database writing, etc.

[0105] In some embodiments, step 118 above, "determining whether to forward the tool invocation request to the target MCP service that provides the target MCP tool based on the risk verification result," can be implemented using the following steps: 1180. When a tool request involves a high-risk operation, a user confirmation screen should be displayed.

[0106] 1181. In response to the user's confirmation operation on the user confirmation interface, send the tool invocation request to the target MCP service that provides the target MCP tool.

[0107] 1182. In response to the user's rejection operation on the user confirmation interface, reject the tool call request.

[0108] The user confirmation interface displays detailed information about the high-risk operation. This detailed information may include: the combined tool identifier of the MCP tools involved in the high-risk operation, the content of the high-risk operation, and the permissions required for the operation.

[0109] The user confirmation interface may further include a confirmation control and a rejection control. In response to a user's action on the confirmation control, a tool invocation request is sent to the target MCP service providing the target MCP tool. In response to a user's action on the rejection control, the tool invocation request is rejected.

[0110] In practical applications, risk rules can only record and filter high-risk operations with risk levels higher than the preset level. This can reduce the number of pop-up windows and avoid user fatigue and misjudgment caused by indiscriminate pop-ups.

[0111] In this embodiment, risk verification is performed on the request content of the tool invocation request to improve system security.

[0112] In some embodiments, the risk verification result includes whether the target MCP service is trustworthy. The "performing risk verification based on the tool invocation request" in section 116 above can be implemented using the following steps: 1163. Obtain the second service content and second digital signature of the target MCP service from the target MCP service.

[0113] 1164. Use the second digital signature to verify the signature of the second service content.

[0114] 1165. If the verification is successful, the digital signature record information of the target MCP service is obtained from the immutable data source.

[0115] 1166. When the second digital signature is recorded in the digital signature record information, the target MCP service is determined to be trustworthy.

[0116] 1167. When the second digital signature is not recorded in the digital signature record information, the target MCP service is determined to be untrustworthy.

[0117] The specific implementation of steps 1163 to 1167 above can be found in the corresponding contents of the above embodiments, and will not be repeated here.

[0118] In this embodiment, when the tool is invoked, the target MCP service to be invoked is verified to be trusted, which can identify silent redefinition attacks and thus improve system security.

[0119] In practical applications, some MCP services inject dangerous commands into their returned results. Therefore, the above methods may also include: 120. Receive the return result returned by the MCP service after it is invoked.

[0120] 122. Using the second pre-trained language model, perform intent recognition on the returned results, and generate a second risk recognition result based on the intent recognition result.

[0121] 124. When the second risk identification result meets the preset requirements, send the returned result to the MCP client.

[0122] In the above 120, the MCP service can execute a tool call request after receiving it, obtain the execution result (i.e., the return result), and return the execution result to the security proxy module.

[0123] In step 122 above, the returned result is input into the second pre-trained language model so that the second pre-trained language model can perform intent recognition on the returned result and generate a second risk recognition result based on the intent recognition result.

[0124] In step 124 above, when the second risk identification result meets the preset requirements, the return result is sent to the MCP client. In this way, the MCP client can send the return result to the first pre-trained language model, so that the first pre-trained language model can generate response information to be fed back to the user or make subsequent decisions based on the return result, such as generating the next tool call instruction.

[0125] In some embodiments, the operation logs of the MCP client can be analyzed based on Long Short-Term Memory (LSTM) networks to identify abnormal patterns such as high-frequency cross-namespace access and a sudden increase in the proportion of high-risk operations, providing real-time alerts and blocking suspicious behaviors. The operation logs include tool call requests sent to the MCP service. These operation logs can be recorded on an immutable data source, such as a blockchain, to support post-event auditing and attack attribution.

[0126] To further enhance system security, the MCP service can be run in a sandbox environment. This sandbox environment can be an isolated sandbox built on WebAssembly (WASM). Direct system calls (such as file deletion and network access) are prohibited within the sandbox, and high-risk operations (such as database writes) are only allowed to be relayed through a secure proxy service. Sandbox resources are limited, including memory limits and CPU time slice control, to prevent resource exhaustion attacks.

[0127] In other words, when a tool invocation request is determined to involve a high-risk operation and the user confirms the high-risk operation through a confirmation interface, the security proxy module can forward the tool invocation request to the security proxy service, which will then execute the request. Upon receiving the request, the security proxy service records a complete operation log to immutable storage (such as a blockchain), supporting post-event auditing and attack tracing.

[0128] Furthermore, upon receiving the request, the security proxy service can determine whether the MCP client's current access pattern matches the LSTM-predicted access pattern. If the current access pattern does not match the LSTM-predicted access pattern, an alert is issued and the tool invocation request is blocked. If the current access pattern matches the LSTM-predicted access pattern, the tool invocation request is processed. The LSTM-predicted access pattern can include the request frequency of high-risk operations; if the current request frequency of high-risk operations is higher than the LSTM-predicted request frequency, the tool invocation request is rejected.

[0129] In some embodiments, before determining to send the tool invocation request to the target MCP service providing the target MCP tool, the MCP client may add a dynamic token obtained from an authorization server to the tool invocation request. This dynamic token carries the permission scope. Thus, upon receiving the tool invocation request, the MCP service can verify the dynamic token to authenticate the MCP client and control access.

[0130] An OAuth 2.1-based authorization mechanism can be adopted. When a client first accesses the MCP service, it needs to dynamically register with the authorization server and obtain a client ID and authorization code. After the user agrees to authorization, the authorization code is exchanged for an access token. This token has short-term validity, typically used for single calls or short-term validity. The short-term token verifies the client's legitimate identity and prevents unauthorized calls. The token carries the scope of permissions, and the server opens corresponding tools based on the permissions. The dynamic generation and short-term validity mechanism reduces the risk of credential leakage. The client needs to register with the authorization server and obtain temporary credentials on the first request. Short-term tokens need to be re-obtained before expiration, and an automatic refresh mechanism is supported.

[0131] This mechanism ensures both the security and flexibility of tool invocation.

[0132] Figure 4 This is a flowchart illustrating the communication method based on the MCP protocol provided in the embodiments of this specification. The execution entity of this method can be... Figure 2 The security proxy module in [the context of the project]. The security proxy module can be a software-based and / or hardware-based module. For example... Figure 4 As shown, the method includes: 400. Obtain the tool call request sent by the MCP client.

[0133] The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool.

[0134] 402. Using the second pre-trained language model, perform intent recognition on the tool call request, and generate risk verification results based on the intent recognition results.

[0135] 404. Based on the risk verification result, determine whether to forward the tool call request to the target MCP service.

[0136] The specific implementation of steps 400 to 404 can be found in the corresponding contents of the above embodiments, and will not be repeated here.

[0137] It should be noted that any steps in the methods provided in the embodiments of this specification that are not fully described in detail can be found in the corresponding content of the above embodiments, and will not be repeated here. Furthermore, the methods provided in the embodiments of this specification may include other parts or all of the steps in the above embodiments in addition to the steps described above; for details, please refer to the corresponding content of the above embodiments, and will not be repeated here.

[0138] Figure 5 This is a flowchart illustrating the communication method based on the MCP protocol provided in the embodiments of this specification. The execution entity of this method can be... Figure 2 The security proxy module in [the context of the project]. The security proxy module can be a software-based and / or hardware-based module. For example... Figure 5 As shown, the method includes: 500. Obtain the tool call request sent by the MCP client.

[0139] The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool.

[0140] 502. Obtain the second service content and second digital signature of the target MCP service from the target MCP service.

[0141] 504. Use the second digital signature to verify the signature of the second service content.

[0142] 506. When the verification is successful, forward the tool invocation request to the target MCP service.

[0143] 508. If the verification fails, the tool call request is rejected.

[0144] The specific implementation of steps 500 to 508 can be found in the corresponding contents of the above embodiments, and will not be repeated here.

[0145] In some embodiments, the step 506 above, "when verification is successful, forward the tool invocation request to the target MCP service," can be implemented using the following steps: 5060. If the verification is successful, the digital signature record information of the target MCP service is obtained from the tamper-proof data source.

[0146] 5062. When the second digital signature is recorded in the digital signature record information, send the tool invocation request to the target MCP service.

[0147] The tool call request is rejected if the second digital signature is not recorded in the digital signature record information.

[0148] The specific implementation of steps 5060 and 5062 can be found in the corresponding contents of the above embodiments, and will not be repeated here.

[0149] It should be noted that any steps in the methods provided in the embodiments of this specification that are not fully described in detail can be found in the corresponding content of the above embodiments, and will not be repeated here. Furthermore, the methods provided in the embodiments of this specification may include other parts or all of the steps in the above embodiments in addition to the steps described above; for details, please refer to the corresponding content of the above embodiments, and will not be repeated here.

[0150] Figure 6 This is a flowchart illustrating the communication method based on the MCP protocol provided in the embodiments of this specification. The execution entity of this method can be... Figure 2 The security proxy module in [the context of the project]. The security proxy module can be a software-based and / or hardware-based module. For example... Figure 6 As shown, the method includes: 600. Obtain the tool call request sent by the MCP client.

[0151] The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool.

[0152] 602. Forward the tool invocation request to the target MCP service.

[0153] 604. Receive the return result of the target MCP service in response to the tool call request.

[0154] 606. Using the second pre-trained language model, perform intent recognition on the returned result, and generate a second risk recognition result based on the intent recognition result.

[0155] 608. When the second risk identification result meets the preset requirements, send the return result to the MCP client.

[0156] 610. If the second risk identification result does not meet the preset requirements, discard the returned result.

[0157] The specific implementation of steps 600 to 610 can be found in the corresponding contents of the above embodiments, and will not be repeated here.

[0158] It should be noted that any steps in the methods provided in the embodiments of this specification that are not fully described in detail can be found in the corresponding content of the above embodiments, and will not be repeated here. Furthermore, the methods provided in the embodiments of this specification may include other parts or all of the steps in the above embodiments in addition to the steps described above; for details, please refer to the corresponding content of the above embodiments, and will not be repeated here.

[0159] The following is in conjunction with the appendix Figures 7-8 The technical solutions provided in the embodiments of this specification will be described in detail. Figure 7 This demonstrates the process of adding an MCP service to an MCP client.

[0160] 11. The user enters the command to add the MCP service into the MCP client.

[0161] Upon receiving this instruction, the MCP client triggers the security proxy model to execute the following steps.

[0162] 12. The security proxy model obtains the publisher information of the MCP service.

[0163] Publisher information may include the publisher's organizational identity information, such as the organization name.

[0164] 13. The security proxy model obtains the first service content and the first digital signature.

[0165] The first service includes the service code for the MCP service and tool description information.

[0166] 14. The security proxy model performs signature verification.

[0167] The first service content is verified using a first digital signature. The specific signature verification process can be found in the corresponding content of the above embodiments, and will not be repeated here. The purpose of signature verification is to confirm whether the MCP service has been tampered with by an attacker after its release.

[0168] If the signature verification passes, proceed to step 15; otherwise, terminate the process of adding the MCP service. Optionally, the user can be notified of the reason for the failure before terminating the process of adding the MCP service.

[0169] 15. The security proxy model obtains the digital signature record of the MCP service from the blockchain.

[0170] Once it is confirmed that the MCP service has not been tampered with by attackers after its release, it is then confirmed whether the publisher left a record on the blockchain after releasing the MCP service.

[0171] 16. The security proxy model determines whether the MCP service is trustworthy.

[0172] If the digital signature record of the MCP service obtained from the blockchain contains the first digital signature, it indicates whether the publisher left a record on the blockchain after publishing the MCP service. Therefore, the publisher can be considered trustworthy, and the MCP service published by the publisher is trustworthy.

[0173] If the MCP service is determined to be trustworthy, proceed to step 17; otherwise, terminate the process of adding the MCP service. Optionally, the user may be notified of the reason for the failure before terminating the process of adding the MCP service.

[0174] 17. The security agent model allocates a unique namespace for the MCP service based on the publisher information.

[0175] For example, the publisher's organization name can be combined with the service name of the MCP service to obtain a unique namespace.

[0176] 18. The security proxy model adds a unique namespace as a prefix before the tool identifier of the MCP tool to obtain the combined tool identifier.

[0177] The security proxy model can obtain the tool identifier of the MCP tool from the tool description information of the MCP service, add the unique namespace as a prefix before the tool identifier of the MCP tool to obtain the combined tool identifier, replace the tool identifier recorded in the tool description information of the MCP service with the combined tool identifier, and send the updated tool description information to the MCP client.

[0178] 19. The MCP client adds the MCP tool to the tool list based on the combined tool identifier.

[0179] Based on the updated tool description information, the MCP client adds the combined tool identifier and tool description of the MCP tools to the tool list.

[0180] 20. Notify the user that the addition was successful.

[0181] In the embodiments described in this specification, the process of adding an MCP tool provided by a new MCP service to the tool list is actively triggered by the user. Optionally, when the MCP service corresponding to an MCP tool already added to the tool list is updated or upgraded, the MCP tool for that MCP service can also be updated in the tool list according to steps 12-19 above. For example, the MCP tool for the previous MCP service can be deleted from the tool list first, and then the updated MCP tool for the previous MCP service can be added to the tool list according to steps 12-19 above.

[0182] Figure 8 The tool invocation process is demonstrated. For example... Figure 8As shown, the process includes the following steps: 21. The user enters a user query into the MCP client.

[0183] 22. The MCP client sends user queries and tool lists to the LLM.

[0184] 23. LLM returns the tool call command.

[0185] LLM generates tool invocation instructions based on user queries and tool lists.

[0186] 24. MCP client generates tool call request.

[0187] The MCP client generates tool invocation requests based on tool invocation instructions.

[0188] 25. The MCP client sends a tool call request to the security agent module.

[0189] 26. The security proxy module performs risk verification on tool call requests.

[0190] Risk verification can be achieved through semantic recognition and risk rule comparison.

[0191] If the risk verification passes, proceed to step 27; otherwise, reject the request.

[0192] 27. The security proxy module obtains the second digital signature and the second service content from the MCP service.

[0193] The MCP service is the MCP service requested by the tool invocation request, wherein the second service content includes the service code and tool description information.

[0194] 28. The security proxy module performs digital signature verification.

[0195] The second digital signature is used to verify the signature of the second service content in order to determine whether the MCP service has been tampered with by an attacker.

[0196] If the verification passes, proceed to step 29; otherwise, reject the request.

[0197] 29. The security proxy module obtains the digital signature record of the MCP service from the blockchain.

[0198] The digital signature record can contain the digital signatures of the MCP service under different versions.

[0199] 30. The security agent module performs blockchain record comparison.

[0200] Determine whether the second digital signature is recorded in the digital signature record. If it is, the comparison passes; otherwise, the comparison fails.

[0201] If the comparison is successful, proceed to step 31; otherwise, reject the request.

[0202] 31. The security agent module determines whether there are high-risk operations.

[0203] If it exists, proceed to step 32; otherwise, proceed to step 33. 32. The security agent model interacts with the user for secondary confirmation.

[0204] The security agent model can display a secondary confirmation interface, which shows detailed information about high-risk operations for users to make a judgment.

[0205] 33. The security proxy module forwards requests to the MCP service.

[0206] The MCP service executes the request and returns the result.

[0207] 34. The security proxy module determines whether the user has permission.

[0208] The security proxy module determines whether the user has entered permission on the secondary confirmation screen.

[0209] If the user allows it, proceed to step 35. Otherwise, reject the request.

[0210] 35. The security proxy module forwards requests to the security proxy service.

[0211] The security proxy service executes the request and receives the returned result.

[0212] 36. The MCP service returns the result to the security agent module.

[0213] 37. The security proxy service returns the result to the security proxy module.

[0214] 38. The security proxy module performs risk verification on the returned results.

[0215] Semantic understanding can be used to perform risk verification on the returned results.

[0216] If the verification passes, step 39 will be executed; otherwise, the returned result will be discarded.

[0217] 39. Return.

[0218] In practical applications, upon receiving the request, the security proxy service determines whether the MCP client's current access pattern matches the LSTM-based prediction pattern. If the current access pattern does not match the LSTM-based prediction pattern, an alert is issued and the tool invocation request is blocked; otherwise, the request is executed. LSTM prediction can be performed based on the MCP client's operation logs. The MCP client's operation logs record the tool invocation requests received by the security proxy service.

[0219] In summary, the technical solutions provided in this specification propose isolating tool identifiers through a global namespace to ensure the dynamism and security of tool calls, preventing attackers from achieving unauthorized operations (such as tool shadow attacks) by adding new tools or overwriting tools with the same name; using a context-aware semantic scanning model based on a pre-trained language model (such as BERT) to analyze the semantic logic of tool descriptions and identify malicious instructions hidden in natural language, overcoming the limitations of traditional rule matching and effectively defending against variant attacks and hidden content poisoning (such as Shell command injection described in natural language); and combining tool version change records with digital signatures and storing them in a private blockchain network to achieve tamper-proof traceability of version history, and ensuring the integrity of tool definitions through client signature verification. This approach prevents attackers from launching long-term, latent attacks through "silent redefinition" (such as hiding high-risk changes when upgrading tools), ensuring that tool version changes are transparent and trustworthy. It proposes dynamic confirmation rules based on risk levels, triggering secondary user confirmation only for high-risk operations (such as file deletion and code execution), and displaying operation details (initiator, target operation, and permission requirements). This avoids user fatigue and misjudgment caused by traditional indiscriminate pop-ups, improving the accuracy of user authorization and their right to know. Furthermore, by utilizing LSTM networks to analyze the temporal characteristics of operation logs (such as cross-namespace access frequency and the proportion of sensitive operations), it automatically identifies abnormal behavior patterns (such as sudden high-frequency deletion requests), reducing reliance on manual intervention, proactively defending against permission abuse and attack propagation, and mitigating the potential risks of user error.

[0220] This specification provides an embodiment of a communication device based on the MCP protocol, comprising: The acquisition module is used to obtain information about the publisher of the MCP service; The allocation module is used to allocate a unique identifier to the MCP service based on the publisher information; The combination module is used to combine the unique identifier with the tool identifier of the MCP tool provided by the MCP service to obtain the combined tool identifier. An add module is used to add the MCP tool to the tool list based on the combined tool identifier; The tool list is used to record the MCP tools that the first pre-trained language model can call.

[0221] Another embodiment of this specification provides a communication device based on the MCP protocol, comprising: The acquisition module is used to acquire tool call requests sent by the MCP client. The tool call request is generated by the MCP client based on the tool call instruction output by the first pre-trained language model. The tool call instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool call request is used to request the invocation of the target MCP tool. The identification module is used to identify the intent of the tool call request using a second pre-trained language model, and generate a risk verification result based on the intent identification result. The determination module is used to determine, based on the risk verification result, whether to forward the tool call request to the target MCP service.

[0222] Another embodiment of this specification provides a communication device based on the MCP protocol, comprising: The first acquisition module is used to acquire a tool call request sent by the MCP client. The tool call request is generated by the MCP client based on the tool call instruction output by the first pre-trained language model. The tool call instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool call request is used to request the invocation of the target MCP tool. The second acquisition module is used to acquire the second service content and the second digital signature of the target MCP service from the target MCP service. The verification module is used to verify the signature of the second service content using the second digital signature; The forwarding module is used to forward the tool call request to the target MCP service when the verification is successful; The rejection module is used to reject the tool call request when the verification fails.

[0223] Another embodiment of this specification provides a communication device based on the MCP protocol, comprising: The acquisition module is used to acquire tool call requests sent by the MCP client. The tool call request is generated by the MCP client based on the tool call instruction output by the first pre-trained language model. The tool call instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool call request is used to request the invocation of the target MCP tool. The forwarding module is used to forward the tool invocation request to the target MCP service; A receiving module is used to receive the return result of the target MCP service in response to the tool invocation request; The identification module is used to perform intent identification on the returned result using a second pre-trained language model, and generate a second risk identification result based on the intent identification result; The sending module is used to send the return result to the MCP client when the second risk identification result meets the preset requirements; The discard module is used to discard the returned result when the second risk identification result does not meet the preset requirements.

[0224] It should be noted that the devices provided in the above embodiments can implement the technical solutions described in the corresponding method embodiments above. The specific implementation principles and corresponding beneficial effects of the above modules or units can be found in the corresponding content of the above method embodiments, and will not be repeated here.

[0225] This specification also provides an electronic device according to one embodiment. For example... Figure 9 As shown, the electronic device includes a processor 42 and a memory 41. The memory 41 stores one or more computer programs (or instructions); the processor 42 is coupled to the memory 41 and is used for the at least one or more computer programs to implement the steps in the methods provided in the embodiments of this specification.

[0226] Furthermore, the electronic device also includes other components such as a communication component 43, a display 44, a power supply component 45, and an audio component 46. Only some components are shown here for illustrative purposes, and it is not intended that the electronic device contains only these components.

[0227] The methods in this specification can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, as a computer program product. Therefore, this specification also provides a computer program product. This computer program product includes a computer program / instructions that, when executed by an electronic component such as a processor, can perform, in whole or in part, the steps or functions of the methods provided in the embodiments of this specification. The computer can be a general-purpose computer, a special-purpose computer, a computer network, network equipment, user equipment, core network equipment, or other programmable device.

[0228] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0229] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0230] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0231] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0232] Accordingly, embodiments of this specification also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium.

[0233] Accordingly, embodiments of this specification also provide a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above-described method embodiments. It should be understood that each step or combination of steps in the above-described method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above-described method embodiments.

[0234] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0235] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for embodiments such as devices, electronic devices, storage media, and program products, since they are basically similar to the method embodiments, the descriptions are relatively simple, and relevant parts can be referred to the descriptions of the method embodiments.

[0236] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0237] The above are merely embodiments of this specification and are not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this application.

Claims

1. A communication method based on the MCP protocol, characterized in that, include: Obtain information about the publisher of MCP services; A unique identifier is assigned to the MCP service based on the publisher information; The unique identifier is combined with the tool identifier of the MCP tool provided by the MCP service to obtain the combined tool identifier; Based on the combined tool identifier, add the MCP tool to the tool list; The tool list is used to record the MCP tools that the first pre-trained language model can call.

2. The method according to claim 1, characterized in that, Also includes: Obtain the first service content and the first digital signature of the MCP service from the MCP service; The first service content is verified by using the first digital signature; Based on the signature verification result, determine whether the MCP service is trustworthy; Based on the publisher information, a unique identifier is assigned to the MCP service, including: When the MCP service is trusted, a unique identifier is assigned to the MCP service based on the publisher information.

3. The method according to claim 2, characterized in that, Using the first digital signature to verify the service content includes: The first digital signature is decrypted using the public key of the MCP service to obtain the first digest; A second digest of the first service content is generated using a preset hash function; When the first digest and the second digest are consistent, the verification is deemed successful; If the first digest and the second digest are inconsistent, the verification is determined to fail.

4. The method according to claim 2, characterized in that, Determining the trustworthiness of the MCP service based on the signature verification result includes: If the signature verification passes, the digital signature record of the MCP service is obtained from the immutable data source; When the digital signature record includes the first digital signature, the MCP service is deemed trustworthy. When the first digital signature is not included in the digital signature record, the MCP service is determined to be untrustworthy.

5. The method according to claim 2, characterized in that, Determining the trustworthiness of the MCP service based on the signature verification result includes: If the signature verification fails, the MCP service is deemed untrustworthy.

6. The method according to any one of claims 1 to 5, characterized in that, Also includes: Obtain a tool invocation request sent by the MCP client. The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool. Based on the tool call request, a risk verification is performed; Based on the risk verification results, determine whether to forward the tool invocation request to the target MCP service that provides the target MCP tool.

7. The method according to claim 6, characterized in that, Based on the tool invocation request, risk verification is performed, including: Using a second pre-trained language model, the intent of the tool call request is identified, and a risk verification result is generated based on the intent identification result.

8. The method according to claim 6, characterized in that, Based on the tool invocation request, risk verification is performed, including: Obtain the preset risk rules; Using the aforementioned risk rules, determine whether the tool invocation request involves a high-risk operation; And, based on the risk verification results, determine whether to forward the tool invocation request to the target MCP service that provides the target MCP tool, including: When a tool call request involves a high-risk operation, a user confirmation interface is displayed, which shows the operation details of the high-risk operation. In response to the user's confirmation operation on the user confirmation interface, a tool invocation request is sent to the target MCP service that provides the target MCP tool; In response to the user's rejection action on the user confirmation interface, the tool invocation request is rejected.

9. The method according to claim 6, characterized in that, The risk verification result includes whether the target MCP service is trustworthy; Based on the tool invocation request, risk verification is performed, including: Obtain the second service content and second digital signature of the target MCP service from the target MCP service; The second digital signature is used to verify the signature of the second service content; If the verification is successful, the digital signature record information of the target MCP service is obtained from the immutable data source; When the second digital signature is recorded in the digital signature record information, the target MCP service is determined to be trustworthy; When the second digital signature is not recorded in the digital signature record information, the target MCP service is determined to be untrustworthy.

10. The method according to any one of claims 1 to 5, characterized in that, Also includes: Receive the return result returned by the MCP service after it is invoked; Using a second pre-trained language model, the returned result is subjected to intent recognition, and a second risk recognition result is generated based on the intent recognition result; When the second risk identification result meets the preset requirements, the return result is sent to the MCP client.

11. The method according to any one of claims 1 to 5, characterized in that, The unique identifier is combined with the tool identifier of the MCP tool provided by the MCP service to obtain the combined tool identifier, which includes: The unique identifier is added as a prefix before the tool identifier of the MCP tool to obtain the combined tool identifier.

12. A communication method based on the MCP protocol, characterized in that, include: Obtain a tool invocation request sent by the MCP client. The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool. Using a second pre-trained language model, the intent of the tool call request is identified, and a risk verification result is generated based on the intent identification result. Based on the risk verification result, determine whether to forward the tool call request to the target MCP service.

13. A communication method based on the MCP protocol, characterized in that, include: Obtain a tool invocation request sent by the MCP client. The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool. Obtain the second service content and second digital signature of the target MCP service from the target MCP service; The second digital signature is used to verify the signature of the second service content; When the verification is successful, the tool invocation request is forwarded to the target MCP service; If the verification fails, the tool call request is rejected.

14. The method according to claim 13, characterized in that, When verification is successful, the tool invocation request is forwarded to the target MCP service, including: If the verification is successful, the digital signature record information of the target MCP service is obtained from the immutable data source; When the second digital signature is recorded in the digital signature record information, the tool invocation request is sent to the target MCP service; The method further includes: The tool call request is rejected if the second digital signature is not recorded in the digital signature record information.

15. A communication method based on the MCP protocol, characterized in that, include: Obtain a tool invocation request sent by the MCP client. The tool invocation request is generated by the MCP client based on the tool invocation instruction output by the first pre-trained language model. The tool invocation instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool invocation request is used to request the invocation of the target MCP tool. Forward the tool invocation request to the target MCP service; Receive the return result from the target MCP service in response to the tool invocation request; Using a second pre-trained language model, the returned result is subjected to intent recognition, and a second risk recognition result is generated based on the intent recognition result; When the second risk identification result meets the preset requirements, the return result is sent to the MCP client; If the second risk identification result does not meet the preset requirements, the returned result is discarded.

16. A communication device based on the MCP protocol, characterized in that, include: The acquisition module is used to obtain information about the publisher of the MCP service; The allocation module is used to allocate a unique identifier to the MCP service based on the publisher information; The combination module is used to combine the unique identifier with the tool identifier of the MCP tool provided by the MCP service to obtain the combined tool identifier. An add module is used to add the MCP tool to the tool list based on the combined tool identifier; The tool list is used to record the MCP tools that the first pre-trained language model can call.

17. A communication device based on the MCP protocol, characterized in that, include: The acquisition module is used to acquire tool call requests sent by the MCP client. The tool call request is generated by the MCP client based on the tool call instruction output by the first pre-trained language model. The tool call instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool call request is used to request the invocation of the target MCP tool. The identification module is used to identify the intent of the tool call request using a second pre-trained language model, and generate a risk verification result based on the intent identification result. The determination module is used to determine, based on the risk verification result, whether to forward the tool call request to the target MCP service.

18. A communication device based on the MCP protocol, characterized in that, include: The first acquisition module is used to acquire a tool call request sent by the MCP client. The tool call request is generated by the MCP client based on the tool call instruction output by the first pre-trained language model. The tool call instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool call request is used to request the invocation of the target MCP tool. The second acquisition module is used to acquire the second service content and the second digital signature of the target MCP service from the target MCP service. The verification module is used to verify the signature of the second service content using the second digital signature; The forwarding module is used to forward the tool call request to the target MCP service when the verification is successful; The rejection module is used to reject the tool call request when the verification fails.

19. A communication device based on the MCP protocol, characterized in that, include: The acquisition module is used to acquire tool call requests sent by the MCP client. The tool call request is generated by the MCP client based on the tool call instruction output by the first pre-trained language model. The tool call instruction is generated by the first pre-trained language model based on the user query and the tool list. The tool call request is used to request the invocation of the target MCP tool. The forwarding module is used to forward the tool invocation request to the target MCP service; A receiving module is used to receive the return result of the target MCP service in response to the tool invocation request; The identification module is used to perform intent identification on the returned result using a second pre-trained language model, and generate a second risk identification result based on the intent identification result; The sending module is used to send the return result to the MCP client when the second risk identification result meets the preset requirements; The discard module is used to discard the returned result when the second risk identification result does not meet the preset requirements.

20. An electronic device, characterized in that, include: Memory and processor, among which, The memory is used to store programs; The processor, coupled to the memory, is configured to execute the program stored in the memory to implement the method of any one of claims 1 to 15.

21. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a computer, it can implement the method of any one of claims 1 to 15.

22. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 15.

Images