A method and apparatus for releasing an MCP tool

Abstract

The embodiment of the application discloses a method and device for publishing MCP tools, which comprises the following steps: configuring a first mapping relationship, a second mapping relationship and a corresponding relationship between the MCP tool and an API through an MCP tool manager, and publishing the MCP tool to a tool list visible to an MCP client; after receiving an MCP tool request message through an access layer tool executor, converting the MCP tool request message into a corresponding API request message according to the first mapping relationship, and forwarding the API request message to an upstream service; 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 mapping relationship between the messages, the embodiment of the application can efficiently and at low cost realize the conversion from the API to the MCP tool, and does not need to hard modify the existing API code.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a method and apparatus for publishing an MCP tool. Background Technology

[0002] MCP (Model Context Protocol) is a groundbreaking public protocol in the field of large model technology that enables AI agents to use tools. In terms of tool invocation, it provides standardized specifications for traditional FunctionCallback invocation in terms of message specifications, interaction flow, error codes, and lifecycle management.

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

[0004] Application content

[0005] The purpose of this application is to provide a method and apparatus for releasing an MCP tool to address the shortcomings of existing technologies, which involve a large workload in development and testing.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows:

[0007] Firstly, a method for publishing an MCP tool is provided, including the following steps:

[0008] Configure the first mapping relationship, the second mapping relationship, and the correspondence between MCP tools and APIs through the MCP tool manager, and publish the MCP tools to the tool list visible to the MCP client; the first mapping relationship is the mapping relationship between API request messages and MCP tool request messages, and the second mapping relationship is the mapping relationship between semantic response messages and API response messages;

[0009] After receiving the MCP tool request message through the access layer tool executor, the MCP tool request message is converted into a corresponding API request message according to the first mapping relationship, and the API request message is forwarded 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] Secondly, a distribution device for MCP tools is provided, comprising:

[0012] The configuration module is used to configure the first mapping relationship, the second mapping relationship, and the correspondence between MCP tools and APIs through the MCP tool manager, and to publish the MCP tools to the tool list visible to the MCP client; the first mapping relationship is the mapping relationship between API request messages and MCP tool request messages, and the second mapping relationship is the mapping relationship between semantic response messages and API response messages;

[0013] The first conversion module is used to convert the MCP tool request message into a corresponding API request message according to the first mapping relationship after receiving the MCP tool request message through the access layer tool executor, and forward the API request message to the 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] Based on the mapping relationship between messages, the embodiments of this application can efficiently and cost-effectively convert APIs to MCP tools without requiring hard modifications to existing API code and avoiding unnecessary token consumption for large language models. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a method for publishing an MCP tool provided in an embodiment of this application;

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

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

[0019] Figure 4 This is a schematic diagram of the configuration mapping and transformation rules for API request messages provided in the embodiments of this application;

[0020] Figure 5 This is a schematic diagram illustrating the specific process of message conversion provided in the embodiments of this application;

[0021] Figure 6 This is a schematic diagram of the mapping and transformation rule that combines two fields into one, provided in an embodiment of this application;

[0022] Figure 7This is a schematic diagram illustrating the mapping and conversion rules for converting a JSON object array format to a CSV format, as provided in an embodiment of this application.

[0023] Figure 8 This is a flowchart illustrating the specific process of message conversion implemented by the XConverter message converter provided in this application embodiment;

[0024] Figure 9 This is a schematic diagram of the structure of an MCP tool publishing device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] The MCP protocol provides detailed specifications for the request and response message formats of tools. When vertical SaaS platform enterprises build their own MCP Servers and publish their own MCP tools, they face three typical problems. One is that the request and response messages of existing APIs are not compatible with the MCP protocol specifications. Another is that the key names of the data fields in the API response messages are abbreviated in English or in Pinyin, resulting in weak semantic information and hindering the accurate understanding of the LLM model. The third is that API response messages generally return a lot of detailed data. If all of it is returned to the LLM model, the token cost will be high. However, some details in the response messages can be merged, and some details can be filtered out.

[0027] Generally, when faced with these three issues, SaaS platform companies first modify the code of existing APIs. This involves adding code to adapt to the MCP tool request message format when parsing request message data based on different entry paths or request source identifiers, and adding semantic adaptation and conversion code before returning response message data to facilitate understanding by large-scale LLM models. Then, different entry paths are configured in the load balancer or NGINX, or path marker header information is added under the same path. This approach has two significant drawbacks. First, the cost of modifying and testing the code is high, and the deployment speed is slow, hindering the rapid and large-scale reuse of existing API assets. Second, because requests to the API from the original request path and requests to the API from the new MCP tool request path will coexist, operations personnel need to add some kind of path identification marker for hard-coded logic for identification. They also need to simultaneously monitor API requests from the MCP tool request path and implement governance measures such as rate limiting and circuit breaking. All of these factors contribute to high operational costs and low reuse rates of existing governance methods.

[0028] To address the three issues mentioned above, this application proposes an MCP tool adaptation layer. Without modifying the API code, existing APIs can be published as tools conforming to the MCP protocol after being converted by the MCP tool adapter. This allows for the rapid provision of MCP tools for numerous AI agents, accelerating the implementation of AI strategic transformation for vertical SaaS companies. The aforementioned MCP tool adaptation layer has three advantages: First, it extracts the hard-coded adaptation work necessary for adapting APIs one by one to an MCP tool, such as message format conversion, semantic enhancement, and detail filtering and hiding, into a common, reusable, and configurable capability layer. These adaptation conversions are completed through configuration. Second, the semantic conversion of API response messages implemented by the adaptation layer enhances semantic information, filters out useless information, and reduces the token burden of large language models. Third, there is still only one set of APIs; the API itself does not need to concern itself with the origin of the request path, and existing governance mechanisms such as monitoring, rate limiting, and circuit breaking can still be reused.

[0029] This application focuses on the MCP Tool-API adapter, which uses the coordinated work of several components such as 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 adaptation and conversion of traditional existing APIs to MCP tools.

[0030] Specifically, the MCP Tool-API adapter internally includes an XConverter message converter. The XConverter 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 includes an HTTP client that initiates HTTP requests to upstream services, which can be built using Java, Node.js, or Python. The input and output parameters of the upstream service's API can be in SOAP, JSON, CSV, or fixed-length message formats.

[0031] The following description, in conjunction with the accompanying drawings, details the method for publishing the MCP tool provided in this application through specific embodiments and application scenarios.

[0032] like Figure 1 The diagram shown is a flowchart of a method for publishing an MCP tool according to an embodiment of this application. The method includes the following steps:

[0033] Step 101: Configure the first mapping relationship, the second mapping relationship, and the correspondence between MCP tools and APIs through the MCP tool manager, and publish the MCP tools to the tool list visible to the MCP client; the first mapping relationship is the mapping relationship between API request messages and MCP tool request messages, and the second mapping relationship is the mapping relationship between semantic response messages and API response messages.

[0034] Specifically, the message parser of the XConverter message converter can parse 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 can also parse the message data in the destination message format into the intermediate structure tree of the destination message; based on the node value addressing and referencing rules of the intermediate structure tree specified by the XConverter message converter and its 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 can be configured and constructed.

[0035] The XConverter message converter executes the SPEL value expression configured in the mapping rules to complete the conversion from source message to 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 summarize and abstract four structural nodes that share common meanings across various message format types, and uniformly use these four structural nodes to construct the intermediate structure tree. These four structural nodes include loopNode, objectNode, valueNode, and attributeNode. The XConverter message converter can also summarize and abstract eight data value types that share common meanings to represent data types, and uniformly use these eight data value types to describe the data types of the values ​​of each valueNode and attributeNode in the intermediate structure tree. These eight data value types include TEXT (text type), BOOL (text type), and so on. The XConverter message converter accepts EAN (boolean), LONG (integer), DATE (date), DECIMAL (floating-point), NULL (null), DOCUMENTREF (document object reference), and MISSING (non-existent field value). Using the built-in message format base parser, the XConverter parses the input message data into a native message structure tree of the specified message format type. The XConverter then traverses this native message structure tree, translating the native structure nodes into structure nodes of a unified intermediate structure tree, forming a new unified intermediate structure tree. After adding the native message format type name to this new unified intermediate structure tree, it is named a MessageDefinition message structure definition object and serialized.

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

[0038] In this embodiment, before converting the MCP tool request message into the corresponding API request message according to the first mapping relationship, the 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 can be obtained according to the MCP tool corresponding to the MCP tool request message. The API information includes API type and API upstream URL.

[0039] Accordingly, the mcptool-api-adaptor is invoked using the API information and the MCP tool request message information as input parameters. The mcptool-api-adaptor then invokes the API request message generator, which in turn invokes the XConverter message converter's message conversion capabilities to convert the MCP tool request message data into API request message data using the MCP tool request message data, the MCP tool request message definition information, the API request message definition information, and the first mapping relationship as input parameters.

[0040] Furthermore, the XConverter message converter can call a base parser 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. Using the intermediate structure tree of the source message definition data as a reference standard, the XConverter message converter recursively verifies the structural nodes of the intermediate structure tree of the source message and the intermediate structure tree of the destination message to ensure structural consistency. If inconsistent structural nodes are found during the structure tree verification, 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. 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, generating an intermediate structure tree of the destination message with values. Based on the intermediate structure tree and the message format specified in the destination message definition, the corresponding format writer outputter is called 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 MCP response message generator delegates the message conversion request to the semantic response message generator; 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] Based on the mapping relationship between messages, the embodiments of this application can efficiently and cost-effectively convert APIs to MCP tools without requiring hard modifications to existing API code and avoiding unnecessary token consumption for large language models.

[0044] In this embodiment, the adapter conversion method for publishing an API as an MCP tool includes configuring message mapping conversion rules in a configuration state and implementing message adaptation conversion actions based on the mapping conversion rules in a runtime state, thereby publishing the existing API as an MCP tool. This achieves the goal of quickly converting existing APIs into tools that meet the requirements of the MCP Model Context Protocol tool specification through simple configuration and publishing them on the MCP server for large language models to call with the assistance of the MCP Client.

[0045] Specifically, the MCP Server's server-side program provides standard SSE endpoints and MCP message endpoints on the public internet. Various large-scale LLM models call the MCP tools provided by the MCP Server through the MCP Client program. SSE (Server Send Event) is a one-way communication technology based on the HTTP protocol, allowing the server to proactively 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 tool calls to the MCP Server. Request messages conforming to the MCP protocol tool specification enter the MCP Server through the MCP message endpoint, and response messages conforming to the MCP protocol tool specification are returned to the MCP client via the SSE persistent connection in event format.

[0046] like Figure 2 The diagram shown illustrates a specific implementation of the MCP tool publishing method provided in this application, comprising the following steps:

[0047] Step 1: Issue and manage API key request identity information by calling the MCP API key manager.

[0048] Step 2: Manage the APIs by calling the API Manager. Configure and save basic API information, API request message definitions, API response message definitions, API upstream URL forwarding addresses, etc.

[0049] Step 3: Manage tools by calling the MCP tool manager. This includes configuring the mapping between tools and APIs, configuring the publishing of tools to the toolslist so that they are visible to the MCP client, 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 APIs that require adaptation.

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

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

[0052] Step 6: The MCP Server's MCP message executor is responsible for identifying different types of message requests and, depending on the type, calling the initialize executor, tools / list executor, notify executor, and access layer tool executor respectively to execute the message request execution logic. 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 of the MCP tool request, the access layer tool executor of the MCP Server directly delegates the call to the execution layer tool executor, and returns upwards after receiving the response.

[0054] Step 8: After receiving the request, the execution layer tool executor first calls the tool-api mapping manager to retrieve the API information corresponding to the tool. This API information includes basic information such as the API type and API upstream URL. If the API requires adaptation, the tool-api mapping manager continues to retrieve the API request message definition, API response message definition, MCP tool request message definition, semantic response message definition, mapping relationship between API request messages and MCP tool request messages, and mapping relationship between semantic response messages and API response messages—configuration information needed for message conversion. If the API does not require adaptation, the access layer tool executor directly calls the HTTP API requester, forwarding the MCP tool request message to the upstream service program via HTTP RPC call and returning the response message after receiving it. If the API requires adaptation, the access layer tool executor uses all API information and MCP tool request message information as input parameters to call the mcptool-api-adaptor adapter requester. The mcptool-api-adaptor adapter requester completes the API adaptation and forwarding of the call. The access layer tool executor then returns the adapted response message returned by the mcptool-api-adaptor adapter requester upwards.

[0055] Step 9: Upon receiving the request, the mcptool-api-adaptor first calls the API request message generator to convert the MCP tool request message into an 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 information between the API request message and the MCP tool request message as input parameters, and uses the XConverter message converter's message conversion capabilities to convert the MCP tool request message data into API request message data. Then, the mcptool-api-adaptor calls the HTTP API requester to transmit the API request message data via HTTP. The API response message is forwarded to the upstream service via RPCcall and the API response message data is obtained. Then, the API response message data, API response message definition information, semantic response message definition information, and the mapping relationship between semantic response messages and API response messages are used as input parameters to call the MCP response message generator. The MCP response message generator delegates the request to the semantic response message generator to convert the API response message data into a semantically friendly and concise API response message. After the MCP response message generator obtains the semantically friendly and concise API response message, it calls the tostring serialization method to generate a result string, assigns it to the text field value in the MCP tool response message format, generates the MCPtool response message, and returns it upwards.

[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 upwards.

[0057] In this embodiment, the MCP Tool-API adapter includes an API key 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 API key manager is responsible for the issuance and management of API keys. An API key is a tool access credential issued offline by the MCP server to the MCP client before the MCP client initiates an SSE long-connection establishment and message request to the MCP server. The API key data model includes key information such as the API key, API key holder, API key issuance date, and API key status. API key status typically includes several states such as active, frozen, and invalid.

[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 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, and the API request forwarding URL refers to the fully qualified URL of the microservice to which the API request is forwarded.

[0060] The MCP tool manager is responsible for managing MCP tools, encompassing three main tasks: tool registration and management, tool-API mapping management, and tool publishing (toolslist) management. Administrators register and manage basic tool information; the MCP tool model includes key information such as toolID, tool name, tool function description, and tool request message definition data. Administrators configure and manage which API a tool uses to perform its functions; the tool-API mapping model includes tool ID, apiID, a flag indicating whether forwarding adaptation is needed, mapping rules between API request messages and MCP tool request messages, and mapping rules between semantic response messages and API response messages. Depending on whether an API call requires an adapter, a forwarding flag needs to be set when configuring the tool and API mapping relationship. One type of API does not require message format adaptation through the `mcptool-api-adaptor` requester. These APIs are generally newly developed APIs that conform to the MCP tool request and response message format specifications, and do not require mapping rule configuration. The other type requires message format adaptation through the `mcptool-api-adaptor` requester. These APIs require additional configuration of mapping rules between API request messages and MCP tool request messages, and between semantic response messages and API response messages. Message mapping rules are configured on the MCP tool manager's message mapping rule configuration page. This is accomplished using the XConverter message converter's ability to parse message data into an intermediate structure tree and establish mapping relationships based on that intermediate structure tree. Administrators configure the publishing relationship between tools and toolslist. Administrators can publish tools to the toolslist for MCP Clients to use. Administrators can also unpublish or temporarily freeze the publishing status of tools to prevent MCP Clients from using them.

[0061] The XConverter message converter is responsible for parsing message data of different formats to construct a unified intermediate structure tree, and establishing mapping rules based on the intermediate structure tree to achieve mutual conversion between message data. XConverter possesses message data parsing capabilities (parser), message data conversion capabilities (converter), and serialization and string generation capabilities (writer). It is designed primarily to implement star-structured message format conversion. On the message mapping rule configuration page of the MCP tool manager described in this invention patent, when administrators configure the conversion rules for JSON RPC format request messages to API request messages and API response messages to semantic response messages in the MCP tool, the underlying implementation is all done through the capabilities of the XConverter message converter.

[0062] Specifically, the star-structured message format conversion of the XConverter message converter, such as... Figure 3 As shown, the process includes the following steps: The XConverter message parser parses the message data in the source message format into an intermediate structure tree of the source message; the XConverter message parser parses the message data in the destination message format into an intermediate structure tree of the destination message; based on the node value addressing and referencing rules of the intermediate structure tree specified by the XConverter message converter and its support for SPEL value expressions, a mapping or calculation rule between the field values ​​of the two intermediate structure trees is configured and constructed; at runtime, the XConverter message converter's conversion capability is invoked to execute the SPEL value expressions configured in the mapping rules to complete the conversion from source message data to 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, such as from a nested JSON structure to a flattened JSON structure, from a rich number of fields in JSON to a concise number of fields in JSON, from English field names in JSON to semantic field names in JSON, etc.

[0063] The API request message generator is responsible for converting the request messages specified by the MCP protocol into API request messages that the API can understand. It takes the MCP tool request message, the MCP tool request message definition data, the 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 capability of the XConverter message converter to complete this task.

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

[0065] Configure 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 As shown. (2) The accuracy fuzzy search configuration parameter and sort result sorting configuration parameter in the API request message definition are not exposed to the MCP tool. When the MCP tool request arrives, the API is uniformly sorted using "accuracy":fase fuzzy search and "sort":{"frequency":0} descending order.

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

[0067]

[0068] XConverter converts API request messages using the configured mapping rules between API request messages and MCP tool request messages, resulting in the API request message:

[0069]

[0070]

[0071] The semantic response message generator is responsible for converting API response messages into semantic response messages with certain semantic information that are 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, and calls the conversion capabilities of the XContverter message converter to complete this task, returning a DocumentObject of the semantic response message. Generally, the size and structure of the converted semantic response message data will change. An important prerequisite for semantic response message conversion is that the administrator needs to configure the mapping rules between the semantic response message definition data and the API response message definition data on the MCP tool manager's message mapping rule configuration page.

[0072] This application provides several main mapping and transformation rules for semantic transformation, which enhance semantics, make the structure more compact, and reduce the token count of large models. Details are as follows:

[0073] (1) Perform semantic conversion on key names and field enumeration values ​​to make them concise and easy to understand.

[0074] API response messages are generally designed for reading in programming languages, with the API requester following the API's input and output parameter conventions in their programming and usage. With the rise of Large Language Modeling (LLM) and AI Agent technologies, MCP tool response messages are now read and understood by large models, approximating natural language. This places higher demands on the accuracy, unambiguity, and comprehensibility of field key names in the response messages. Practices in API response messages that use pinyin abbreviations, technical English acronyms, or even different numbers to represent semantics require semantic enhancement to prevent the large language model from misinterpreting and associating them with unexpected knowledge.

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

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

[0077]

[0078] The converted semantic response message is as follows:

[0079]

[0080] (2) Convert the JSON object array to CSV format, and perform semantic transformation on key names and field enumeration values ​​to enhance semantics and save the number of token characters occupied by the key.

[0081] When performing list queries, APIs typically return a response message containing an array of JSON objects. For these messages, we perform semantic conversion on key names and field enumeration values. Furthermore, to reduce the impact of repeated key names on the large language model's token count, we convert the JSON object array message format to a CSV message format, making the response message more compact. For example, we convert the key name `id` to "Product ID", `name` to "Product Name", `category` to "Product Category", and `stock` to "Product Inventory".

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

[0083]

[0084] The converted semantic response message is as follows:

[0085] Product ID, Product Name, Product Category, Product Inventory

[0086] P100, LCD monitor, electronics, 15

[0087] P101, ballpoint pen, stationery, 34

[0088] P102, Bluetooth Mouse, Electronic, 25

[0089] (3) Convert the multi-level nested JSON structure into a flat structure, 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 containment relationships are common in business models, which often results in multi-level nested JSON structures in API response messages. For the same number of core attribute information, a multi-level nested structure will occupy several more object type key names than a flat structure. For program reading and calculation purposes, quantity and unit information are stored in two attribute fields. When providing LLM (Large Language Model) reading and understanding, quantity and unit can be combined into a single string, saving one key name. For business modeling needs, object information is self-integrated and contains a lot of detailed information, but some attribute information is secondary; omitting it does not affect the display of the core attribute information.

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

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

[0093]

[0094]

[0095] The converted semantic response message is as follows:

[0096]

[0097] The MCP response message generator is responsible for converting API response messages into MCP tool response messages. 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 to call the semantic response message generator. For the DocumentObject document returned by the semantic response message generator (JSON or CSV), it calls the DocumentObject's serialization function `writer` to generate a string, which is then assigned to the `result.content.text` field to complete this task. As described in this patent, the semantic response message generator utilizes the conversion capabilities of the XContverter message converter to perform this semantic conversion.

[0098] If the semantic response message generator returns JSON message data, its DocumentObject writer message serializer generates a JSON string. For example, {"Request Status":"Request Successful (200)","Processing Time":"2025-05-10T12:34:16Z","Returned 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 Markdown table-style string. For example, \n|Product ID|Product Name|Product Category|Product Inventory|\n|:---|:---|:---|:---|\n|P100|LCD Monitor|Electronics|15|\n|P101|Pen|Stationery|34|\n|P102|Bluetooth Mouse|Electronics|25|\n.

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

[0101]

[0102]

[0103] The `mcptool-api-adaptor` handles scheduling. In runtime, it invokes the API request message generator, HTTP API requester, and MCP tool response message generator at appropriate times. By forwarding calls to upstream microservice APIs and adapting data message formats, it adapts and calls to the original APIs carrying the MCP tool functionality. Its interaction with the upper-layer MCP tool executor follows the request and response message formats specified by the MCP protocol.

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

[0105] Specifically, in step 1, the source packet data in the source packet format and the destination packet data in the destination packet format are retrieved, uploaded, or edited through the MCP tool manager. The XConverter packet converter is then called to generate source packet definition data and destination packet definition data represented by a unified intermediate structure tree, which are then stored persistently in the database.

[0106] Step 2: Retrieve the source and destination message definition data represented by the unified intermediate structure tree from the database using the MCP tool manager. Establish the mapping calculation rules between the field values ​​of the destination message definition data and the field values ​​of the source message definition data by writing SPEL value expressions. Then, persist the mapping calculation rule data into the database.

[0107] Step 3: In runtime, when a specific message data in the source message format arrives and message format conversion is required, the XConverter message converter's conversion capability is invoked to perform message conversion, using 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 as input parameters, and generating message data in the destination message format.

[0108] The detailed implementation scheme for generating message definition data represented by a unified intermediate structure tree in the XConverter message converter involves parsing message data of different message format types into an intermediate structure tree represented by unified structure nodes with the same meaning. This process aligns the message structure tree formats of the original message types with differences to a level of interoperability and conversion. The steps include:

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

[0110] Step 2 involves summarizing and abstracting eight data value types with common meanings to represent data types, such as TEXT (text), BOOLEAN (boolean), LONG (integer), DATE (date), DECIMAL (floating-point), NULL (null), DOCUMENTREF (document object reference), and MISSING (non-existent field value). These eight data value types are used uniformly to describe the data types of the values ​​of each valuenode and attributenode 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, which parses the input message data into the native message structure tree of each common message format type.

[0112] Step 4: The XConverter message converter traverses the native message structure tree generated in the previous step, translating the native structure nodes into structure nodes of the unified intermediate structure tree to form a new unified intermediate structure tree. After supplementing basic information such as the native message format type name, the intermediate structure tree is named MessageDefinition message structure definition object. After serialization, the message structure definition data is stored in the db.

[0113] Furthermore, in the detailed implementation scheme of the mapping calculation rule data for the field values ​​between message definition data represented by the unified intermediate structure tree in the MCP Tool Manager, the MCP Tool Manager uses the source message definition data, the destination message definition data, and the destination message definition data as input parameters. On the mapping relationship configuration page, by writing SPEL value expressions, the mapping calculation relationship between the field values ​​of the two message definition data is configured as needed, including the following steps:

[0114] Step 1: The XConverter message converter specifies that the hierarchical positioning relationship of each structural node in the message data definition file, which is the message intermediate structure tree, is described in the form of dotted IDs, so as 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-level ValueNode structure node ID}"

[0116] "{Message Definition Data ID}:{root node ID}.{structure node ID}...{last-level attributeNode structure node ID}"

[0117] Step 2: The XConverter message converter specifies the use of SPEL language to write node value expressions. During message format conversion, the value operations of nodes in the intermediate structure tree of the destination message are calculated according to 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, or division operator can all appear as operands or operators in the SPEL value expression. The XConverter message converter specifies the default operation rules for the loop node (loopNode) when calculating mapping rules and provides some filtering and aggregation functions. For example, the fromindex and toindex position markers or other filtering functions can be used to filter the dataset under the loop node (loopNode) to obtain a subset, or the entire dataset under the loop node (loopNode) can be aggregated to obtain a single value.

[0118] Step 3: In the mapping configuration interface of the MCP tool manager, the expanded source message definition data structure tree and destination message intermediate structure tree clearly show which structure nodes are contained in each message definition data and their value types. Select a structure node in the destination message definition data, edit its SPEL value expression to generate message mapping rules between field values. After setting the SPEL value expressions for one or more structure nodes in the destination message definition data as needed, serialize and save them to the DB to obtain persistent mapping rule data.

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

[0120] For example, configure mapping conversion rules to discard unnecessary attribute fields from the MCP client. The `customer` field in the source message definition data will be directly discarded and will not appear in the destination message definition data.

[0121] For example, configure mapping transformation rules to expand multi-layered nested data structures into flat structures. Intermediate structures such as headers, bodies, and transactions in the source message definition data will be directly discarded and will not appear in the destination message definition data.

[0122] For example, configure mapping rules to convert JSON object arrays to CSV format. Add a headers structure node to the CSV, changing "stock" to product inventory and "name" to product name. Directly point the loop nodes of the CSV to the loop nodes of the JSON object array, and map their value nodes accordingly, such as... Figure 7 As shown.

[0123] like Figure 8 The diagram shows a flowchart illustrating the specific process of message conversion implemented by the XConverter message converter according to an embodiment of this application. The XConverter message converter uses source message definition data, destination message definition data, message mapping calculation rule data, and message data in the 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: Using the intermediate tree structure of the source message definition data as a reference standard, recursively verify whether the structural nodes in the two tree structures are structurally consistent.

[0126] Step 3: If inconsistent structure nodes are found during the structure tree verification process, return "Conversion failed, the input message data is inconsistent with the source message structure definition" and end.

[0127] Step 4: Convert the tree structure of the input message data's own data type into an intermediate tree structure representation. Each node in this intermediate tree structure carries the value of the input message data.

[0128] Step 5: Recursively traverse each node of the destination message intermediate structure tree, 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.

[0129] 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 transformed destination message data from the destination message structure tree with values.

[0130] This application presents an adapter conversion method and apparatus for publishing APIs as MCP tools. It primarily utilizes a configuration state to configure message mapping conversion rules and a runtime state to perform message adaptation conversion based on these rules, thereby publishing existing APIs as MCP tools. This allows for the rapid conversion of existing APIs into tools that meet the MCP Model Context Protocol tool specification requirements through simple configuration, and their subsequent publication on the MCP server for use by large language models with the assistance of the MCP client.

[0131] This application embodiment also designs and implements an mcptool-api-adaptor adapter requester, which coordinates and schedules multiple modules such as MCP response message generator, semantic response message generator, API request message generator, XConverter message converter, and HTTP API requester, and realizes the adaptation and semantic enhancement of API message format based on the configuration of message definition data and message mapping conversion rule data by the MCP tool manager and API manager.

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

[0133] This application also designs and implements a method for converting API response messages into semantic response messages. It achieves semantic conversion of API response messages by converting the key names of ambiguous technical terms that are not easily understood by a large language model into easily understandable business term names with semantic information, converting the enumerated attribute values ​​represented by numbers that are not easily understood into easily understandable 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 existing technologies, the existing APIs in this application embodiment do not require hard code modification. They can be adapted to the MCP tool adaptation layer through rule configuration, achieving efficient and low-cost conversion from API to MCP tool. Through the star-shaped message format conversion of the XConverter message converter, the conversion of MCP tool request messages to API request messages can be achieved, handling the problem of asymmetric request message detail. Through the star-shaped message format conversion of the XConverter message converter, the semantic adaptation conversion of API response messages to the Large Language Model (LLM) can be achieved, making them easy to understand and unambiguous. Through the star-shaped message format conversion of the XConverter message converter, API response messages can be simplified, reducing unnecessary token consumption for the Large Language Model (LLM). The existing APIs themselves do not need to care whether the request path comes from the MCP Server entry point or the traditional API entry point. The lifecycle management methods, monitoring, rate limiting, circuit breaking, and other governance methods of the already built APIs can still be reused.

[0135] like Figure 9 The diagram shown is a structural schematic of a publishing device for an MCP tool provided in an embodiment of this application, comprising:

[0136] The configuration module 910 is used to configure the first mapping relationship, the second mapping relationship, and the correspondence between MCP tools and APIs through the MCP tool manager, and to publish the MCP tools to the tool list visible to the MCP client; the first mapping relationship is the mapping relationship between API request messages and MCP tool request messages, and the second mapping relationship is the mapping relationship between semantic response messages and API response messages.

[0137] Specifically, the configuration module 910 is used to parse message data in the source message format into an intermediate structure tree of the source message through the message parser of the XConverter message converter; to parse message data in the destination message format into an intermediate structure tree of the destination message through the message parser of the XConverter message converter; and to configure and construct 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 based on the node value addressing reference rules of the intermediate structure tree specified by the XConverter message converter and its support for SPEL value expressions; wherein, the conversion capability of the XConverter message converter executes the SPEL value expressions configured in the mapping rules to complete the conversion from source message to 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 that have common meanings in various message format types through the XConverter message converter, and to uniformly use these four structural nodes to build an intermediate structure tree. The four structural nodes include loop nodes, object nodes, value nodes, and attribute nodes. The XConverter message converter also summarizes and abstracts eight data value types that have common meanings to represent the data types of values, and uniformly uses these eight data value types to describe the data types of the values ​​of each value node and attribute node in the intermediate structure tree. The eight data value types include TEXT text type. The XConverter message converter accepts the following data types: BOOLEAN (Boolean), LONG (Integer), DATE (Date), DECIMAL (Floating-point), NULL (Null value), DOCUMENTREF (Document Object Reference), and MISSING (Non-existent field value). Using the built-in message format base parser, the XConverter parses the input message data into a native message structure tree of the specified message format type. The XConverter then traverses this native message structure tree, translating the native structure nodes into structure nodes of a unified intermediate structure tree, forming a new unified intermediate structure tree. After adding the native message format type name to this new unified intermediate structure tree, it is named a MessageDefinition message structure definition object and serialized.

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

[0140] Specifically, the first conversion module 920 is used to call a base parser adapted to 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; using the intermediate structure tree of the source message definition data as a reference standard, the XConverter message converter recursively verifies whether the structure nodes in the intermediate structure tree of the source message and the intermediate structure tree of the destination message are structurally 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, and each node in the intermediate structure tree carries the value of the source message; each node in 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 to generate an intermediate structure tree of the destination message with values; based on the intermediate structure tree and the message format specified in the destination message definition, the corresponding format writer outputter is called to output the intermediate structure tree as the 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 used to call the MCP response message generator with 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; the semantic response message generator uses 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.

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

[0144] The acquisition module is used to acquire, based on the MCP tool corresponding to the MCP tool request message, the 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, wherein the API information includes API type and API upstream URL;

[0145] Accordingly, 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; and through the mcptool-api-adaptor adapter requester, call the API request message generator, and through the API request message generator, use the MCP tool request message data, the MCP tool request message definition information, the API request message definition information, and the first mapping relationship as input parameters to call the message conversion capability of the XConverter message converter to convert the MCP tool request message data into API request message data.

[0146] Based on the mapping relationship between messages, the embodiments of this application can efficiently and cost-effectively convert APIs to MCP tools without requiring hard modifications to existing API code and avoiding unnecessary token consumption for large language models.

[0147] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, this computer program implements the various processes of the above-described MCP tool publishing method embodiment and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

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

[0149] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they 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 this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0150] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for publishing a Model Context Protocol (MCP) tool, characterized in that, Includes the following steps: Configure the first mapping relationship, the second mapping relationship, and the correspondence between MCP tools and APIs through the MCP tool manager, and publish the MCP tools to the tool list visible to the MCP client; The first mapping relationship is the mapping relationship between API request messages and MCP tool request messages, and the second mapping relationship is the mapping relationship between semantic response messages and API response messages; After receiving the MCP tool request message through the access layer tool executor, the MCP tool request message is converted into a corresponding API request message according to the first mapping relationship, and the API request message is forwarded 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; Before converting the MCP tool request message into a corresponding API request message according to the first mapping relationship, the method further includes: Based on the MCP tool corresponding to the MCP tool request message, obtain the 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. The API information includes the API type and the API upstream URL. The step of converting the MCP tool request message into a corresponding API request message according to the first mapping relationship specifically includes: Using the API information and the MCP tool request message information as input parameters, the mcptool-api-adaptor adapter requester is invoked; The mcptool-api-adaptor is used to call the API request message generator. 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 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.

2. The method according to claim 1, characterized in that, The step of converting the API response message into a corresponding semantic response message according to the second mapping relationship specifically includes: The API response message data, API response message definition information, semantic response message definition information, and the second mapping relationship information are used as input parameters to call the MCP response message generator; The MCP response message generator delegates the message conversion request to the semantic response message generator. 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 invoke the message conversion capability of the XConverter message converter to convert the API response message data into a semantic response message.

3. The method according to claim 1, characterized in that, Configure the first and second mapping relationships through the MCP tool manager, specifically including: The XConverter message converter's message parser parses the message data in the source message format into the intermediate structure tree of the source message. The XConverter message converter's message parser parses the message data of the destination message format into the intermediate structure tree of the destination message. Based on the node value addressing and referencing rules of the intermediate structure tree specified by the XConverter message converter and the support for SPEL value retrieval 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. The XConverter message converter executes the SPEL value expression configured in the mapping rules to complete the conversion from source message to 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.

4. The method according to claim 3, characterized in that, The XConverter message converter parses message data of different message format types into an intermediate structure tree, specifically including: The XConverter message converter summarizes and abstracts four structural nodes that have common meanings in various message format types, and uses these four structural nodes to build an intermediate structure tree. The four structural nodes include loop node, object node, value node, and attribute node. The XConverter message converter summarizes and abstracts eight data value types with common meanings to represent data types of values. These eight data value types are used uniformly to describe the data types of the values ​​of each value node and attribute node in the intermediate structure tree. The eight data value types include TEXT (text), BOOLEAN (boolean), LONG (integer), DATE (date), DECIMAL (floating-point), NULL (null), DOCUMENTREF (document object reference), and MISSING (non-existent field value). The XConverter message converter uses its built-in message format base parser to parse the input message data into a native message structure tree of the message format type. The XConverter message converter traverses the original message structure tree, translates the original structure nodes into structure nodes of the unified intermediate structure tree, forms a new unified intermediate structure tree, and after adding the original 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 XConverter message converter transforms source messages into destination messages using its conversion capabilities, specifically including: The XConverter message converter calls 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 verify whether the structure nodes in the intermediate structure tree of the source message and the intermediate structure tree of the destination message are structurally 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; each node in 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, generating an intermediate structure tree of the destination message with values; 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.

5. A device for distributing MCP tools, characterized in that, include: The configuration module is used to configure the first mapping relationship, the second mapping relationship, and the correspondence between MCP tools and APIs through the MCP tool manager, and to publish the MCP tools to the tool list visible to the MCP client; The first mapping relationship is the mapping relationship between API request messages and MCP tool request messages, and the second mapping relationship is the mapping relationship between semantic response messages and API response messages; The first conversion module is used to convert the MCP tool request message into a corresponding API request message according to the first mapping relationship after receiving the MCP tool request message through the access layer tool executor, and forward the API request message to the 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. The acquisition module is used to acquire, based on the MCP tool corresponding to the MCP tool request message, the 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, wherein the API information includes API type and 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; and through the mcptool-api-adaptor adapter requester, call the API request message generator, and through the API request message generator, use the MCP tool request message data, the MCP tool request message definition information, the API request message definition information, and the first mapping relationship as input parameters to call the message conversion capability of the XConverter message converter to convert the MCP tool request message data into API request message data.

6. The apparatus according to claim 5, characterized in that, The second conversion module is specifically used to call the MCP response message generator by taking 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. 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 invoke the message conversion capability of the XConverter message converter to convert the API response message data into a semantic response message.

7. The apparatus according to claim 5, characterized in that, The configuration module is specifically used to parse message data in the source message format into an intermediate structure tree of the source message using the message parser of the XConverter message converter; to parse message data in the destination message format into an intermediate structure tree of the destination message using the message parser of the XConverter message converter; and to configure and construct 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 based on the node value addressing reference rules of the intermediate structure tree specified by the XConverter message converter and its support for SPEL value expressions. The conversion capability of the XConverter message converter executes the SPEL value expressions configured in the mapping rules to complete the conversion from source message to 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.

8. The apparatus according to claim 7, characterized in that, The configuration module is specifically used to summarize and abstract four structural nodes with common meanings across multiple message format types using the XConverter message converter, and to uniformly use these four structural nodes to build an intermediate structure tree. These four structural nodes include loop nodes, object nodes, value nodes, and attribute nodes. The module also summarizes and abstracts eight data value types with common meanings to represent the data types of values ​​using the XConverter message converter, and uniformly uses these eight data value types to describe the data types of the values ​​of each value node and attribute node in the intermediate structure tree. These eight data value types include TEXT (text type), BOO (text type), and so on. The XConverter message converter accepts the following data types: LEAN (boolean), LONG (integer), DATE (date), DECIMAL (floating-point), NULL (null), DOCUMENTREF (document object reference), and MISSING (non-existent field value). The XConverter parses the input message data into a native message structure tree of the specified message format type using its built-in message format base parser. The XConverter then traverses this native message structure tree, translating the native structure nodes into structure nodes of a unified intermediate structure tree, forming a new unified intermediate structure tree. After adding the native message format type name to this new unified intermediate structure tree, it names the new unified intermediate structure tree a MessageDefinition message structure definition object and serializes it. The first conversion module and the second conversion module are specifically used 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 to use the intermediate structure tree of the source message definition data as a reference standard through the XConverter message converter 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 structurally consistent. If inconsistent structural nodes are found during the structure tree validation process, a failure message is returned; Otherwise, the tree structure of the source message's own data type is converted into an intermediate tree structure representation, where each node in the intermediate tree structure 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, the writer outputter of the corresponding format is called to output the intermediate structure tree as the converted destination message data.

Images