Method and device for issuing MCP tool

Abstract

The embodiment of the invention discloses an MCP tool issuing method and device, and the method comprises the following steps: configuring a first mapping relation, a second mapping relation, and a corresponding relation between an MCP tool and an API through an MCP tool manager, and issuing the MCP tool to a visible tool list of an MCP client; after an MCP tool request message is received through an access layer tool actuator, the MCP tool request message is converted into a corresponding API request message according to the first mapping relation, and the API request message is forwarded to an upstream service; and obtaining an API response message returned by the upstream service, and converting the API response message into a corresponding semantic response message according to the second mapping relationship. According to the embodiment of the invention, the method can achieve the conversion from the API to the MCP tool at high efficiency and low cost according to the mapping relation between the messages, and does not need to carry out the hard transformation of an existing API code.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and specifically to a method and device for publishing an MCP tool. Background Art

[0002] The Model Context Protocol (MCP) is a groundbreaking public protocol in the field of large model technology that enables AI Agents to use tools. It provides standardized regulations for traditional FunctionCallback calls in terms of message specifications, interaction processes, error codes, and lifecycle management.

[0003] Currently, there are many practical business APIs in vertical fields. Their application layer protocol is generally HTTP, and their message protocols generally follow the HTTP RESTful style or the web service style. Modifying the code of these existing APIs to adapt to the MCP Tool message specification will bring a lot of development and testing workload.

[0004] Application Contents

[0005] The purpose of the embodiments of the present application is to provide a method and apparatus for publishing an MCP tool to address the drawback of the existing technology of heavy development and testing workload.

[0006] In order to solve the above technical problems, this application is implemented as follows:

[0007] In a first aspect, a method for publishing an MCP tool is provided, comprising the following steps:

[0008] The MCP tool manager configures the first mapping relationship, the second mapping relationship, and the correspondence between the MCP tool and the API, and publishes the MCP tool to the tool list visible to the MCP client; the first mapping relationship is the mapping relationship between the API request message and the MCP tool request message, and the second mapping relationship is the mapping relationship between the semantic response message and the API response message;

[0009] After receiving the MCP tool request message through the access layer tool executor, convert the MCP tool request message into a corresponding API request message according to the first mapping relationship, and forward the API request message to the upstream service;

[0010] Obtain the API response message returned by the upstream service, and convert the API response message into a corresponding semantic response message according to the second mapping relationship.

[0011] In a second aspect, a publishing device for an MCP tool is provided, comprising:

[0012] A configuration module, configured to configure, through the MCP tool manager, a first mapping relationship, a second mapping relationship, and a correspondence between the MCP tool and the API, and publish the MCP tool to a tool list visible to the MCP client; the first mapping relationship is a mapping relationship between the API request message and the MCP tool request message, and the second mapping relationship is a mapping relationship between the semantic response message and the API response message;

[0013] A first conversion module is configured to, after receiving an MCP tool request message through the access layer tool executor, convert the MCP tool request message into a corresponding API request message according to the first mapping relationship, and forward the API request message to an upstream service;

[0014] The second conversion module is used to obtain the API response message returned by the upstream service, and convert the API response message into a corresponding semantic response message according to the second mapping relationship.

[0015] The embodiment of the present application can realize the conversion from API to MCP tool efficiently and at low cost based on the mapping relationship between messages, without the need for hard modification of existing API code and avoiding the occupation of unnecessary large language model tokens. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a flow chart of a publishing method of an MCP tool provided in an embodiment of the present application;

[0017] Figure 2 This is a specific implementation diagram of the publishing method of the MCP tool provided in the embodiment of the present application;

[0018] Figure 3 This is a schematic diagram of the star message format conversion principle of the XConverter converter provided in an embodiment of the present application;

[0019] Figure 4 This is a schematic diagram of the configuration mapping conversion rules of the API request message provided in the embodiment of the present application;

[0020] Figure 5 This is a schematic diagram of the specific flow of the message conversion process provided by the embodiment of the present application;

[0021] Figure 6 This is a schematic diagram of a mapping conversion rule for combining two fields into one, provided in an embodiment of the present application;

[0022] Figure 7This is a schematic diagram of a mapping conversion rule for converting a JSON object array format into a CSV format provided in an embodiment of the present application;

[0023] Figure 8 This is a specific flow chart of message conversion performed by the XConverter message converter provided in an embodiment of the present application;

[0024] Figure 9 This is a structural diagram of a publishing device for an MCP tool provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0026] The MCP protocol specifies the tool's request and response message formats in detail. Vertical SAAS platform companies face three typical problems when building their own MCP servers and publishing their own MCP tools. One is that the existing API's request and response messages don't conform to the MCP protocol specifications. Another is that the key names of the API's response message data fields are English abbreviations or phonetic abbreviations, resulting in weak semantic information that hinders accurate understanding of the LLM large model. Finally, the API's response message generally returns a large amount of detailed data. If all of this is returned to the LLM large model, the token usage cost is high. However, some details in the response message can be merged, while others can be filtered out.

[0027] Generally, faced with these three issues, SaaS platform companies first modify existing API code. Based on different entry paths or request source identifiers, they adapt the request message format to the MCP tool when parsing the request message data. They also add semantic adaptation and conversion code that is easier for the large-scale model (LLM) to understand before returning the response message data. They then configure different entry paths on the load balancer or NGINX, or add path identifier header information to the same path. This approach has two significant drawbacks. One is the high cost of code modification and testing, which slows down rollout and hinders the rapid and extensive reuse of existing API assets. Another drawback is that because requests to the API from the original request path and the new MCP tool request path coexist, operations and maintenance personnel must add some kind of path identification markup to hard-coded logic for identification. Operations and maintenance personnel must also manage API requests from the MCP tool request path, including monitoring, rate limiting, and circuit breaking. These factors lead to high operational and maintenance costs and low reuse of existing governance measures.

[0028] In response to the above three problems, the embodiment of the present application proposes an MCP tool adaptation layer. Without the need to modify the API code, the existing API can be published as a tool that complies with the MCP protocol after conversion by the MCP tool adapter, thereby quickly providing the MCP tool for numerous AIAgent intelligent bodies to call, thereby improving the speed of implementation of the AI ​​strategic transformation of vertical SAAS companies. The above-mentioned MCP tool adaptation layer has three advantages: one advantage is that the hard-coded adaptation work such as message format conversion, semantic enhancement conversion, detail filtering and hiding required for adapting the MCP tool for each API is extracted and turned into a public, reusable and configurable capability layer, which completes these adaptation and conversion tasks through configuration; one advantage is that the semantic conversion of API response messages implemented by the adaptation layer can enhance semantic information, filter out useless information and reduce the token number burden of large language models; one advantage is that there is only one set of APIs, and the API itself does not need to pay attention to where the request path comes from. The already established monitoring, current limiting and circuit breaking and other governance measures can still continue to be reused.

[0029] The embodiment of the present application focuses on the MCP Tool-API adapter, which uses the coordinated work of several components, including the XConverter message converter, API request forwarding component, semantic response message generator, API request message generator, MCP tool response message generator, API manager, and MCP tool manager, to achieve the adaptive conversion of traditional existing APIs to MCP tools.

[0030] Specifically, the MCP Tool-API adapter contains an XConverter message converter. The XConverter message converter can convert MCP Tool request messages to API request messages, such as JSON to JSON, JSON to XML, and JSON to CSV; it can also convert API response messages to semantic response messages. The MCP Tool-API adapter also contains an HTTP client that initiates HTTP requests to upstream services. The upstream service can be built in Java / Node / Python. The input and output parameters of the upstream service's API can be in SOAP data format, JSON data format, CSV data format, or fixed-length message format.

[0031] The following describes in detail the publishing method of the MCP tool provided in the embodiment of the present application through specific embodiments and application scenarios in conjunction with the accompanying drawings.

[0032] like Figure 1 FIG. 1 is a flow chart of a method for publishing an MCP tool provided in an embodiment of the present application, the method comprising the following steps:

[0033] Step 101: The MCP tool manager configures a first mapping relationship, a second mapping relationship, and a correspondence between the MCP tool and the API, and publishes the MCP tool to a tool list visible to the MCP client. The first mapping relationship is a mapping relationship between an API request message and an MCP tool request message, and the second mapping relationship is a mapping relationship between a semantic response message and an API response message.

[0034] Specifically, the message data in the source message format can be parsed into the intermediate structure tree of the source message through the message parser of the XConverter message converter; the message data in the destination message format can be parsed into the intermediate structure tree of the destination message through the message parser of the XConverter message converter; based on the node value addressing reference rules of the intermediate structure tree specified by the XConverter message converter and the support for SPEL value expressions, the mapping or calculation rules between the field values ​​of the intermediate structure tree of the source message and the intermediate structure tree of the destination message are configured and constructed.

[0035] Among them, the conversion capability of the XConverter message converter executes the SPEL value expression configured in the mapping rule to complete the conversion of the source message to the destination message; when the source message is an MCP tool request message, the destination message is an API request message; when the source message is an API response message, the destination message is a semantic response message.

[0036] In this embodiment, the XConverter message converter can be used to summarize and abstract 4 structural nodes that have common meanings in multiple message format types, and uniformly use the 4 structural nodes to build an intermediate structure tree, the 4 structural nodes include loop node loopNode, object node objectnode, value node valuenode and attribute node attributenode; the XConverter message converter can be used to summarize and abstract 8 data value types that have common meanings to represent the data type of the value, and uniformly use the 8 data value types to describe the data type of the value of each valuenode value node and each attributenode attribute node in the intermediate structure tree, the 8 data value types include TEXT text type, BOOL EAN Boolean type, LONG integer type, DATE date type, DECIMAL floating point type, NULL null value type, DOCUMENTREF document object reference type and MISSING non-existent field value type; through the message format base parser parser built into the XConverter message converter, the input message data is parsed into the native message structure tree of the message format type; through the XConverter message converter, the native message structure tree is traversed, the native structure nodes are translated and converted into structure nodes of the unified intermediate structure tree to form a new unified intermediate structure tree, and after the native message format type name is supplemented in the new unified intermediate structure tree, the new unified intermediate structure tree is named MessageDefinition message structure definition object and serialized.

[0037] Step 102: After receiving the MCP tool request message through the access layer tool executor, convert the MCP tool request message into a corresponding API request message according to the first mapping relationship, and forward the API request message to the upstream service.

[0038] In this embodiment, before converting the MCP tool request message into a corresponding API request message according to the first mapping relationship, API information corresponding to the MCP tool, API request message definition information, API response message definition information, MCP tool request message definition information, semantic response message definition information, the first mapping relationship, and the second mapping relationship may also be obtained according to the MCP tool corresponding to the MCP tool request message, where the API information includes an API type and an API upstream URL.

[0039] Accordingly, the mcptool-api-adaptor adapter requester is called with the API information and the MCP tool request message information as input parameters; the API request message generator is called through the mcptool-api-adaptor adapter requester, and the API request message generator uses the MCP tool request message data, MCP tool request message definition information, API request message definition information and the first mapping relationship as input parameters, and calls the message conversion capability of the XConverter message converter to convert the MCP tool request message data into API request message data.

[0040] Furthermore, the XConverter message converter can call a base parser that is compatible with the message format type of the source message to parse the source message into a structure tree of its own message format type; the XConverter message converter uses the intermediate structure tree of the source message definition data as a reference standard to recursively check whether the structure nodes in the intermediate structure tree of the source message and the intermediate structure tree of the destination message are consistent with each other; if inconsistent structure nodes are found during the structure tree verification process, a failure message is returned; otherwise, the structure tree of the source message's own data type is converted into an intermediate structure tree representation, and each node in the intermediate structure tree carries the value of the source message; recursively traverse each node of the intermediate structure tree of the destination message, calculate the value of the destination node according to the mapping calculation rules of the SPEL value expression, and generate an intermediate structure tree of the destination message with value; based on the intermediate structure tree and the message format specified in the destination message definition, call a writer outputter of the corresponding format to output the intermediate structure tree as the converted destination message data.

[0041] Step 103: Obtain the API response message returned by the upstream service, and convert the API response message into a corresponding semantic response message according to the second mapping relationship.

[0042] Specifically, the API response message data, API response message definition information, semantic response message definition information and the second mapping relationship information can be used as input parameters to call the MCP response message generator; the message conversion request is delegated to the semantic response message generator through the MCP response message generator, and the semantic response message generator uses the API response message data, API response message definition information, semantic response message definition information and the second mapping relationship information as input parameters to call the message conversion capability of the XConverter message converter to convert the API response message data into a semantic response message.

[0043] The embodiment of the present application can realize the conversion from API to MCP tool efficiently and at low cost based on the mapping relationship between messages, without the need for hard modification of existing API code and avoiding the occupation of unnecessary large language model tokens.

[0044] In an embodiment of the present application, an adapter conversion method for publishing an API into an MCP tool includes configuring message mapping conversion rules in configuration mode and performing message adaptation conversion based on the mapping conversion rules in runtime mode, thereby publishing an existing API into an MCP tool. This method enables the rapid conversion of existing APIs into tools that meet the MCP Model Context Protocol tool specification through simple configuration and publishes them to an MCP server for invocation by large language models with the assistance of MCP clients.

[0045] Specifically, the MCP Server's server-side program provides standard SSE endpoints and MCP message endpoints on the public network. Various large-scale model LLMs call the MCP tool provided by the MCP Server through the MCP Client program. SSE (Server Sent Events) is a one-way communication technology based on the HTTP protocol that allows the server to actively push messages to the client in real time. The client only needs to establish a connection once to continuously receive messages. SSE establishes a persistent HTTP connection. The MCP message endpoint is the entry point for the MCP client to initiate a tool call to the MCP Server. Request messages that comply with the MCP protocol tool specification enter the MCP Server through the MCP message endpoint, and response messages that comply with the MCP protocol tool specification are returned to the MCP client in the form of an event through the SSE persistent connection.

[0046] like Figure 2 FIG. 1 is a specific implementation diagram of the publishing method of the MCP tool provided in an embodiment of the present application, comprising the following steps:

[0047] Step 1: Request identity information by calling the MCP API Key Manager to issue and manage API keys.

[0048] Step 2: Manage the API by calling the API manager. Configure and save the API's basic information, API request message definition information, API response message definition information, API upstream URL forwarding address, and other information.

[0049] Step 3: Manage the tool by calling the MCP tool manager. This includes configuring the mapping between the tool and the API, publishing the tool to the toolslist so that the MCP client can see it, and configuring and managing the mapping between API request messages and MCP tool request messages, as well as the mapping between semantic response messages and API response messages for the API that requires adaptation.

[0050] Step 4: The MCP client first initiates a persistent connection establishment request to the SSE endpoint. After receiving the request, the SSE access point of the MCP server calls the SSE persistent connection manager. After verifying the validity of the apikey and the number of session connections, the SSE persistent connection manager calls the sessionid issuer to issue the sessionid, establishes the SSE persistent connection channel, and returns the MCP messenger endpoint URL information with the sessionid information to the MCP client through the SSE persistent connection channel.

[0051] Step 5: The MCP client initiates an HTTP MCP message call to the URL of the MCP message endpoint. After receiving the request, the MCP message access point of the MCP server calls the MCP message executor.

[0052] In step 6, the MCP Server's MCP message executor is responsible for identifying different types of message requests and calling the initialize executor, tools / list executor, notify executor, and access layer tool executor according to the different types to execute the execution logic of the message request. After obtaining the result, the response message data is returned to the MCP client through the SSE channel of this session.

[0053] Step 7: After receiving the request message from the MCP tool, the access layer tool executor of the MCP Server directly delegates the call to the execution layer tool executor and returns to the upstream after receiving the response.

[0054] Step 8. After the execution layer tool executor receives the request, the execution layer tool executor first calls the tool-api mapping manager to query the API information corresponding to the tool. The API information includes basic information such as API type and API upstream URL. If the API is an API that requires adaptation, the tool-api mapping manager continues to query to obtain the API request message definition information, API response message definition information, MCP tool request message definition information, semantic response message definition information, the mapping relationship information between the API request message and the MCP tool request message, and the mapping relationship information between the semantic response message and the API response message, etc., which are configuration information needed for message conversion. If it is an API that does not require adaptation, the access layer tool executor directly calls the HTTP API requester, directly forwards the MCP tool request message to the upstream service program through the HTTP RPC call method, and returns the response message upstream after obtaining the response. If the API requires adaptation, the access layer tool executor uses the query to obtain all API information and MCP tool request message information as input parameters, and calls the mcptool-api-adaptor adapter requester. The mcptool-api-adaptor adapter requester completes the adaptation and forwarding call of the API. The access layer tool executor returns the adapted response message returned by the mcptool-api-adaptor adapter requester.

[0055] Step 9: After receiving the request, the mcptool-api-adaptor adapter first calls the API request message generator to convert the MCP tool request message to the API request message. The API request message generator takes the MCP tool request message data, the mcp tool request message definition information, the API request message definition information, and the mapping relationship between the API request message and the MCP tool request message as input parameters, and calls the message conversion capability of the XConverter message converter to convert the MCP tool request message data to the API request message data; then, the mcptool-api-adaptor adapter calls the HTTP API requester to convert the API request message data through HTTP. The MCP response message generator is called with the API response message data, API response message definition information, semantic response message definition information, and the mapping relationship between the semantic response message and the API response message as input parameters. The MCP response message generator delegates the request to the semantic response message generator to complete the conversion of the API response message data into a semantically friendly and concise converted API response message. After receiving the semantically friendly and concise converted API response message, the MCP response message generator calls the tostring serialization method to generate a result string and assigns it to the text field value in the MCP tool response message format. After that, the MCP tool response message is generated and returned upstream.

[0056] When the semantic response message generator receives a message conversion request, it takes the API response message data, API response message definition information, semantic response message definition information, and the mapping relationship between the semantic response message and the API response message as input parameters, calls the message conversion capability of the XConverter message converter to convert the API response message data into a semantically friendly and concise converted API response message, and returns it upward.

[0057] In this embodiment, the MCP Tool-API adapter includes an apikey manager, an API manager, an MCP tool manager, an XConverter message converter, an API request message generator, a semantic response message generator, an MCP response message generator, and an mcptool-api-adaptor adapter requester.

[0058] The APIKey Manager is responsible for issuing and managing APIKeys. An APIKey is a tool invocation credential issued offline by the MCP Server to the MCP Client before the MCP Client initiates an SSE persistent connection and message request to the MCP Server. The APIKey data model includes key information such as the APIKey, APIKey holder, APIKey issuance date, and APIKey status. APIKey status typically includes enabled, frozen, and invalidated.

[0059] The API manager is responsible for registering and managing APIs. Administrators use the API manager to manage APIs. The API model includes key information such as the API ID, API name, API description, API request forwarding URL, API request message definition data, and API response message definition data. Upstream microservice APIs are accessed via HTTP RPC calls. The API request forwarding URL refers to the full URL path of the microservice to which the API request is forwarded.

[0060] The MCP tool manager is responsible for the management of the MCP tool, including three aspects: tool registration and management, tool-api mapping relationship management, and tool publishing toolslist management. The administrator registers and manages the basic information of the tool. The MCPtool model includes key information such as toolID, tool name, tool function description, and tool request message definition data. The administrator configures and manages which API to use to complete the tool's functions. The tool-api mapping relationship model includes information such as tool ID, apiID, a flag indicating whether adaptation forwarding is required, mapping rule data between api request messages and MCP tool request messages, and mapping rule data between semantic response messages and api response messages. When configuring the tool and API mapping relationship, you need to set the forwarding flag based on whether the API call requires an adapter. One type of API does not require message format conversion through the mcptool-api-adaptor adapter. These APIs are generally newly developed APIs that comply with the MCP tool's request and response message formats and do not require mapping rule configuration. Another type of API requires message format conversion through the mcptool-api-adaptor adapter. These APIs require additional mapping rule data for API request messages to MCP tool request messages, and for semantic response messages to API response messages. Message mapping rules are configured on the MCP tool manager's message mapping rule configuration page. They utilize the XConverter message converter's ability to parse message data into an intermediate structure tree and establish mapping relationships based on the intermediate structure tree. Administrators configure the publishing relationship between tools and toolslist. Administrators can publish tools to the toolslist for MCP Client to call. Administrators can also release or temporarily freeze the publishing status of a tool to prohibit MCP Client from calling it.

[0061] The XConverter message converter is responsible for parsing message data of different message formats into a unified intermediate structure tree, and establishing mapping rules based on the intermediate structure tree to achieve mutual conversion between message data. XConverter has message data parsing capabilities (parser), message data conversion capabilities (converter), and serialization and string generation capabilities (writer). It is designed primarily to achieve star message format conversion. On the MCP tool manager message mapping rule configuration page described in the patent, when the administrator configures the MCP tool's JSON RPC format request message to API request message conversion rules, and API response message to semantic response message conversion rules, the underlying capabilities are all completed through the XConverter message converter capabilities.

[0062] Specifically, the star message format conversion work of the XConverter message converter is as follows: Figure 3 As shown, the following steps are included: the message parser of the XConverter message converter finally parses the message data in the source message format into the intermediate structure tree of the source message; the message parser of the XConverter message converter finally parses the message data in the destination message format into the intermediate structure tree of the destination message; based on the node value addressing reference rules of the intermediate structure tree specified by the XConverter message converter and the support for SPEL value expressions, the mapping or calculation rules between the field values ​​of the two intermediate structure trees are configured and constructed; at runtime, the conversion capability of the XConverter message converter is called to execute the SPEL value expression configured in the mapping rule to complete the conversion of the source message data to the destination message data. This conversion can be from one message format to another, such as JSON to CSV, or from one structure of the same message format to another, for example, from a JSON nested structure to a JSON flat structure, from the rich number of fields in JSON to the simple number of fields in JSON, from the English field name in JSON to the semantic field name in JSON, and so on.

[0063] The API request message generator is responsible for converting the request message specified by the MCP protocol into an API request message that can be recognized by the API. It takes the MCP tool request message, MCP tool request message definition data, API request message definition data, and the mapping rule data between the API request message and the MCP tool request message as input parameters, and calls the conversion capabilities of the XConverter message converter to complete this task.

[0064] For example, when registering an API in the API Manager, the request message definition data for the API itself includes four parameters: companyName, taxId, accuracy, and sort, where sort is a sub-object. When registering a tool in the MCP Tool Manager, the request message definition data for the tool includes two parameters: companyName and taxId.

[0065] Configure the mapping conversion rules on the MCP tool manager message mapping rule configuration page: (1) The companyName and taxId fields in the MCP tool request message definition data correspond one-to-one with the companyName and taxId fields in the API request message definition data, such as Figure 4 (2) The accuracy fuzzy query configuration parameters and sort result sorting configuration parameters in the API request message definition are not open to the MCP tool. When the MCP tool request arrives, the API is uniformly queried using "accuracy":fase" fuzzy query and "sort":{"frequency":0} descending sort.

[0066] The MCP tool request message before conversion is:

[0067]

[0068] XConverter uses the configured mapping rules between the API request message and the MCP tool request message to convert the message and obtain the API request message:

[0069]

[0070]

[0071] The semantic response message generator is responsible for converting API response messages into semantic response messages with specific semantic information that is easily understood by the Large Language Model (LLM). It takes the API response message, API response message definition data, semantic response message definition data, and the mapping relationship between the semantic response message and the API response message as input parameters, invokes the conversion capabilities of the XContverter message converter to complete this task, and returns a DocumentObject document object for the semantic response message. Generally, the size and structure of the converted semantic response message data will change. A key prerequisite for semantic response message conversion is that the administrator must configure the mapping rules between the semantic response message definition data and the API response message definition data on the MCP tool manager message mapping rule configuration page.

[0072] The present application embodiment provides several main mapping conversion rules for semantic conversion, which play the role of semantic enhancement, compact structure, and reducing token count in large models. Details are as follows:

[0073] (1) Make semantic conversion of key names and field enumeration values, which is concise and easy to understand

[0074] API response messages are generally designed for reading in programming languages, and API requesters must adhere to API input and output parameter conventions when programming and using them. With the rise of large language models (LLMs) and AI agent technology, MCP tool response messages are now understood by large models in a manner similar to natural language. This places higher demands on the accuracy, unambiguity, and understandability of field key names in response messages. Some API response messages that use pinyin abbreviations, technical English abbreviations, or even different numbers to represent semantics require semantic enhancement to prevent ambiguous interpretations by large language models that could lead to unintended associations.

[0075] For example, the key names gssh, taxno, and taxId are converted to "corporate tax number", the key name user_id is converted to "user ID", the key name status is converted to "request status", the key name name is converted to "name", the key name role is converted to "role", the key name timestamp is converted to "processing time", the value "200" of status is converted to "request successful (200)", and the value "admin" of role is converted to "administrator (admin)".

[0076] For example, the original API response message before conversion is:

[0077]

[0078] The semantic response message after conversion is:

[0079]

[0080] (2) Convert the JSON object array to CSV format, and perform semantic conversion on the key name and field enumeration value to enhance the semantics and save the number of token characters occupied by the key

[0081] When querying a list, the API generally returns a response message with a JSON object array result. For this type of message, on the one hand, the key name and field enumeration value are semantically converted. On the other hand, in order to reduce the occupation of the large language model token count by repeated key names in the response message, the JSON object array message format is converted to CSV message format to make the response message more compact. For example, the key name id is converted to "product ID", the key name name is converted to "product name", the key name category is converted to "product category", and the key name stock is converted to "product inventory".

[0082] For example, the original API response message before conversion is:

[0083]

[0084] The semantic response message after conversion is:

[0085] Product ID, product name, product category, product inventory

[0086] P100, LCD display, electronics, 15

[0087] P101, signature pen, stationery, 34

[0088] P102, Bluetooth mouse, electronic, 25

[0089] (3) Convert JSON multi-layer nested structures into flat structures, merge multiple fields into one field, eliminate unnecessary secondary fields, and perform semantic conversion on key names and field enumeration values.

[0090] One-to-one inclusion relationships are common in business models, which generally result in multi-layered nested JSON structures in API response messages. A multi-layered nested structure representing the same number of core attribute information will occupy several more object type key names than a flattened structure. For program reading and calculation needs, quantity and unit information are stored in two attribute fields. For LLM reading and comprehension, the quantity and unit can be combined into a single string, saving a key name. For business model modeling needs, object information is self-integrated and contains more detailed information. However, some attribute information is secondary and can be omitted without affecting the presentation of core attribute information.

[0091] For example, the timestamp key name is converted to "processing time", the id key name is converted to "transaction ID", and the recipient key name is converted to "transaction payee". The key names of the status and message attributes are combined into "request status", and the values ​​"200" and "OK" are combined into "200(OK)". The key names of the amount and currency attributes are combined into "transaction amount", and the values ​​1500.00 and USD are combined into "1500.00USD". The customer attribute field is directly eliminated. Finally, the nested JSON structure is flattened, eliminating technical attribute keys such as response, header, body, and transaction. These do not affect the understanding of core attribute information but are meaningless to the large language model (LLM). This achieves a semantic conversion effect with clear semantics and compact structure, saving token counts in the large language model.

[0092] For example, the original API response message before conversion is:

[0093]

[0094]

[0095] The converted semantic response message is:

[0096]

[0097] The MCP response message generator is responsible for converting the API response message into the MCP tool response message. It calls the semantic response message generator with the API response message, API response message definition data, semantic response message definition data, and the mapping relationship between the semantic response message and the API response message as input parameters. For the DocumentObject document object of the JSON message or CSV message returned by the semantic response message generator, it calls the serialization function writer of the DocumentObject document object to generate a string string and assigns it to the result.content.text field to complete this task. As described in the patent of this invention, the semantic response message generator calls the conversion capability of the XContverter message converter to complete this semantic conversion work.

[0098] If the semantic response message generator returns JSON data, its DocumentObject writer message serializer generates a JSON string. For example, {"Request Status":"Request Successful (200)","Processing Time":"2025-05-10T12:34:16Z","Return Data":[{"User ID":"1234","Name":"Zhang San","Role":"Administrator(admin)"},{"User ID":"6789","Name":"Li Si","Role":"Auditor(auditor)"}]}.

[0099] If the semantic response message generator returns CSV message data, its DocumentObject writer message serializer generates a string in the markdown table style. For example, \n|Product ID|Product Name|Product Category|Product Inventory|\n|:---|:---|:---|:---|\n|P100|LCD Monitor|Electronics|15|\n|P101|Signature Pen|Stationery|34|\n|P102|Bluetooth Mouse|Electronics|25|\n.

[0100] The MCP response message generator can ultimately generate the following MCP tool response message structure message data. The example is as follows, where the text field value is the string generated by serializing the document object returned by the semantic response message generator:

[0101]

[0102]

[0103] The mcptool-api-adaptor adapter handles scheduling tasks. During runtime, it calls the API request message generator, HTTP API requester, and MCP tool response message generator at appropriate times. It adapts the existing APIs that carry MCP tool functions by forwarding calls to upstream microservice APIs and converting and adapting data message formats. The message specifications for interaction between it and the upper-layer MCP tool executor follow the MCP tool call request and response message formats specified by the MCP protocol.

[0104] In this embodiment, the overall process of the message conversion process is as follows: Figure 5 As shown, the implementation includes the following three steps, steps 1 and 2 are completed in the configuration state, and step 3 is completed in the running state.

[0105] Specifically, in step 1, the sample source message data in the source message format and the sample destination message data in the destination message format are retrieved, uploaded, or edited through the MCP tool manager, and the XConverter message converter is called to generate the source message definition data represented by the unified intermediate structure tree and the destination message definition data represented by the unified intermediate structure tree, and store them in the database for persistent storage.

[0106] In the second step, the source message definition data and destination message definition data represented by the unified intermediate structure tree are retrieved from the DB through the MCP tool manager. By writing SPEL value expressions, the mapping calculation rules between the field values ​​of the destination message definition data represented by the unified intermediate structure tree and the field values ​​of the source message definition data are established. The mapping calculation rule data is stored in the database for persistence.

[0107] Step 3. In the running state, when a specific message data in the source message format arrives and needs to be converted to the message format, the specific message data in the source message format, the source message definition data represented by the unified intermediate structure tree, the destination message definition data represented by the unified intermediate structure tree, and the mapping calculation rule data between the field values ​​of the destination message definition data represented by the unified intermediate structure tree and the field values ​​of the source message definition data are used as input parameters, and the conversion capability of the XConverter message converter is called to perform message conversion to generate message data in the destination message format.

[0108] Among them, in the detailed implementation scheme of the XConverter message converter generating message definition data represented by a unified intermediate structure tree, the XConverter message converter parses message data of different message format types into an intermediate structure tree represented by unified structure nodes with the same meaning, and aligns the message structure tree formats of the different original message types to a level of interoperability and conversion, including the following steps:

[0109] The first step is to summarize and abstract four structural nodes that have common meanings in multiple message format types, such as loop node loopNode, object node objectnode, value node valuenode, attribute node attributenode, etc. These four nodes are used uniformly to build the intermediate structure tree.

[0110] The second step is to summarize and abstract 8 data value types with common meanings to represent the data type of values, such as TEXT text type, BOOLEAN Boolean type, LONG integer type, DATE date type, DECIMAL floating point type, NULL empty value type, DOCUMENTREF document object reference type, MISSING non-existent field value type, etc. These 8 data value types are uniformly used to describe the data type of the value of each valuenode value node and each attributenode attribute node in the intermediate structure tree.

[0111] Step 3: The XConverter message converter has a built-in message format base parser that implements common message format types such as XML, JSON, and CSV, and parses the input message data into the native message structure tree of each common message format type.

[0112] In step 4, the XConverter message converter traverses the native message structure tree generated in the previous step and translates the native structure nodes into structure nodes of a unified intermediate structure tree to form a new unified intermediate structure tree. After adding basic information such as the native message format type name, the intermediate structure tree is named MessageDefinition message structure definition object, and the message structure definition data is serialized and stored in the database.

[0113] Furthermore, in the detailed implementation scheme for the MCP Tool manager to generate mapping calculation rule data for each field value between message definition data represented by a unified intermediate structure tree, the MCP Tool manager uses the source message definition data and the destination message definition data as input parameters, and configures the mapping calculation relationship between the field values ​​of the two message definition data as needed by writing a SPEL value expression on the mapping relationship configuration page, including the following steps:

[0114] In the first step, the XConverter message converter specifies that the hierarchical positioning relationship of each structural node in the message data definition file, that is, the structure tree in the middle of the message, is described in the form of dotted ID to accurately locate and reference a certain node value.

[0115] For example: "{message definition data ID}:{root node ID}.{structure node ID}.{structure node ID}...{last layer ValueNode structure node ID}",

[0116] "{Message definition data ID}:{root node ID}.{Structure node ID}...{Last layer attributeNode structure node ID}"

[0117] In the second step, the XConverter message converter specifies the use of SPEL language to write node value expressions. When converting the message format, the value operation of the nodes in the structure tree in the middle of the destination message is calculated in accordance with the SPEL language operation specifications. One or more node values, a constant word or a NULL value, and a utility function or an addition, subtraction, multiplication and division operator can appear in the SPEL value expression as operands or operators. The XConverter message converter specifies the default operation rules for the loop node loopNode when calculating the mapping rules and provides some filtering functions and aggregation functions. For example, the two position markers fromindex and toindex or other filtering functions can be used to filter the data set under the loop node loopNode to obtain a subset, or all data sets under the loop node loopNode can be aggregated to obtain a single value.

[0118] In step 3, on the mapping relationship configuration interface of the MCP tool manager, expand the source message definition data structure and the destination message intermediate structure to clearly identify the structure node information and value type information contained in each message definition. Select a structure node in the destination message definition and edit its SPEL value expression to generate a message mapping rule between field values. After setting the SPEL value expression for one or more structure nodes in the destination message definition as needed, serialize and save them to the database to obtain persistent mapping rule data.

[0119] For example, configure a mapping conversion rule that combines two fields into one. The status and message fields in the source message definition data are combined into one to become the request status field in the destination message definition data. Its SPEL value expression is sid-901CAE1D:json.header.status+'('+sid-901CAE1D:json.header.message+')'. The amount and currency fields in the source message definition data are combined into one to become the transaction amount field in the destination message definition data. For example, Figure 6 As shown in the figure, its SPEL value expression is sid-901CAE1D:json.body.transaction.amount+sid-901CAE1D:json.body.transaction.currency. Here, sid-901CAE1D indicates the source message definition data ID, and json indicates the root node ID and message type.

[0120] For example, you can configure a mapping conversion rule to discard unnecessary attribute fields and not return them to the MCP client. This will directly discard the customer field in the source message definition data and prevent it from appearing in the destination message definition data.

[0121] For example, you can configure a mapping conversion rule that expands a multi-layered nested data structure into a flat structure. Intermediate structures such as the header, body, and transaction in the source message definition data are discarded and do not appear in the destination message definition data.

[0122] For example, configure a mapping conversion rule to convert the JSON object array format to CSV format. Add a headers structure node to CSV, change stock to product inventory, and name to product name. Direct the CSV LoopNode loop node to the LoopNode loop node of the JSON object array, and map the valuenodes under it one by one, such as Figure 7 shown.

[0123] like Figure 8 As shown, this is a specific flow chart of the XConverter message converter provided in an embodiment of the present application implementing message conversion. The XConverter message converter uses source message definition data, destination message definition data, message mapping calculation rule data, and message data in a specific source message format at runtime as input to generate a converted destination message data that conforms to the target message format. The specific steps are as follows:

[0124] Step 1: Call the base parser that is compatible with the message format type of the input message data to parse the input message data into a structure tree of its own message format type, such as an XML structure tree.

[0125] Step 2: Use the intermediate structure tree of the source message definition data as a reference standard and recursively check whether the structure nodes in the two structure trees are consistent.

[0126] In step 3, if inconsistent structure nodes are found during the structure tree verification process, the system returns "Conversion failed, input message data is inconsistent with the source message structure definition" and ends.

[0127] Step 4: Convert the data structure of the input message data into an intermediate structure tree. Each node in the intermediate structure tree carries the value of the input message data.

[0128] Step 5: Recursively traverse each node of the intermediate structure tree of the destination message, calculate the value of the destination node according to the mapping calculation rules of the SPEL value expression, and generate the intermediate structure tree of the destination message with value.

[0129] In step 6, based on the intermediate structure tree of the destination message with values ​​and the message format specified in the destination message definition, such as JSON / XML / CSV, call the writer outputter of the corresponding format to output the converted destination message data from the structure tree of the destination message with values.

[0130] This embodiment of the present application designs and implements an adapter conversion method and apparatus for publishing an API into an MCP tool. This method primarily publishes an existing API into an MCP tool by configuring message mapping conversion rules in configuration mode and performing message adaptation conversion actions based on these rules in runtime mode. This method enables the rapid conversion of existing APIs into tools that meet the MCP Model Context Protocol (MCP) tool specification through simple configuration, and publishes them to an MCP server for invocation by large language models with the assistance of MCP clients.

[0131] The embodiment of the present application also designs and implements an mcptool-api-adaptor adapter requester, which achieves adaptive conversion and semantic enhancement of the API message format through coordinated scheduling of multiple modules such as the MCP response message generator, semantic response message generator, API request message generator, XConverter message converter, HTTP API requester, and configuration of message definition data and message mapping conversion rule data based on the MCP tool manager and API manager.

[0132] The embodiment of the present application also designs and implements an XConverter message format converter, which abstractly summarizes multiple unified structure node types with common semantics and parses the message data into a unified intermediate structure tree based on the unified type structure nodes. It configures the SPEL value expression to establish a mapping conversion rule for how the field value of an intermediate structure tree is calculated through one or more field values ​​of another intermediate structure tree. It realizes the conversion from the source message to the destination message by calculating the SPEL value expression at runtime and serializing the string output of the message document object.

[0133] The embodiment of the present application also designs and implements a method for converting an API response message into a semantic response message. It achieves the semantic conversion of the API response message by converting the key names of ambiguous technical terms that are difficult for large language models to understand into easy-to-understand business term names with semantic information, converting enumeration attribute values ​​represented by numbers that are difficult to understand into easy-to-understand business term names with semantic information, merging or removing redundant nodes, flattening nested results, and converting the object array JSON message format into CSV format.

[0134] Compared with the prior art, the existing API in the embodiment of the present application does not require hard code modification. The adaptation of the MCP tool adaptation layer can be achieved through rule configuration, and the conversion from API to MCP tool can be achieved efficiently and at low cost; after the star message format conversion of the XConverter message converter, the conversion of the MCP tool request message to the API request message can be achieved, and the problem of asymmetric details of the request message can be handled; after the star message format conversion of the XConverter message converter, the API response message can be adapted to the semantic adaptation conversion that is friendly to the large language model (LLM) and is easy to understand and unambiguous; after the star message format conversion of the XConverter message converter, the API response message can be simplified, and the number of unnecessary tokens occupied by the large language model (LLM) can be reduced; the existing API itself does not need to pay attention to whether the request path comes from the MCP Server entrance or the traditional API entrance, and the lifecycle management, monitoring, current limiting and circuit breaking and other governance measures of the already built API can still continue to be reused.

[0135] like Figure 9 FIG. 1 is a schematic diagram of a structure of a publishing device for an MCP tool provided in an embodiment of the present application, including:

[0136] Configuration module 910 is configured to configure, through the MCP tool manager, a first mapping relationship, a second mapping relationship, and a correspondence between the MCP tool and the API, and publish the MCP tool to a tool list visible to the MCP client; the first mapping relationship is a mapping relationship between an API request message and an MCP tool request message, and the second mapping relationship is a mapping relationship between a semantic response message and an API response message.

[0137] Specifically, the configuration module 910 is specifically used to parse the message data in the source message format into the intermediate structure tree of the source message through the message parser of the XConverter message converter; parse the message data in the destination message format into the intermediate structure tree of the destination message through the message parser of the XConverter message converter; based on the node value addressing reference rules of the intermediate structure tree specified by the XConverter message converter and the support for SPEL value expressions, configure and construct the mapping or calculation rules between the field values ​​of the intermediate structure tree of the source message and the intermediate structure tree of the destination message; wherein, the conversion capability of the XConverter message converter executes the SPEL value expression configured in the mapping rule to complete the conversion from the source message to the destination message; when the source message is an MCP tool request message, the destination message is an API request message; when the source message is an API response message, the destination message is a semantic response message.

[0138] In this embodiment, the configuration module 910 is specifically used to summarize and abstract four structural nodes with common meanings in multiple message format types through the XConverter message converter, and uniformly use the four structural nodes to build an intermediate structure tree, the four structural nodes include loop nodes loopNode, object nodes objectnode, value nodes valuenode and attribute nodes attributenode; summarize and abstract eight data value types with common meanings to represent the data type of the value through the XConverter message converter, and uniformly use the eight data value types to describe the data type of the value of each valuenode value node and each attributenode attribute node in the intermediate structure tree, the eight data value types include TEXT text type , BOOLEAN Boolean type, LONG integer type, DATE date type, DECIMAL floating point type, NULL null value type, DOCUMENTREF document object reference type and MISSING non-existent field value type; through the message format base parser parser built into the XConverter message converter, the input message data is parsed into the native message structure tree of the message format type; through the XConverter message converter, the native message structure tree is traversed, the native structure nodes are translated into the structure nodes of the unified intermediate structure tree to form a new unified intermediate structure tree, and after the native message format type name is supplemented in the new unified intermediate structure tree, the new unified intermediate structure tree is named MessageDefinition message structure definition object and serialized.

[0139] The first conversion module 920 is configured to, after receiving the MCP tool request message through the access layer tool executor, convert the MCP tool request message into a corresponding API request message according to the first mapping relationship, and forward the API request message to the upstream service.

[0140] Specifically, the first conversion module 920 is specifically configured to call a base parser that is compatible with the message format type of the source message through the XConverter message converter to parse the source message into a structure tree of its own message format type; use the intermediate structure tree of the source message definition data as a reference standard through the XConverter message converter to recursively verify, node by node, whether the structure nodes in the intermediate structure tree of the source message and the intermediate structure tree of the destination message are consistent; if inconsistent structure nodes are found during the structure tree verification process, a failure message is returned; otherwise, the structure tree of the source message's own data type is converted into an intermediate structure tree representation, where each node in the intermediate structure tree carries the value of the source message; recursively traverse each node of the intermediate structure tree of the destination message, calculate the value of the destination node according to the mapping calculation rules of the SPEL value expression, and generate an intermediate structure tree of the destination message with a value; based on the intermediate structure tree and the message format specified in the destination message definition, call a writer outputter of the corresponding format to output the intermediate structure tree as converted destination message data.

[0141] The second conversion module 930 is used to obtain the API response message returned by the upstream service, and convert the API response message into a corresponding semantic response message according to the second mapping relationship.

[0142] The second conversion module 930 is specifically configured to take the API response message data, API response message definition information, semantic response message definition information, and the second mapping relationship information as input parameters and call the MCP response message generator; delegate the message conversion request to the semantic response message generator through the MCP response message generator, and call the message conversion capability of the XConverter message converter through the semantic response message generator with the API response message data, API response message definition information, semantic response message definition information, and the second mapping relationship information as input parameters to convert the API response message data into a semantic response message.

[0143] In this embodiment, the above-mentioned device further includes:

[0144] an acquisition module, configured to acquire, based on the MCP tool corresponding to the MCP tool request message, API information, API request message definition information, API response message definition information, MCP tool request message definition information, semantic response message definition information, the first mapping relationship, and the second mapping relationship corresponding to the MCP tool, wherein the API information includes an API type and an API upstream URL;

[0145] Correspondingly, the first conversion module 920 is specifically used to call the mcptool-api-adaptor adapter requester with the API information and the MCP tool request message information as input parameters; call the API request message generator through the mcptool-api-adaptor adapter requester, and use the MCP tool request message data, MCP tool request message definition information, API request message definition information and the first mapping relationship as input parameters through the API request message generator, and call the message conversion capability of the XConverter message converter to convert the MCP tool request message data into API request message data.

[0146] The embodiment of the present application can realize the conversion from API to MCP tool efficiently and at low cost based on the mapping relationship between messages, without the need for hard modification of existing API code and avoiding the occupation of unnecessary large language model tokens.

[0147] The present application also provides a computer-readable storage medium having a computer program stored thereon. When executed by a processor, the computer program implements the various processes of the aforementioned MCP tool publishing method embodiment and achieves the same technical effects. To avoid repetition, the details are not described here. The computer-readable storage medium may be, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0148] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0149] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0150] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of this application, ordinary technicians in this field can also make many forms without departing from the purpose of this application and the scope of protection of the claims, all of which are within the protection of this application.

Claims

1. A method for publishing a Model Context Protocol (MCP) tool, characterized in that: The following steps are involved: Configure the first mapping relationship, the second mapping relationship, and the correspondence between the MCP tool and the API through the MCP tool manager, and publish the MCP tool to the tool list visible to the MCP client; The first mapping relationship is a mapping relationship between an API request message and an MCP tool request message, and the second mapping relationship is a mapping relationship between a semantic response message and an API response message; After receiving the MCP tool request message through the access layer tool executor, convert the MCP tool request message into a corresponding API request message according to the first mapping relationship, and forward the API request message to the upstream service; Obtain the API response message returned by the upstream service, and convert the API response message into a corresponding semantic response message according to the second mapping relationship.

2. The method according to claim 1, characterized in that Before converting the MCP tool request message into a corresponding API request message according to the first mapping relationship, the method further includes: According to the MCP tool corresponding to the MCP tool request message, obtain API information corresponding to the MCP tool, API request message definition information, API response message definition information, MCP tool request message definition information, semantic response message definition information, the first mapping relationship, and the second mapping relationship, wherein the API information includes an API type and an API upstream URL; The converting, according to the first mapping relationship, the MCP tool request message into a corresponding API request message specifically includes: Call the mcptool-api-adaptor adapter requester with the API information and the MCP tool request message information as input parameters; The API request message generator is called through the mcptool-api-adaptor adapter requester, and the API request message generator takes the MCP tool request message data, MCP tool request message definition information, API request message definition information and the first mapping relationship as input parameters, and calls the message conversion capability of the XConverter message converter to convert the MCP tool request message data into API request message data.

3. The method according to claim 2, characterized in that The converting of the API response message into a corresponding semantic response message according to the second mapping relationship specifically includes: Calling the MCP response message generator with the API response message data, API response message definition information, semantic response message definition information, and the second mapping relationship information as input parameters; The MCP response message generator delegates the message conversion request to the semantic response message generator, and the semantic response message generator takes the API response message data, API response message definition information, semantic response message definition information and the second mapping relationship information as input parameters, calls the message conversion capability of the XConverter message converter, and converts the API response message data into a semantic response message.

4. The method according to claim 1, wherein Configuring the first mapping relationship and the second mapping relationship through the MCP tool manager specifically includes: The message parser of the XConverter message converter parses the message data in the source message format into an intermediate structure tree of the source message; The message parser of the XConverter message converter parses the message data in the target message format into an intermediate structure tree of the target message; Based on the node value addressing reference rules of the intermediate structure tree specified by the XConverter message converter and the support for SPEL value expressions, configure and construct the mapping or calculation rules between the field values ​​of the intermediate structure tree of the source message and the intermediate structure tree of the destination message; Among them, the conversion capability of the XConverter message converter executes the SPEL value expression configured in the mapping rule to complete the conversion of the source message to the destination message; when the source message is an MCP tool request message, the destination message is an API request message; when the source message is an API response message, the destination message is a semantic response message.

5. The method according to claim 4, characterized in that Parsing message data of different message format types into an intermediate structure tree by the XConverter message converter specifically includes: The XConverter message converter summarizes and abstracts four structural nodes that have common meanings in multiple message format types, and uniformly uses the four structural nodes to build an intermediate structure tree. The four structural nodes include loop node loopNode, object node objectnode, value node valuenode and attribute node attributenode; The XConverter message converter summarizes and abstracts 8 data value types with common meanings to represent the data type of the value, and uniformly uses the 8 data value types to describe the data type of the value of each valuenode value node and each attributenode attribute node in the intermediate structure tree. The 8 data value types include TEXT text type, BOOLEAN Boolean type, LONG integer type, DATE date type, DECIMAL floating point type, NULL null value type, DOCUMENTREF document object reference type and MISSING non-existent field value type; Parse the input message data into a native message structure tree of the message format type through the message format base parser built into the XConverter message converter; The native message structure tree is traversed by the XConverter message converter, and the native structure nodes are converted into structure nodes of the unified intermediate structure tree to form a new unified intermediate structure tree. After the native message format type name is added to the new unified intermediate structure tree, the new unified intermediate structure tree is named as a MessageDefinition message structure definition object and serialized; The conversion capability of the XConverter message converter is used to convert the source message into the destination message, specifically including: The XConverter message converter calls a base parser that is adapted to the message format type of the source message to parse the source message into a structure tree of its own message format type; The XConverter message converter uses the intermediate structure tree of the source message definition data as a reference standard to recursively check whether the structure nodes in the intermediate structure tree of the source message and the intermediate structure tree of the destination message are consistent in structure node by node; If inconsistent structural nodes are found during the structure tree verification process, a failure message is returned; otherwise, the structure tree of the source message's own data type is converted into an intermediate structure tree representation, and each node in the intermediate structure tree carries the value of the source message; each node of the intermediate structure tree of the destination message is recursively traversed, and the value of the destination node is calculated according to the mapping calculation rules of the SPEL value expression, and an intermediate structure tree of the destination message with a value is generated; based on the intermediate structure tree and the message format specified in the destination message definition, the writer outputter of the corresponding format is called to output the intermediate structure tree as the converted destination message data.

6. A publishing device for an MCP tool, characterized in that: include: A configuration module, configured to configure the first mapping relationship, the second mapping relationship, and the correspondence between the MCP tool and the API through the MCP tool manager, and publish the MCP tool to a tool list visible to the MCP client; The first mapping relationship is a mapping relationship between an API request message and an MCP tool request message, and the second mapping relationship is a mapping relationship between a semantic response message and an API response message; A first conversion module is configured to, after receiving an MCP tool request message through the access layer tool executor, convert the MCP tool request message into a corresponding API request message according to the first mapping relationship, and forward the API request message to an upstream service; The second conversion module is used to obtain the API response message returned by the upstream service, and convert the API response message into a corresponding semantic response message according to the second mapping relationship.

7. The device according to claim 6, characterized in that Also includes: an acquisition module, configured to acquire, based on the MCP tool corresponding to the MCP tool request message, API information, API request message definition information, API response message definition information, MCP tool request message definition information, semantic response message definition information, the first mapping relationship, and the second mapping relationship corresponding to the MCP tool, wherein the API information includes an API type and an API upstream URL; The first conversion module is specifically used to call the mcptool-api-adaptor adapter requester with the API information and the MCP tool request message information as input parameters; call the API request message generator through the mcptool-api-adaptor adapter requester, and use the MCP tool request message data, MCP tool request message definition information, API request message definition information and the first mapping relationship as input parameters through the API request message generator, and call the message conversion capability of the XConverter message converter to convert the MCP tool request message data into API request message data.

8. The device according to claim 7, characterized in that The second conversion module is specifically configured to take the API response message data, the API response message definition information, the semantic response message definition information, and the second mapping relationship information as input parameters and call the MCP response message generator; The MCP response message generator delegates the message conversion request to the semantic response message generator, and the semantic response message generator takes the API response message data, API response message definition information, semantic response message definition information and the second mapping relationship information as input parameters, calls the message conversion capability of the XConverter message converter, and converts the API response message data into a semantic response message.

9. The device according to claim 6, characterized in that The configuration module is specifically used to parse the message data in the source message format into the intermediate structure tree of the source message through the message parser of the XConverter message converter; parse the message data in the destination message format into the intermediate structure tree of the destination message through the message parser of the XConverter message converter; based on the node value addressing reference rules of the intermediate structure tree specified by the XConverter message converter and the support for SPEL value expressions, configure and construct the mapping or calculation rules between the field values ​​of the intermediate structure tree of the source message and the intermediate structure tree of the destination message; wherein, the conversion capability of the XConverter message converter executes the SPEL value expression configured in the mapping rule to complete the conversion from the source message to the destination message; when the source message is an MCP tool request message, the destination message is an API request message; when the source message is an API response message, the destination message is a semantic response message.

10. The device according to claim 9, characterized in that The configuration module is specifically used to summarize and abstract four structural nodes with common meanings in multiple message format types through the XConverter message converter, and uniformly use the four structural nodes to build an intermediate structure tree, the four structural nodes include loop node loopNode, object node objectnode, value node valuenode and attribute node attributenode; summarize and abstract eight data value types with common meanings through the XConverter message converter to represent the data type of the value, and uniformly use the eight data value types to describe the data type of the value of each valuenode value node and each attributenode attribute node in the intermediate structure tree, the eight data value types include TEXT text type, BOO LEAN Boolean type, LONG integer type, DATE date type, DECIMAL floating point type, NULL null value type, DOCUMENTREF document object reference type and MISSING non-existent field value type; using the message format base parser parser built into the XConverter message converter, the input message data is parsed into a native message structure tree of the message format type; the XConverter message converter traverses the native message structure tree, translates the native structure nodes into structure nodes of a unified intermediate structure tree, forms a new unified intermediate structure tree, and after adding the native message format type name to the new unified intermediate structure tree, the new unified intermediate structure tree is named MessageDefinition message structure definition object and serialized; The first conversion module and the second conversion module are specifically configured to call a base parser that is compatible with the message format type of the source message through the XConverter message converter to parse the source message into a structure tree of its own message format type; and recursively verify, node by node, whether the structure nodes in the intermediate structure tree of the source message and the intermediate structure tree of the destination message are consistent with each other using the intermediate structure tree of the source message definition data as a reference standard through the XConverter message converter. If inconsistent structure nodes are found during the structure tree verification process, a failure message will be returned; Otherwise, converting the structure tree of the data type of the source message into an intermediate structure tree representation, wherein each node in the intermediate structure tree carries the value of the source message; Recursively traverse each node of the intermediate structure tree of the destination message, calculate the value of the destination node according to the mapping calculation rules of the SPEL value expression, and generate the intermediate structure tree of the destination message with the value; Based on the intermediate structure tree and the message format specified in the destination message definition, a writer outputter of a corresponding format is called to output the intermediate structure tree as converted destination message data.

Images