Data processing method and device

Abstract

The embodiment of the invention discloses a data processing method and device. A client request sent by a client is received, the client request is analyzed, request types are determined, target servers are determined based on the request types, the client request is sent to the target servers, and response messages returned by the target servers are obtained. And generating a feedback result according to the response message and sending the feedback result to the client. Therefore, the MCP proxy gateway can be used as a communication bridge between the client and the MCP server, and the client only needs to establish connection with the MCP proxy gateway, so that the network resource overhead and management burden of the client are reduced.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a data processing method and apparatus. Background Technology

[0002] With the rapid development of Large Language Model (LLM) technology, Model Context Protocol (MCP) is becoming increasingly important as a standard protocol for connecting AI (Artificial Intelligence) models with external data sources and tools. It can effectively extend model capabilities and is a key infrastructure for building complex AI applications.

[0003] Currently, a common approach to implementing MCP functionality is for the client to establish and maintain independent network connections with multiple MCP servers. Under this architecture, the client needs to individually send requests to each required service and process the responses. However, this method requires the client to maintain multiple long-lived connections equal to the number of services, resulting in significant network resource overhead and management burden. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a data processing method and apparatus that can reduce the network resource overhead and management burden on the client.

[0005] In a first aspect, embodiments of the present invention provide a data processing method, the method comprising: Receive client requests sent by the client; The client request is parsed and the request type is determined, including tool invocation requests and capability discovery requests. Determine the target server based on the request type; Send the client request to the target server; Receive response messages sent by each of the target servers; A feedback result is generated based on the response message and sent to the client.

[0006] In some embodiments, determining the target server based on the request type includes: In response to the client request being a capability discovery request, the pre-bound server is identified as the target server.

[0007] In some embodiments, determining the target server based on the request type includes: In response to the client request being a tool invocation request, the target tool is determined based on the tool invocation request; Detect whether the target tool is a local tool; In response to the fact that the target tool is a local tool, the local tool is invoked to process the tool invocation request; In response to the fact that the target tool is not a local tool, the target server is determined according to the tool routing mapping table and the target tool, wherein the tool routing mapping table includes the correspondence between tool names and servers.

[0008] In some embodiments, determining the target server based on the tool routing mapping table and the target tool includes: Determine the candidate server that matches the target tool in the tool routing mapping table; In response to the existence of multiple candidate servers, the availability status and priority of each candidate server are determined; The target server is determined from the candidate servers based on the availability and priority.

[0009] In some embodiments, sending the client request to the target server includes: In response to the client request being a tool invocation request, check whether authentication is required for the tool invocation; In response to the tool requiring authentication, obtain authentication information; The authentication information is added to the client request and sent to the target server.

[0010] In some embodiments, the method further includes: The received client request and / or response messages are format-validated, including verifying the existence of the version number, the request identifier, the validity of the method name, and the mutual exclusion of correct and incorrect fields in the response message.

[0011] In some embodiments, generating a feedback result based on the response message and sending it to the client includes: In response to the presence of multiple response messages, the multiple response messages are merged to obtain the feedback result. Merging the multiple response messages includes filtering out failed response messages and merging successful response messages.

[0012] In some embodiments, the method further includes: In response to receiving a failure response message, the client request is resent to the corresponding target server according to the predetermined number of retries and delay.

[0013] In a second aspect, embodiments of the present invention provide a data processing apparatus, the apparatus comprising: The request receiving unit is used to receive client requests sent by the client. A request type determination unit is used to parse the client request and determine the request type, which includes tool invocation requests and capability discovery requests. A target server determination unit is configured to determine a target server based on the request type. A request forwarding unit is used to send the client request to the target server; A response message receiving unit is used to receive response messages sent by each of the target servers; The feedback message sending unit is used to generate a feedback result based on the response message and send it to the client.

[0014] Thirdly, embodiments of the present invention provide an electronic device, including a memory and a processor, wherein the memory is used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method as described in the first aspect.

[0015] Fourthly, embodiments of the present invention provide a computer program product comprising a computer program, wherein when the computer program is run on a computer, the computer executes the method described in the first aspect above.

[0016] Fifthly, embodiments of the present invention provide a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the method described in the first aspect.

[0017] The technical solution of this invention receives client requests sent by clients, parses the client requests and determines the request type, which includes tool invocation requests and capability discovery requests. Based on the request type, it determines the target server, sends client requests to the target servers, obtains response messages returned by each target server, generates feedback results based on the response messages, and sends them to the client. Therefore, a Model Context Protocol (MCP) proxy gateway can be used as a communication bridge between the client and the MCP server. The client only needs to establish a connection with the MCP proxy gateway, reducing the client's network resource overhead and management burden. Attached Figure Description

[0018] The above and other objects, features and advantages of the present invention will become clearer from the following description of embodiments of the invention with reference to the accompanying drawings, in which: Figure 1 This is a schematic diagram of the data processing system according to an embodiment of the present invention; Figure 2 This is a schematic diagram of data interaction according to an embodiment of the present invention; Figure 3 This is a flowchart of a data processing method according to an embodiment of the present invention; Figure 4 This is a flowchart of a data processing method according to another embodiment of the present invention; Figure 5 This is a schematic diagram of a data processing device according to an embodiment of the present invention; Figure 6 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0019] The present application is described below based on embodiments, but it is not limited to these embodiments. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without these details. To avoid obscuring the substance of the present application, well-known methods, processes, flows, elements, and circuits are not described in detail.

[0020] Furthermore, those skilled in the art should understand that the accompanying drawings provided herein are for illustrative purposes only and are not necessarily drawn to scale.

[0021] Unless the context explicitly requires it, words such as "including" or "contains" throughout the application should be interpreted as including rather than exclusive or exhaustive; that is, meaning "including but not limited to".

[0022] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0023] The solutions described in this specification and embodiments, if involving the processing of personal information, will be processed only on the premise of having a legal basis (such as obtaining the consent of the personal information subject, or being necessary for the performance of a contract), and will only be processed within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0024] With the rapid development of Large Language Models (LLMs) technology, artificial intelligence applications are increasingly being applied across various industries. Against this backdrop, how to efficiently and securely integrate large language models with diverse external services and data sources has become a core issue driving technology implementation and industrial upgrading. To address this need, the Model Context Protocol (MCP) has emerged and is gradually becoming a standardized communication framework connecting AI models and external services. Based on the JSON-RPC 2.0 protocol, MCP defines a general format and process for interaction between models and services, aiming to simplify resource access, enhance system scalability, and promote interoperability of ecosystem components. Its importance lies not only in improving the model's access to real-time information and proprietary knowledge, but also in providing underlying support for building complex, modular artificial intelligence applications.

[0025] However, despite the significant advantages of MCP in theory, it has revealed several key challenges that urgently need to be addressed in its actual deployment and application.

[0026] First, the problem of service decentralization is becoming increasingly prominent: MCP services with different functions are usually deployed independently on multiple servers or network environments, and clients need to configure and maintain a large number of service endpoints simultaneously. This not only increases the complexity of the system architecture, but also makes dynamic service discovery and unified management difficult.

[0027] Secondly, protocol complexity poses a potential obstacle: Although MCP is based on JSON-RPC 2.0, different service providers often have differences in details in their implementation, such as inconsistencies in error handling, parameter validation, or session management, which seriously affect client compatibility and keep integration costs high.

[0028] In addition, performance issues cannot be ignored: when the client establishes a direct connection with multiple distributed MCP services, frequent network requests and data transmissions will introduce significant latency and bandwidth overhead. Especially in high-concurrency scenarios, the overall response time may become a system bottleneck.

[0029] Moreover, the complexity of the authentication mechanism further exacerbates the integration difficulty: some MCP services require authentication through authorization protocols such as OAuth, while clients face technical challenges in coordinating multiple authentication processes and managing token lifecycles, especially when accessing across security domains.

[0030] The aforementioned problems severely restrict the promotion and application of MCP technology in large-scale, high-requirement production environments. Therefore, this invention proposes a data processing method and system to solve these technical problems.

[0031] Figure 1 This is a schematic diagram of a data processing system according to an embodiment of the present invention. Figure 1 As shown, the data processing system of this embodiment includes a client 1, an MCP proxy gateway 2, and servers. There are multiple servers; this embodiment uses n servers as an example, as shown in Figures 3a, 3b, 3c, ..., 3n. The MCP proxy gateway 2 is connected to both the client 1 and each server, serving as a communication bridge between the client and the servers.

[0032] Client 1 can be a specific application or a terminal device (such as a mobile phone, laptop, desktop computer, tablet, etc.) with that specific application installed. More specifically, this specific application is a software component that implements the MCP protocol, primarily responsible for human-computer interaction with the user, such as receiving user input and providing feedback. It also interacts with the MCP proxy gateway 2, for example, by sending client requests to the MCP proxy gateway 2 and receiving feedback information from it.

[0033] MCP Proxy Gateway 2 is a middleware or gateway that acts as a bridge between Client 1 and the server. Its main function is to receive client requests, forward them to the appropriate server, and then return the server's response to the client.

[0034] In some embodiments, the MCP proxy gateway 2 includes an interface processing module 21, a protocol parser 22, a request router 23, a connection pool manager 24, a detector 25, and a load balancer 26.

[0035] The interface processing module 21 is used to manage the communication between client 1 and MCP proxy gateway 2. For example, a communication connection between client 1 and MCP proxy gateway 2 is established through the stdio (Standard Input Output) interface. stdio defines a set of functions, macros, and data types that enable client 1 to communicate with MCP proxy gateway 2.

[0036] Protocol parser 22 is used to manage communication protocols, such as ensuring that all forwarded requests and responses conform to the JSON-RPC 2.0 (JSON Remote Procedure Call 2.0) protocol specification. JSON-RPC 2.0 is a lightweight, stateless protocol for remote procedure calls (RPC) that uses JSON (JavaScript Object Notation) as its data format to communicate between clients and servers over a network. The JSON-RPC 2.0 protocol specification mainly includes: all requests, responses, and error messages are encoded in JSON format, making them easy to parse and generate in various programming languages; clients can call functions or methods defined on the server and receive the returned results, just like calling local functions; the protocol itself does not maintain session state, and each request is independent; it supports two calling methods: one is that the client sends a request but does not expect to receive a response, and the server executes the method without returning any result; the other is that the client sends a request and waits for the server to return a result (success or error); it supports batch requests: clients can send multiple calls in a single request, and the server also returns multiple responses in array form, improving communication efficiency; a unified error handling mechanism: it defines standard error codes and error message formats, making it easy for clients to identify and handle errors; JSON-RPC 2.0 itself does not specify a transport layer protocol, and it can run on top of any protocol capable of transmitting text, such as HTTP (Hypertext Transfer Protocol), TCP (Transmission Control Protocol), and WebSocket (a protocol for full-duplex communication over a single TCP connection). Specifically, the protocol parser 22 implements a complete JSON-RPC 2.0 protocol verification mechanism in the MCPMessage class to ensure message format consistency and protocol compatibility. Each received message undergoes rigorous format checks, including verifying the JSON-RPC version number, the existence of the request ID, the validity of the method name, and the mutual exclusion of the result and error fields in the response, ensuring that all forwarded requests and responses strictly adhere to the JSON-RPC 2.0 protocol specification.

[0037] Request router 23 maintains the tool routing map table, including acquiring the tool routing map table upon receiving a capability discovery request from client 1, and dynamically maintaining the tool routing map table throughout the process. Request router 23 makes intelligent routing decisions based on different request types. For tool invocation requests, it checks if the tool name is a local tool (e.g., buc_logout) and prioritizes local processing. For other request types, it determines the target server based on the pre-configured tool map and the dynamically discovered tool list. During dynamic tool discovery, request router 23 detects situations where multiple servers provide the same tool name, records the server list corresponding to each tool through the tool routing map table, and identifies potential conflicts due to duplicate tool names. When a tool conflict is detected, the system prioritizes servers providing the same tool based on the priority field in the configuration, ensuring that high-priority servers are listed first. This analysis aids in subsequent conflict resolution decisions. When multiple servers provide the same tool, request router 23 uses a priority mechanism for conflict resolution, defaulting to selecting the healthiest server with the highest priority to handle the request, ensuring consistent service quality. Simultaneously, during the tool list merging process, request router 23 maintains the consistency of tool interfaces, ensuring that the definition of the same tool remains consistent across different servers. Local tools (such as buc_logout) will be added to the tool list to ensure the integrity of the interface.

[0038] The connection pool manager 24 manages network connections between the MCP proxy gateway 2 and clients and servers to improve system performance, reduce latency, and enhance system stability and scalability. Simultaneously, the connection pool manager 24 integrates a health check mechanism. Before forwarding client requests, it assesses the availability of the target server. This allows the request router 23 to filter out unavailable servers, ensuring requests are only sent to available servers. Furthermore, if a high-priority server becomes unavailable, the system automatically selects the next available server. This intelligent failover mechanism ensures service continuity and avoids service interruptions due to single points of failure. When a request fails, the connection pool manager 24 intelligently retryes based on the configured number of retries and latency. For temporary issues such as timeouts and connection errors, it attempts to resend the request; for permanent errors such as authentication failures, it immediately returns an error response.

[0039] Detector 25 is used to continuously collect, analyze, and report the operational status, performance metrics, and security events of the gateway and its proxied services, providing real-time and comprehensive data support for operations, development, and decision-making. Specifically, detector 25 continuously records and analyzes metrics such as response time and success rate of each server to ensure consistent service quality. When performance differences are detected, routing policies are adjusted to maintain overall performance consistency.

[0040] Load balancer 26 is used to manage the load of MCP proxy gateway 2. When load balancing mode is enabled, load balancer 26 analyzes the health status and performance metrics of multiple available servers to detect whether resource allocation will cause conflicts or imbalances. In load balancing mode, the system uses a weighted random algorithm to select one available server, taking into account the server's health status and historical performance, to achieve intelligent load distribution.

[0041] In some embodiments, the MCP proxy gateway 2 also includes an OAuth (Open Authorization) authentication module, which performs preprocessing before the request is sent, checks whether the tool call requires authentication, and if so, automatically obtains or refreshes the access token and adds it as the Authorization header to the request, supporting multiple authentication methods such as Bearer Token and API Key. Simultaneously, it maintains the consistency of authentication status, ensures the validity and unified management of tokens, and triggers a re-authentication process when a token expires or becomes invalid, ensuring that the authentication status of all requests is consistent.

[0042] In some embodiments, the MCP proxy gateway 2 also includes a response management module. When merging multiple server responses, the system analyzes the success status, error type, and data structure of the responses, identifying differences and potential conflicts between the results returned by different servers. Simultaneously, for scenarios requiring the merging of multiple responses (such as tools / list, resources / list, etc.), the system implements intelligent merging logic: successful responses are prioritized for retention and merging, while failed responses are filtered, ultimately returning a unified response format. Cursor compatibility mode is supported, automatically adjusting the response format based on configuration. During capability declaration merging, boolean values ​​and object formats are converted according to the compatibility mode to ensure compatibility with different clients. A unified error code and message format are used for all types of errors. Regardless of whether the error originates from network connection issues, authentication failures, or internal server errors, it is packaged into a standard JSON-RPC error response, ensuring consistent error handling.

[0043] A server is the actual provider of tools (such as database queries, file operations, web searches, etc.).

[0044] In some embodiments, the server is an HTTP (Hypertext Transfer Protocol) based server that can communicate with MCP proxy gateway 2 via HTTP. The server can implement one or more of the following: tool declaration, tool invocation, resource management, and providing prompt word templates. For tool declaration, during initialization, the server informs MCP proxy gateway 2 which tools are available, including the tool's name, description, and parameter mode, through a capability discovery response. For tool invocation, when a client invokes a tool, the backend server receives the tool invocation request, performs the corresponding operation, and returns the result. In some embodiments, the server can also provide a list of resources (such as files, database connections, etc.) and access capabilities. In some embodiments, the server can also provide prompt word templates, which clients can use to construct requests. Thus, MCP proxy gateway 2 aggregates multiple HTTP MCP servers into a single STDIOMCP interface, providing clients with a unified access point and supporting unified authentication capabilities.

[0045] Figure 2 This is a schematic diagram of data interaction according to an embodiment of the present invention. For example... Figure 2 As shown, the data interaction in this embodiment of the invention includes the following steps: Step S101: Send an initialization request.

[0046] In this embodiment, client 1 and MCP proxy gateway 2 establish a communication connection through the stdio (Standard Input Output) interface. stdio defines a set of functions, macros, and data types that enable client 1 to communicate with MCP proxy gateway 2.

[0047] After the user completes registration and login on client 1, client 1 enters the initialization phase. During this phase, it sends an initialization request to MCP proxy gateway 2. This initialization request is used to initialize the session, negotiate the version, and exchange basic capability information between the client and server. For example, the initialization request includes the MCP protocol version used by the client, client information, and supported capabilities. Supported capabilities include which resources, tools, and prompts are supported, as well as related options such as whether lists or subscriptions are supported. Client information includes the client name and version.

[0048] Step S102: Send initialization response.

[0049] In this embodiment, after receiving the initialization request, the MCP proxy gateway 2 returns an initialization response to the client 1. The initialization response includes the MCP protocol versions supported by the gateway, the gateway's capabilities, and gateway information. The supported MCP protocol versions should be consistent with or compatible with the MCP protocol version used by the client. The gateway's capabilities include the resources, tools, prompts, and related options provided by the gateway. The gateway information includes the gateway name and gateway version.

[0050] In some embodiments, after receiving the initialization response, the client will send an initialization completion notification to the MCP proxy gateway 2, indicating that the initialization is complete and normal communication can then begin.

[0051] Step S103: Send a capability discovery request.

[0052] In this embodiment, the client sends a capability discovery request to the MCP proxy gateway, which is used to request a list of available tools from the MCP proxy gateway.

[0053] Step S104: Send a capability discovery request.

[0054] In this embodiment, after receiving the capability discovery request sent by client 1, the MCP proxy gateway identifies the pre-bound server as the target server and sends the capability discovery request to the target server. The pre-bound server can be a server that has established a connection with the MCP proxy gateway.

[0055] It should be noted that not all servers may support the tool. For example, one server may only provide the tool, while another may only provide the resource. Therefore, the MCP proxy gateway can determine the target server based on the capabilities of each server; for instance, it can identify the server that supports the tool as the target server.

[0056] Step S105: Send a capability discovery response.

[0057] In this embodiment, after receiving a capability discovery request, each server sends its own capability discovery response to the MCP proxy gateway, and the capability discovery response includes a list of tools.

[0058] Step S106: Send a capability discovery response.

[0059] In this embodiment, after the MCP proxy gateway receives the capability discovery responses sent by each server, it generates a new capability discovery response and sends it to the client. Specifically, it merges the tool lists from all capability discovery responses into a summary tool list, and generates a new capability discovery response based on the summary tool list.

[0060] In some embodiments, during the tool discovery process, if the MCP proxy gateway detects multiple servers providing the same tool name, it prioritizes the servers providing the same tool based on the priority field in the configuration, placing higher-priority servers first. The priority field in the configuration specifies the pre-defined priority level.

[0061] In some embodiments, during the tool list merging process, the MCP proxy gateway maintains the consistency of tool interfaces, ensuring that the definitions of the same tools remain consistent across different servers. Local tools (such as buc_logout) are uniformly added to the tool list to guarantee interface integrity. Simultaneously, the MCP proxy gateway automatically adjusts the response format according to pre-configured settings. During capability discovery response merging, boolean values ​​and object formats are converted according to a compatibility mode to ensure compatibility with different clients.

[0062] Step S107: Obtain input information.

[0063] In this embodiment, the client receives input information from the user, which includes one or more combinations of text, images, videos, and voice.

[0064] Step S108: Obtain the tool call request.

[0065] In this embodiment, the client sends the user's input information to the AI ​​model. After understanding the user's request based on the input information, if the AI ​​model identifies that an external tool is needed to complete the task, it generates a structured tool call request based on the tool list obtained above. The tool call request includes the name of the tool to be called and related parameters.

[0066] Step S109: Send a tool call request.

[0067] In this embodiment, the client sends the tool invocation request to the MCP proxy gateway 2 through the stdio interface.

[0068] Step S110: Send a tool call request.

[0069] In this embodiment, after receiving the tool invocation request, the MCP proxy gateway 2 forwards the tool invocation request to the corresponding server.

[0070] Specifically, after receiving a tool invocation request, MCP proxy gateway 2 parses the request to obtain the target tool, which is the tool name. It then checks whether the target tool is a local tool. If it is, it invokes the local tool to process the tool invocation request. If the target tool is not a local tool, it determines the target server based on the tool routing mapping table and the target tool, and sends the tool invocation request to the target server. The tool routing mapping table includes the correspondence between tool names and servers.

[0071] In some embodiments, candidate servers matching the target tool are determined in the tool routing mapping table; in response to the existence of multiple candidate servers, the availability status and priority of each candidate server are determined; and the target server is determined from the candidate servers based on the availability status and priority. That is, when MCP proxy gateway 2 detects multiple servers providing the same tool, a priority mechanism is used to resolve conflicts, and the healthiest server with the highest priority is selected by default to handle the request, ensuring consistent service quality. When MCP proxy gateway 2 detects multiple servers providing the same tool, it obtains the availability status of the servers; if a high-priority server is unavailable, the next available server is selected. This intelligent failover mechanism ensures service continuity and avoids service interruptions due to single points of failure.

[0072] In some embodiments, when determining the target server, if load balancing mode is enabled, the system analyzes the health status and performance metrics of multiple available servers to detect potential conflicts or imbalances in resource allocation. In load balancing mode, MCP proxy gateway 2 uses a weighted random algorithm to select one server from the available servers, considering the server's health status and historical performance to achieve intelligent load distribution. Simultaneously, it continuously records and analyzes metrics such as response time and success rate of each server to ensure consistent service quality. When performance differences are detected, routing strategies are adjusted to maintain overall performance consistency.

[0073] In some embodiments, in response to a client request being a tool invocation request, the system detects whether authentication is required for the tool invocation; if authentication is required, it obtains authentication information; adds the authentication information to the client request and sends it to the target server. That is, MCP proxy gateway 2 performs authorization authentication before forwarding the tool invocation request. Specifically, it checks whether the invoked tool requires authentication; if so, it automatically obtains a token or refreshes the access token and adds it as an Authorization header to the request, supporting multiple authentication methods such as Bearer Token and API Key. The Authorization header is a request header in the HTTP protocol used by MCP proxy gateway 2 to prove its identity to the server or provide credentials required to access protected resources. Simultaneously, MCP proxy gateway 2 maintains the consistency of authentication status, ensuring the validity and unified management of tokens. When a token expires or becomes invalid, a re-authentication process is triggered to ensure consistent authentication status across all requests.

[0074] In some embodiments, the MCP proxy gateway 2 uses a unified error code and message format for all types of errors. Regardless of whether the error originates from network connection failure, authentication failure, or internal server error, it will be packaged into a standard JSON-RPC error response and sent to the client to ensure consistency in error handling.

[0075] In some embodiments, in steps S104 and S110 above, the MCP proxy gateway 2 detects the availability status of the target server before forwarding the client request, and sends the client request to the available target server.

[0076] Step S111: The server obtains the query response.

[0077] In this embodiment, after receiving a tool call request, the server executes the tool call request to obtain a query response.

[0078] Specifically, the server parses the tool invocation request, checks if it is indeed a tool invocation, and if so, extracts the tool name and relevant parameters. It checks if the requested tool is in the registered tool list. Based on the tool's input pattern, it validates the relevant parameters and invokes the corresponding tool function, passing in the relevant parameters. The result of the tool execution is encapsulated into a query response and returned. If an error occurs in any of the above steps, a failure response is returned.

[0079] Step S112: Send query response.

[0080] In this embodiment, the server sends the obtained query response to the MCP proxy gateway.

[0081] Step S113: Send query response.

[0082] In this embodiment, the MCP proxy gateway merges and transforms the query response received from the server before sending it to the client.

[0083] Specifically, when the server retrieves a query response, if the response retrieval fails due to reasons such as parameter validation failure, the query response is a failure response. The data result of the failure response includes error fields (such as "error") and error type (such as text information like "search failed" or "file read failed"). If the response retrieval is successful, the query response is a success response. After receiving the query response, the MCP proxy gateway analyzes the success status, error type, and data structure of the response message to identify differences and potential conflicts between the results returned by different servers.

[0084] For scenarios that require merging multiple responses (including capability discovery response merging, query response merging, etc.), the MCP proxy gateway will prioritize retaining and merging successful responses, while failing responses will be filtered out, and finally a unified response format will be returned.

[0085] In some embodiments, for a failed response, the MCP proxy gateway performs intelligent retries based on the configured number of retries and latency. For temporary issues such as timeouts and connection errors, it will attempt to resend the request; for permanent errors such as authentication failures, it will immediately return an error response.

[0086] In some embodiments, for received client requests and response messages sent to the client, the MCP proxy gateway detects that all forwarded requests and responses strictly follow the JSON-RPC 2.0 protocol specification, and ensures message format consistency and protocol compatibility through the verification mechanism of the MCPMessage class.

[0087] The MCPMessage class is the basic unit for information exchange between the MCP client and server. It defines the message format and content, ensuring that both parties can correctly send, receive, and understand each other's communications. Its main functions include unifying the communication format, carrying the payload, and supporting bidirectional communication. Unifying the communication format: It provides a standardized message structure for all types of interactions (such as calling tools, returning results, requesting permissions, reporting errors, etc.). Carrying the payload: It encapsulates the actual data that needs to be transmitted, such as parameters for tool calls, execution results, error details, etc. Supporting bidirectional communication: It allows both the client to send requests and the server to send responses or proactive notifications. An MCPMessage object typically contains one or more of the following key fields: Type: Used to identify the type of message. Common types include request, response, notification, and error. Request indicates a request initiated by the client. Response indicates the server's response to the request. Notification indicates a notification sent proactively by the server to the client. Error indicates an error occurred during the operation.

[0088] ID: A unique identifier used to associate a request with its corresponding response. When a client sends a request with a specific ID, the server's response uses the same ID to indicate which request it is responding to.

[0089] Method: When type is request or notification, the method field specifies the name of the specific operation or function to be invoked (e.g., "readFile" or "listFiles").

[0090] Params: An object containing the arguments required to call the method. Its structure depends on the specific method.

[0091] Result: When the type is response and the request is successful, this field contains the data returned by the operation.

[0092] Error: When the type is error or the response contains error information, this field provides detailed error information, which typically includes the code and message.

[0093] Step S114: The client displays the query results.

[0094] In this embodiment, after receiving the query response, the client provides the query response to the AI ​​model. The AI ​​model generates the final query results based on the query response, and the client displays the query results to the user.

[0095] In some embodiments, the MCP proxy gateway 2 performs format verification on the received client request and / or response messages. This format verification includes verifying the existence of the version number and request identifier, the validity of the method name, and the mutual exclusion of correct and incorrect fields in the response message. Specifically, when the MCP proxy gateway 2 receives a request from a client (initialization request, capability discovery request, tool invocation request) or a response message from a server (query response, capability discovery response, etc.), it needs to verify each received message. This verification includes version number verification, request ID (identifier) ​​existence verification, and method name validity verification.

[0096] For version number verification, MCP proxy gateway 2 verifies the protocol version in the message and checks whether it conforms to the JSON-RPC 2.0 protocol.

[0097] For verifying the existence of request IDs (identifiers), in the JSON-RPC 2.0 protocol, each request has a unique ID, and correspondingly, the response to that request will also contain the same ID. Since JSON-RPC allows asynchronous communication, a client may send multiple requests simultaneously, and the order in which MCP proxy gateway 2 processes these requests may not be fixed. Therefore, request IDs can be used to associate requests with responses. Thus, when MCP proxy gateway 2 receives a message, it verifies whether the message contains a request ID. If the message contains a request ID, it can be executed normally; otherwise, it cannot be executed normally.

[0098] For method name verification, the client requests received by MCP proxy gateway 2 include method names, such as the method name "initialize" in initialization requests and "tools / list" in tool invocation requests. MCP proxy gateway 2 will verify the method names to check whether they meet the predetermined requirements.

[0099] The above verification mechanism can be implemented in the MCPMessage class.

[0100] This invention receives client requests from clients, parses the requests, and determines the request type, including tool invocation requests and capability discovery requests. Based on the request type, it identifies target servers, sends client requests to these servers, obtains response messages from each target server, generates feedback results based on the response messages, and sends them to the client. Therefore, a Model Context Protocol (MCP) proxy gateway can act as a communication bridge between the client and the MCP server. The client only needs to establish a connection with the MCP proxy gateway, reducing the client's network resource overhead and management burden.

[0101] Figure 3 This is a flowchart of a data processing method according to an embodiment of the present invention. Figure 3 As shown, the data processing method of the MCP proxy gateway includes the following steps: Step S201: Receive the client request sent by the client.

[0102] In this embodiment, the client sends a client request to the MCP proxy gateway during the initialization phase or after receiving user input.

[0103] Specifically, during the initialization phase, the client sends a capability discovery request to the MCP proxy gateway. This request requests a list of available tools from the MCP proxy gateway. Upon receiving user input, the client sends this input to the AI ​​model. After understanding the user's request based on the input, the AI ​​model, if it identifies that external tools are needed to complete the task, generates a structured tool invocation request based on the aforementioned tool list. This request includes the name of the tool to be invoked and related parameters.

[0104] Step S202: Message type determination.

[0105] In this embodiment, the client request is parsed and the request type is determined. The request type includes tool invocation requests and capability discovery requests. The client request includes a request type field, which determines the request type. For example, the field in a capability discovery request is "list," and the field in a tool invocation request is "tool_use."

[0106] Step S203: Dynamic tool discovery.

[0107] In this embodiment, dynamic tool discovery is performed in response to the client request being a tool invocation request.

[0108] Specifically, as described above, the tool invocation request occurs after the initialization phase. During the initialization phase, the MCP proxy gateway has already obtained the tool routing map, which includes the correspondence between tool names and servers. That is, the MCP proxy gateway can determine the server list from the tool routing map, which includes all server names. A tool discovery task is created for each server and executed concurrently to obtain the status of each server. This concurrent execution of the discovery task to obtain the status of each server includes: the MCP proxy gateway concurrently sending tool discovery requests to each server; upon receiving the tool discovery request, the server sends its tool list to the MCP proxy gateway. Based on the received server response information, the MCP proxy gateway can obtain the tool list of each server and determine the availability status of each server. If a successful response is received, it indicates that the corresponding server is available; if no successful response is received, it indicates that the corresponding server is unavailable. Simultaneously, the tool routing map is dynamically updated based on the obtained tool list.

[0109] Step S204, Intelligent Routing Decision.

[0110] In this embodiment, the tool call request is parsed to obtain the tool name, thereby determining the target tool. It is then checked whether the target tool is a local tool. If the target tool is a local tool, the local tool is invoked to process the tool call request. If the target tool is not a local tool, the target server is determined based on a tool routing mapping table and the target tool. The tool routing mapping table includes the correspondence between tool names and servers.

[0111] Specifically, if there is only one target tool, then the corresponding server is directly identified as the target server.

[0112] If there are multiple target tools, obtain the servers corresponding to each target tool. Then, sort the multiple servers according to a pre-determined priority, select a server in descending order of priority, and check if the server is available. If the server is available, determine the server as the target server. If the server is unavailable, select the next server in descending order of priority, check if the next server is available, and determine the next server as the target server. Continue in this manner until a usable server with a high priority is obtained as the target server.

[0113] Step S205: Determine the target server.

[0114] In this embodiment, when the client request is a tool invocation request, the target server is obtained through step S204 described above. When the client request is a capability discovery request, all servers that support tool capabilities can be identified as the target server.

[0115] Step S206: Send concurrent requests.

[0116] In this embodiment, after the target server is determined, corresponding client requests are sent concurrently to each target server.

[0117] Step S207: Collect response messages.

[0118] In this embodiment, response messages returned by each target server are collected. The response message corresponding to a tool invocation request is a query response, and the response message corresponding to a capability discovery request is a capability discovery response.

[0119] Step S208: Response message aggregation and processing.

[0120] In this embodiment, the response messages are aggregated to obtain the feedback results.

[0121] Step S209, Protocol Adaptation.

[0122] In this embodiment, the feedback result is converted into a feedback result adapted to the client protocol.

[0123] Step S210: Send feedback results.

[0124] In this embodiment, the feedback result is sent to the client.

[0125] This invention receives client requests from clients, parses the requests, and determines the request type, including tool invocation requests and capability discovery requests. Based on the request type, it identifies target servers, sends client requests to these servers, obtains response messages from each target server, generates feedback results based on the response messages, and sends them to the client. Therefore, a Model Context Protocol (MCP) proxy gateway can act as a communication bridge between the client and the MCP server. The client only needs to establish a connection with the MCP proxy gateway, reducing the client's network resource overhead and management burden.

[0126] Figure 4 This is a flowchart of a data processing method according to another embodiment of the present invention. Figure 4 As shown, the data processing method of this embodiment of the invention is executed by the MCP proxy gateway, and specifically includes the following steps: Step S310: Receive the client request sent by the client.

[0127] Step S320: Parse the client request and determine the request type, which includes tool invocation request and capability discovery request.

[0128] Step S330: Determine the target server based on the request type.

[0129] Step S340: Send the client request to the target server.

[0130] Step S350: Receive response messages from each of the target servers; In some embodiments, determining the target server based on the request type includes: In response to the client request being a capability discovery request, the pre-bound server is identified as the target server.

[0131] In some embodiments, determining the target server based on the request type includes: In response to the client request being a tool invocation request, the target tool is determined based on the tool invocation request; Detect whether the target tool is a local tool; In response to the fact that the target tool is a local tool, the local tool is invoked to process the tool invocation request; In response to the fact that the target tool is not a local tool, the target server is determined according to the tool routing mapping table and the target tool, wherein the tool routing mapping table includes the correspondence between tool names and servers.

[0132] In some embodiments, determining the target server based on the tool routing mapping table and the target tool includes: Determine the candidate server that matches the target tool in the tool routing mapping table; In response to the existence of multiple candidate servers, the availability status and priority of each candidate server are determined; The target server is determined from the candidate servers based on the availability and priority.

[0133] In some embodiments, sending the client request to the target server includes: In response to the client request being a tool invocation request, check whether authentication is required for the tool invocation; In response to the tool requiring authentication, obtain authentication information; The authentication information is added to the client request and sent to the target server.

[0134] In some embodiments, the method further includes: The received client request and / or response messages are format-validated, including verifying the existence of the version number, the request identifier, the validity of the method name, and the mutual exclusion of correct and incorrect fields in the response message.

[0135] In some embodiments, generating a feedback result based on the response message and sending it to the client includes: In response to the presence of multiple response messages, the multiple response messages are merged to obtain the feedback result. Merging the multiple response messages includes filtering out failed response messages and merging successful response messages.

[0136] In some embodiments, the method further includes: In response to receiving a failure response message, the client request is resent to the corresponding target server according to the predetermined number of retries and delay.

[0137] This invention receives client requests from clients, parses the requests, and determines the request type, including tool invocation requests and capability discovery requests. Based on the request type, it identifies target servers, sends client requests to these servers, obtains response messages from each target server, generates feedback results based on the response messages, and sends them to the client. Therefore, a Model Context Protocol (MCP) proxy gateway can act as a communication bridge between the client and the MCP server. The client only needs to establish a connection with the MCP proxy gateway, reducing the client's network resource overhead and management burden.

[0138] Figure 5 This is a schematic diagram of a data processing apparatus according to an embodiment of the present invention. Figure 5 As shown, the data processing apparatus of this embodiment includes a request receiving unit 51, a request type determining unit 52, a target server determining unit 53, a request forwarding unit 54, a response message receiving unit 55, and a feedback message sending unit 56. The request receiving unit 51 receives client requests sent by clients. The request type determining unit 52 parses the client request and determines the request type, which includes tool invocation requests and capability discovery requests. The target server determining unit 53 determines target servers based on the request type. The request forwarding unit 54 sends the client request to the target server. The response message receiving unit 55 receives response messages from each of the target servers. The feedback message sending unit 56 generates feedback results based on the response messages and sends them to the client.

[0139] This invention receives client requests from clients, parses the requests, and determines the request type, including tool invocation requests and capability discovery requests. Based on the request type, it identifies target servers, sends client requests to these servers, obtains response messages from each target server, generates feedback results based on the response messages, and sends them to the client. Therefore, a Model Context Protocol (MCP) proxy gateway can act as a communication bridge between the client and the MCP server. The client only needs to establish a connection with the MCP proxy gateway, reducing the client's network resource overhead and management burden.

[0140] Figure 6 This is a schematic diagram of an electronic device according to an embodiment of the present invention. In this embodiment, the electronic device 6 includes a server, a terminal, etc. Figure 6 As shown, the electronic device 6 includes at least one processor 61; a memory 62 communicatively connected to at least one processor 61; and a communication component 63 communicatively connected to a scanning device, the communication component 63 receiving and transmitting data under the control of the processor 61; wherein the memory 62 stores instructions executable by at least one processor 61, the instructions being executed by at least one processor 61 to implement the above-described data processing method.

[0141] Specifically, the electronic device includes: one or more processors 61 and a memory 62. Figure 6 Taking a processor 61 as an example, the processor 61 and the memory 62 can be connected via a bus or other means. Figure 6 Taking a bus connection as an example, memory 62, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Processor 61 executes various functional applications and data processing of the device by running the non-volatile software programs, instructions, and modules stored in memory 62, thereby implementing the aforementioned data processing methods.

[0142] The memory 62 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store an option list, etc. Furthermore, the memory 62 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 62 may optionally include memory remotely located relative to the processor 61, and these remote memories may be connected to external devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0143] One or more modules are stored in memory 62 and, when executed by one or more processors 61, perform the data processing method in any of the above method embodiments.

[0144] The above-mentioned products can perform the methods provided in the embodiments of this application, and have the corresponding functional modules and beneficial effects of performing the methods. For technical details not described in detail in this embodiment, please refer to the methods provided in the embodiments of this application.

[0145] This invention receives client requests from clients, parses the requests, and determines the request type, including tool invocation requests and capability discovery requests. Based on the request type, it identifies target servers, sends client requests to these servers, obtains response messages from each target server, generates feedback results based on the response messages, and sends them to the client. Therefore, a Model Context Protocol (MCP) proxy gateway can act as a communication bridge between the client and the MCP server. The client only needs to establish a connection with the MCP proxy gateway, reducing the client's network resource overhead and management burden.

[0146] Another embodiment of the present invention relates to a non-volatile storage medium for storing a computer-readable program for use by a computer to execute some or all of the above-described method embodiments.

[0147] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0148] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A data processing method, characterized in that, The method includes: Receive client requests sent by the client; The client request is parsed and the request type is determined, including tool invocation requests and capability discovery requests. Determine the target server based on the request type; Send the client request to the target server; Receive response messages sent by each of the target servers; A feedback result is generated based on the response message and sent to the client.

2. The method according to claim 1, characterized in that, Determining the target server based on the request type includes: In response to the client request being a capability discovery request, the pre-bound server is identified as the target server.

3. The method according to claim 1, characterized in that, Determining the target server based on the request type includes: In response to the client request being a tool invocation request, the target tool is determined based on the tool invocation request; Detect whether the target tool is a local tool; In response to the fact that the target tool is a local tool, the local tool is invoked to process the tool invocation request; In response to the fact that the target tool is not a local tool, the target server is determined according to the tool routing mapping table and the target tool, wherein the tool routing mapping table includes the correspondence between tool names and servers.

4. The method according to claim 3, characterized in that, Determining the target server based on the tool routing mapping table and the target tool includes: Determine the candidate server that matches the target tool in the tool routing mapping table; In response to the existence of multiple candidate servers, the availability status and priority of each candidate server are determined; The target server is determined from the candidate servers based on the availability and priority.

5. The method according to claim 1, characterized in that, Sending the client request to the target server includes: In response to the client request being a tool invocation request, check whether authentication is required for the tool invocation; In response to the tool requiring authentication, obtain authentication information; The authentication information is added to the client request and sent to the target server.

6. The method according to claim 1, characterized in that, The method further includes: The received client request and / or response messages are format-validated, including verifying the existence of the version number, the request identifier, the validity of the method name, and the mutual exclusion of correct and incorrect fields in the response message.

7. The method according to claim 1, characterized in that, The step of generating a feedback result based on the response message and sending it to the client includes: In response to the presence of multiple response messages, the multiple response messages are merged to obtain the feedback result. Merging the multiple response messages includes filtering out failed response messages and merging successful response messages.

8. The method according to claim 7, characterized in that, The method further includes: In response to receiving a failure response message, the client request is resent to the corresponding target server according to the predetermined number of retries and delay.

9. A data processing apparatus, characterized in that, The device includes: The request receiving unit is used to receive client requests sent by the client. A request type determination unit is used to parse the client request and determine the request type, which includes tool invocation requests and capability discovery requests. A target server determination unit is configured to determine a target server based on the request type. A request forwarding unit is used to send the client request to the target server; A response message receiving unit is used to receive response messages sent by each of the target servers; The feedback message sending unit is used to generate a feedback result based on the response message and send it to the client.

10. An electronic device comprising a memory and a processor, characterized in that, The memory is used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method as described in any one of claims 1-8.

11. A computer program product, the computer program product comprising a computer program, characterized in that, When the computer program is run on a computer, the computer performs the method according to any one of claims 1-8.

12. A computer-readable storage medium storing computer program instructions thereon, characterized in that, The computer program instructions, when executed by a processor, implement the method as described in any one of claims 1-8.

Images