An intra-enterprise service calling method, apparatus, device and storage medium

Abstract

The application discloses an enterprise internal service calling method and device, equipment and a storage medium, and relates to the technical field of artificial intelligence. The method comprises the following steps: registering a target enterprise corresponding to a calling tool in a corresponding independent MCP server instance, and constructing an independent URL endpoint path containing a field identifier for each independent MCP server instance; receiving a service calling request initiated by an intelligent agent, determining a current field identifier from a target URL endpoint path of the service calling request, and determining a corresponding target MCP server instance according to the current field identifier and the independent URL endpoint path; obtaining a tool list in the target MCP server instance, and sending a service problem in the service calling request and the tool list to a target large language model to determine a target calling tool and a calling parameter, so as to perform internal service calling on the target enterprise. In this way, the tool calling efficiency and flexibility can be improved.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method, apparatus, device, and storage medium for invoking internal enterprise services. Background Technology

[0002] With the rapid development of large language model technology, more and more enterprises hope to use large language models to call internal services to complete complex business processes. The Model Context Protocol (MCP), as a standardized protocol for calling large language model tools, aims to establish a unified standard for connecting large language models with external resources and tools. The MCP architecture adopts a client-server model, with its core consisting of three parts: the MCP host responsible for user interaction, the MCP client built into the host for connecting services, and the MCP server providing the actual tool functionality.

[0003] In existing technologies, there are several main solutions for calling internal enterprise services via the MCP protocol: Solution 1: Using a single MCP server to centrally manage all tools, i.e., registering all enterprise tools to a single MCP server, with agents accessing through a single endpoint. With this solution, token consumption increases linearly as the number of tools increases, making it impossible to isolate tools according to business scenarios or achieve cross-domain tool combinations. Solution 2: Dividing into multiple MCP servers according to fixed domains, i.e., creating an independent MCP server and Uniform Resource Locator (URL) endpoint for each business domain. In this solution, tool combinations require maintaining multiple connections, making it impossible to customize cross-domain toolsets or perform fine-grained filtering within a domain. Solution 3: Reducing token consumption through prompt word optimization and context caching, i.e., reducing tool descriptions and caching static content. However, the simplified descriptions in this solution affect tool understandability, and caching cannot fundamentally solve the problem of the number of tools, resulting in limited optimization effects, typically only between 10% and 40%. In summary, existing technologies for large language models to call internal enterprise services via the MCP protocol suffer from several key technical drawbacks, including huge token consumption, lack of flexible tool combination mechanisms, inability to achieve fine-grained tool filtering, and limited optimization effects.

[0004] Therefore, how to provide a large-scale tool invocation scheme that can effectively reduce token consumption and is flexible and controllable to improve the efficiency of internal service invocation within enterprises is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method, apparatus, device, and storage medium for invoking internal services within an enterprise, which can improve the efficiency of invoking internal services within an enterprise. The specific solution is as follows: Firstly, this application discloses a method for invoking internal enterprise services, including: The tools to be invoked corresponding to the target enterprise are registered to the corresponding independent MCP server instances, and an independent URL endpoint path containing a domain identifier is constructed for each independent MCP server instance; the tools to be invoked include basic tools under each standard domain and tool combinations selected from several standard domains; the standard domains are business domains divided based on the business type corresponding to the target enterprise; Receive a service call request initiated by an intelligent agent, and determine the current domain identifier from the target URL endpoint path of the service call request, so as to determine the corresponding target MCP server instance based on the current domain identifier and the independent URL endpoint path; Obtain the tool list in the target MCP server instance, and send the service question in the service call request and the tool list to the target large language model to determine the target calling tool and calling parameters, so as to perform internal service calls to the target enterprise based on the target calling tool and the calling parameters.

[0006] Optionally, the step of registering the tools to be invoked corresponding to the target enterprise to the corresponding independent MCP server instances, and constructing an independent URL endpoint path containing a domain identifier for each of the independent MCP server instances, includes: Load all configured standard domains from the target enterprise's persistent storage and create a first standalone MCP server instance for the standard domains; Register the tools belonging to each standard domain of the target enterprise to the first independent MCP server instance corresponding to each standard domain; The tool combinations selected from several standard domains will be registered to the second independent MCP server instance corresponding to the preset custom domain; Construct independent URL endpoint paths containing domain identifiers for the first independent MCP server instance and the second independent MCP server instance.

[0007] Optionally, registering the tool combination selected from several standard domains to the second independent MCP server instance corresponding to a preset custom domain includes: Based on the preset configuration interface, obtain the user-defined domain information to determine the preset custom domain; A combination of tools is selected from several of the aforementioned standard domains based on the list of tools specified by the user. A second independent MCP server instance is constructed for the preset custom domain, and the tool combination is registered to the second independent MCP server instance.

[0008] Optionally, obtaining the list of tools in the target MCP server instance includes: The path query parameters in the service call request are parsed to determine whether the path query parameters contain tool filtering parameters; If the path query parameters include the tool filtering parameters, then the specified tool set is obtained based on the tool filtering parameters; Based on the specified toolset, all tools in the target MCP server instance are filtered to generate a filtered toolset list containing the tools in the specified toolset, and the filtered toolset list is determined as the toolset list.

[0009] Optionally, the step of filtering all tools in the target MCP server instance based on the specified toolset to generate a filtered tool list containing tools from the specified toolset, and determining the filtered tool list as the tool list, includes: Create a temporary MCP server instance based on the specified toolset; The tools that are online in the target MCP server instance are traversed, and the tools of the specified tool set are registered to the temporary MCP server instance; The temporary MCP server instance is identified as the new target MCP server instance to obtain the tool list in the target MCP server instance.

[0010] Optionally, the method further includes: The system receives tool configuration change events in real time through a message subscription channel and parses these events to obtain the event change type and content. The independent MCP server instance is refreshed based on the event change type and the event change content to obtain the changed independent MCP server instance.

[0011] Optionally, the step of making internal service calls to the target enterprise based on the target calling tool and the calling parameters includes: Based on the calling parameters, the target calling tool is invoked in the backend service of the target enterprise through the target MCP server instance, and the tool calling result is sent to the target large language model to generate the enterprise internal service calling result.

[0012] Secondly, this application discloses an internal enterprise service invocation device, comprising: The instance construction module is used to register the tools to be invoked corresponding to the target enterprise to the corresponding independent MCP server instances, and to construct independent URL endpoint paths containing domain identifiers for each independent MCP server instance; the tools to be invoked include basic tools under each standard domain and tool combinations selected from several standard domains; the standard domains are business domains divided based on the business type corresponding to the target enterprise; The request analysis module is used to receive service call requests initiated by the intelligent agent and determine the current domain identifier from the target URL endpoint path of the service call request, so as to determine the corresponding target MCP server instance based on the current domain identifier and the independent URL endpoint path; The service invocation module is used to obtain the tool list in the target MCP server instance, and send the service question in the service invocation request and the tool list to the target large language model to determine the target invocation tool and invocation parameters, so as to perform internal service invocation on the target enterprise based on the target invocation tool and the invocation parameters.

[0013] Thirdly, this application discloses an electronic device, including: Memory, used to store computer programs; A processor for executing the computer program to implement the aforementioned enterprise internal service invocation method.

[0014] Fourthly, this application discloses a computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the aforementioned enterprise internal service invocation method.

[0015] As can be seen, in this application, the tools to be invoked corresponding to the target enterprise are registered to the corresponding independent MCP server instances, and an independent URL endpoint path containing a domain identifier is constructed for each of the independent MCP server instances; the tools to be invoked include basic tools under each standard domain and tool combinations selected from several standard domains; the standard domain is a business domain divided based on the business type corresponding to the target enterprise; a service invocation request initiated by an agent is received, and the current domain identifier is determined from the target URL endpoint path of the service invocation request, so as to determine the corresponding target MCP server instance according to the current domain identifier and the independent URL endpoint path; a tool list in the target MCP server instance is obtained, and the service question in the service invocation request and the tool list are sent to the target large language model to determine the target invocation tool and invocation parameters, so as to perform internal service invocation on the target enterprise based on the target invocation tool and the invocation parameters. In other words, by registering tools to independent MCP server instances according to standard and custom domains and constructing URL endpoints with domain identifiers, subsequent access to the corresponding endpoints yields a precisely narrowed list of tools. This significantly reduces the number of tool descriptions transmitted to the large language model, substantially lowers token consumption, and enables flexible combination and on-demand invocation of cross-domain tools. This, in turn, can significantly improve the efficiency of internal service invocation within an enterprise. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 This application discloses a flowchart of an internal service invocation method. Figure 2 This is a schematic diagram of the structure of an enterprise internal service invocation device disclosed in this application; Figure 3 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0018] 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, and 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.

[0019] In existing technologies, when large language models call internal enterprise services via the MCP protocol, the full transmission of the tool list leads to huge token consumption. There is a lack of flexible tool combination mechanisms, and fine-grained tool filtering is impossible. Furthermore, token optimization methods such as prompt word simplification and context caching have limited effectiveness. Therefore, this application provides an internal enterprise service call solution. Through mechanisms such as domain isolation, custom domains, and tool filtering, it enables on-demand return of the tool list, significantly reducing token consumption during large language model calls, while providing flexible tool combination and fine-grained tool filtering capabilities. Therefore, this application will specifically introduce an internal enterprise service call method that can solve the above problems.

[0020] See Figure 1 As shown in the figure, this application discloses a method for invoking internal enterprise services, including: Step S11: Register the tools to be invoked corresponding to the target enterprise to the corresponding independent MCP server instances, and construct an independent URL endpoint path containing a domain identifier for each independent MCP server instance; the tools to be invoked include basic tools under each standard domain and tool combinations selected from several standard domains; the standard domains are business domains divided based on the business type corresponding to the target enterprise.

[0021] In this embodiment, the standard domain is a business domain divided based on the business type of the target enterprise. For example, for a securities company, its business can be divided into standard domains such as the stock domain, user domain, and order domain. Each standard domain has several basic tools, such as the stock domain having tools for querying market data, trading volume, and candlestick charts. At the system level, the overall architecture of the enterprise internal service call system in this embodiment can be divided into four layers: The first layer is the unified access gateway layer, which is an HTTP (Hypertext Transfer Protocol) access gateway built on the Hertz framework. It is responsible for receiving MCP requests from intelligent agents. The gateway parses the target domain according to the request URL path and routes it to the corresponding MCP server instance. The second layer is the domain management layer, which is responsible for managing two types of entities: standard domains and custom domains. Standard domains are domains naturally divided according to business types, while custom domains are combinations of tools configured by users. A custom domain can contain tools from multiple standard domains. The third layer is the MCP server instance layer. Each domain corresponds to an independent MCP server instance, which has an independent toolset and SSE (Server-Sent Events) connection endpoint. The fourth layer is the backend service layer, which is the backend service that actually executes the tool calls and supports multiple protocols such as HTTP, Dubbo, Kitex, and GraphQL.

[0022] The step of registering the tools to be invoked by the target enterprise to the corresponding independent MCP server instances and constructing independent URL endpoint paths containing domain identifiers for each independent MCP server instance includes: loading all configured standard domains from the persistent storage of the target enterprise and creating a first independent MCP server instance for each standard domain; registering the tools under each standard domain of the target enterprise to the first independent MCP server instance corresponding to each standard domain; registering a combination of tools selected from several standard domains to a second independent MCP server instance corresponding to a preset custom domain; and constructing independent URL endpoint paths containing domain identifiers for the first independent MCP server instance and the second independent MCP server instance.

[0023] For example, during system startup, all configured standard domains can be queried and loaded from the target enterprise's persistent storage (such as a MySQL database). The loaded list of standard domains is then traversed. For each standard domain, a first independent MCP server instance named "mcp-domain code-server" is created, using the domain code as the identifier. This instance, along with the domain identifier, domain code, and domain configuration information, is encapsulated into an MCP service information object, stored in the standard domain cache using the domain ID (Identifier) ​​as the key. This allows for quick retrieval of the corresponding MCP server instance based on the domain identifier later. After tool registration, a path prefix can be constructed based on the SSE endpoint prefix configured for each domain, and the endpoint suffix can be determined based on the MCP communication type configured for that domain: if the communication type is SSE, "sse" is appended to the path prefix to obtain the independent URL endpoint path; otherwise, "mcp" is appended to the path prefix to obtain the independent URL endpoint path. For example, the independent URL endpoint path for the stock domain could be / api / mcp / stock_area / sse, for the user domain it could be / api / mcp / user_area / sse, and for the order domain it could be / api / mcp / order_area / sse. Thus, each standard domain has its own isolated and independent MCP server instance and independent URL endpoint, ensuring that toolsets from different domains do not interfere with each other and achieving resource isolation between domains.

[0024] The step of registering the tool combination selected from several standard domains to the second independent MCP server instance corresponding to the preset custom domain includes: obtaining user-defined domain information based on a preset configuration interface to determine the preset custom domain; selecting a tool combination from several standard domains based on the tool list specified by the user; constructing a second independent MCP server instance for the preset custom domain, and registering the tool combination to the second independent MCP server instance.

[0025] It is understandable that a preset custom domain, also known as a virtual domain, is a collection of tools manually selected by the user from multiple standard domains, used for cross-domain tool combinations. In one specific implementation, the data model of a custom domain may include the following fields: primary key ID (id), owner user ID (OwnerUserId), domain code (Code), domain name (Name), SSE endpoint prefix (SsePrefix), a list of associated tool IDs (Sids, separated by commas), whether it is valid (Valid), key (Secret), and whether authentication is required (Auth). Among them, the key field Sids stores the list of tool IDs contained in the virtual domain. For example, when the value of this field is "1,3,5,8", it means that the custom domain contains four tools with tool IDs of 1, 3, 5, and 8 respectively. When the system starts up and initializes custom domains, the total number of custom domains can be counted first. Then, custom domain records can be queried from persistent storage in batches by page. For each custom domain, a second independent MCP server instance named in the form of "mcp-domain code-server" can be created and stored in the custom domain cache. At the same time, the tool ID list of the custom domain can be parsed, and a two-way mapping relationship between tool IDs and custom domains can be established one by one. That is, for each tool ID, all the custom domains to which it belongs can be recorded so that the affected custom domains can be quickly located when tools are changed in the future.

[0026] Step S12: Receive a service call request initiated by the agent, and determine the current domain identifier from the target URL endpoint path of the service call request, so as to determine the corresponding target MCP server instance based on the current domain identifier and the independent URL endpoint path.

[0027] In this embodiment, when an agent initiates a service call request, the request carries the target URL endpoint path, such as / api / mcp / stock_area / sse. Upon receiving this service call request, the unified access gateway layer parses the target URL endpoint path, extracts the current domain identifier (e.g., stock_area), and then matches it against the existing independent URL endpoint paths. First, it searches the standard domain cache for the first independent MCP server instance corresponding to the current domain identifier. If no match is found, it continues searching the custom domain cache for the second independent MCP server instance corresponding to the current domain identifier, thus routing the service call request to the corresponding target MCP server instance. It is understandable that, since each domain corresponds to an independent URL endpoint path, the gateway can achieve domain-level tool isolation simply through URL routing, eliminating the need for the agent to carry additional domain information in the request body, thus simplifying the agent's access logic.

[0028] Step S13: Obtain the tool list in the target MCP server instance, and send the service question in the service call request and the tool list to the target large language model to determine the target calling tool and calling parameters, so as to make internal service calls to the target enterprise based on the target calling tool and the calling parameters.

[0029] In this embodiment, obtaining the tool list in the target MCP server instance includes: parsing the path query parameters in the service call request to determine whether the path query parameters contain tool filtering parameters; if the path query parameters contain the tool filtering parameters, obtaining a specified tool set based on the tool filtering parameters; filtering all tools in the target MCP server instance based on the specified tool set to generate a filtered tool list containing tools in the specified tool set, and determining the filtered tool list as the tool list. Specifically, filtering all tools in the target MCP server instance based on the specified tool set to generate a filtered tool list containing tools in the specified tool set, and determining the filtered tool list as the tool list, includes: creating a temporary MCP server instance based on the specified tool set; traversing the online tools in the target MCP server instance and registering the tools from the specified tool set to the temporary MCP server instance; determining the temporary MCP server instance as the new target MCP server instance to obtain the tool list in the target MCP server instance.

[0030] In practice, if the path query parameters do not include tool filtering parameters, the tool list is directly determined by all tools in the target MCP server instance. The tool filtering parameter can be a `toolset` parameter. For example, the values ​​of the `toolset` parameter are separated by commas to obtain several tool codes. After whitespace trimming of each tool code, a tool code mapping table is constructed to obtain the specified tool set. Then, a temporary MCP server instance with the same name as the target domain is created. All tool configurations in the cache that are online are traversed. For tools whose domain identifier matches the target MCP server instance and whose tool codes match the tool code mapping table, they are registered in the temporary MCP server instance. Finally, a streaming HTTP service object is constructed based on this temporary MCP server instance and designated as the new target MCP server instance, ensuring that the tool list returned to the Agent only contains tools from the specified tool set.

[0031] For example, if the Agent initiates a service call request as GET / api / mcp / stock_area / sse?toolset=getPrice,getVolume,getKLine, this request will only return the three specified tools: market data query (getPrice), trading volume query (getVolume), and candlestick chart query (getKLine), instead of all 20 tools in the stock field. Through this real-time filtering mechanism based on URL parameters, tools can be filtered on demand at runtime without pre-configuration. Assuming an average cost of 50 tokens per tool description, in a scenario where only market data is queried, the token cost of the tool list is reduced from approximately 1000 tokens for 20 tools to approximately 150 tokens for 3 tools, a reduction of approximately 85%. In a scenario where only order placement is performed, the token cost is similarly reduced from approximately 1000 tokens to approximately 150 tokens, a reduction of approximately 85%. In a scenario where positions are queried, filtering returns only 2 tools, reducing the token cost from approximately 1000 tokens to approximately 100 tokens, a reduction of approximately 90%. In addition, for tools involving sensitive operations (such as deletion and export), their exposure scope can be controlled as needed through tool filtering mechanisms to prevent sensitive tools from being mistakenly invoked by large language models.

[0032] In terms of token saving, assuming the target company has 100 tools, and each tool description consumes an average of 50 tokens, the traditional full transmission method would consume 100 × 50 = 5000 tokens per request for the tool list. However, using the domain isolation method in this embodiment, in the stock business scenario, the agent connects to the stock domain endpoint to obtain only 20 tools from that domain, consuming 20 × 50 = 1000 tokens, a saving of 80%. In the user business scenario, only 15 tools from the user domain are obtained, consuming 15 × 50 = 750 tokens, a saving of 85%. In the order business scenario, only 30 tools from the order domain are obtained, consuming 30 × 50 = 1500 tokens, a saving of 70%. It is evident that the domain isolation mechanism can reduce the token consumption of the tool list by 60% to 85%.

[0033] This embodiment further includes: receiving tool configuration change events in real time through a message subscription channel, parsing the tool configuration change events to obtain the event change type and event change content; refreshing the independent MCP server instance based on the event change type and the event change content to obtain the changed independent MCP server instance. For example, this application can build a message subscription channel based on Redis's publish-subscribe mechanism. When the service starts, it subscribes to a specified service change channel and continuously listens to messages in the channel through an independent coroutine. When the configuration of a tool or domain changes, the configuration end publishes the tool configuration change event to the channel. After the service subscribes to the event, it parses it to obtain the event change type (such as tool addition, tool modification, tool deletion, tool launch, tool decommissioning, domain addition, domain deletion, etc.) and the event change content (such as the changed tool configuration or domain configuration). Then, it updates the local cache according to the event change type and the event change content and refreshes the corresponding independent MCP server instance, such as registering newly added tools or removing decommissioned tools in the instance, to obtain the changed independent MCP server instance. With the above configuration hot update mechanism, the effective time of configuration changes can be controlled within 1 second, without restarting the service, and supports the real-time online and offline deployment of tools.

[0034] The step of making internal service calls to the target enterprise based on the target calling tool and the calling parameters includes: calling the target calling tool in the backend service of the target enterprise through the target MCP server instance based on the calling parameters, and sending the tool calling result to the target large language model to generate the enterprise internal service calling result.

[0035] Specifically, after determining the tool list, the target MCP server instance returns the tool list to the Agent. The Agent sends the service question from the service call request along with the tool list to the target large language model. The target large language model determines the target calling tool from the tool list based on the semantics of the service question and generates call parameters according to the parameter schema of the target calling tool. Then, based on the call parameters, the target calling tool is invoked in the target enterprise's backend service through the target MCP server instance. The backend service supports multiple protocols such as HTTP, Dubbo, Kitex, and GraphQL. The target large language model generates the final response in natural language form based on the tool call result and returns the internal service call result to the Agent or the user, thus completing a complete internal service call.

[0036] As can be seen, in this application, the tools to be invoked corresponding to the target enterprise are registered to the corresponding independent MCP server instances, and an independent URL endpoint path containing a domain identifier is constructed for each of the independent MCP server instances; the tools to be invoked include basic tools under each standard domain and tool combinations selected from several standard domains; the standard domain is a business domain divided based on the business type corresponding to the target enterprise; a service invocation request initiated by an agent is received, and the current domain identifier is determined from the target URL endpoint path of the service invocation request, so as to determine the corresponding target MCP server instance according to the current domain identifier and the independent URL endpoint path; a tool list in the target MCP server instance is obtained, and the service question in the service invocation request and the tool list are sent to the target large language model to determine the target invocation tool and invocation parameters, so as to perform internal service invocation on the target enterprise based on the target invocation tool and the invocation parameters. In other words, by registering the tools to be invoked for the target enterprise into separate independent MCP server instances according to standard domains, and constructing independent URL endpoint paths containing domain identifiers for each independent MCP server instance, domain isolation based on URL routing is achieved. The agent connects to the endpoint of the corresponding domain according to the business scenario, and only obtains the tool list of that domain, avoiding the full transmission of the tool list. This fundamentally reduces the number of tools sent to the target large language model, significantly reduces the token consumption and API call cost during the large language model invocation process, mitigates the risk of context window overflow, shortens the initial token generation time, and reduces the decision complexity of the large language model in selecting tools. Furthermore, the tools to be invoked also include combinations of tools selected from several standard domains, supporting cross-domain tool combinations. A single URL endpoint can access the combined toolset, simplifying the agent's connection management and improving the flexibility and efficiency of internal enterprise service invocation.

[0037] refer to Figure 2 The present application also discloses an internal enterprise service invocation device, comprising: The instance construction module 11 is used to register the tools to be invoked corresponding to the target enterprise to the corresponding independent MCP server instances, and to construct an independent URL endpoint path containing a domain identifier for each independent MCP server instance; the tools to be invoked include basic tools under each standard domain and tool combinations selected from several standard domains; the standard domains are business domains divided based on the business type corresponding to the target enterprise; Request analysis module 12 is used to receive service call requests initiated by the intelligent agent and determine the current domain identifier from the target URL endpoint path of the service call request, so as to determine the corresponding target MCP server instance based on the current domain identifier and the independent URL endpoint path; Service invocation module 13 is used to obtain the tool list in the target MCP server instance, and send the service question in the service invocation request and the tool list to the target large language model to determine the target invocation tool and invocation parameters, so as to perform internal service invocation on the target enterprise based on the target invocation tool and the invocation parameters.

[0038] As can be seen, in this embodiment, by dividing tools into different standard domains based on the target enterprise's business type and creating an independent MCP server instance and an independent URL endpoint path containing domain identifiers for each domain, tool isolation between domains is achieved. The agent connects to the endpoint of the corresponding domain according to the business scenario and only obtains the tool list of that domain, avoiding the full transmission of the tool list. This fundamentally reduces the number of tools sent to the target large language model, thereby significantly reducing the token consumption and API call costs during the large language model's invocation process, mitigating the risk of context window overflow, shortening the initial token generation time, and reducing the decision complexity of the large language model in selecting suitable tools from a large number of tools, thus improving the accuracy of tool selection. On the other hand, the tools to be invoked also include combinations of tools selected from several standard domains, supporting cross-domain tool combinations according to business scenarios. The agent can access the combined toolset through a single URL endpoint without maintaining multiple long connections, simplifying the connection management between the agent and the MCP server instance, and improving the flexibility and efficiency of internal enterprise service invocation.

[0039] In some specific embodiments, the instance construction module 11 may specifically include: The first instance creation unit is used to load all configured standard domains from the persistent storage of the target enterprise and create a first independent MCP server instance for the standard domains; The first tool registration unit is used to register the tools belonging to each standard domain of the target enterprise to the first independent MCP server instance corresponding to each standard domain; The tool registration submodule is used to register a combination of tools selected from several standard domains to a second independent MCP server instance corresponding to a preset custom domain; The path construction unit is used to construct independent URL endpoint paths containing domain identifiers for the first independent MCP server instance and the second independent MCP server instance.

[0040] In some specific embodiments, the tool registration submodule may specifically include: The domain information definition unit is used to obtain user-defined domain information based on the preset configuration interface in order to determine the preset custom domain; The tool selection unit is used to select a combination of tools from several standard domains based on the tool list specified by the user terminal; The second tool registration unit is used to construct a second independent MCP server instance for the preset custom domain and register the tool combination to the second independent MCP server instance.

[0041] In some specific embodiments, the service invocation module 13 may specifically include: The tool parameter judgment unit is used to parse the path query parameters in the service call request to determine whether the path query parameters contain tool filtering parameters. The toolset acquisition unit is used to acquire a specified toolset based on the toolset filtering parameters if the path query parameters include the toolset filtering parameters. The tool list processing submodule is used to filter all tools in the target MCP server instance based on the specified tool set to generate a filtered tool list containing tools in the specified tool set, and to determine the filtered tool list as the tool list.

[0042] In some specific embodiments, the tool list processing submodule may specifically include: A temporary instance creation unit is used to create a temporary MCP server instance based on the specified toolset. The third tool registration unit is used to traverse the online tools in the target MCP server instance and register the tools of the specified tool set to the temporary MCP server instance; The list determination unit is used to determine the temporary MCP server instance as the new target MCP server instance in order to obtain the tool list in the target MCP server instance.

[0043] In some specific embodiments, the enterprise internal service invocation device may further include: The event acquisition module is used to receive tool configuration change events in real time through the message subscription channel, and to parse the tool configuration change events to obtain the event change type and event change content; The instance change module is used to refresh the independent MCP server instance based on the event change type and the event change content to obtain the changed independent MCP server instance.

[0044] In some specific embodiments, the service invocation module 13 may specifically include: The service invocation unit is used to invoke the target invocation tool in the backend service of the target enterprise through the target MCP server instance based on the invocation parameters, and send the tool invocation result to the target large language model to generate the enterprise internal service invocation result.

[0045] Furthermore, embodiments of this application also disclose an electronic device, Figure 3 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0046] Figure 3 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the enterprise internal service invocation method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0047] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0048] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0049] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including computer programs capable of performing the enterprise internal service invocation methods executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0050] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed method for invoking internal enterprise services. The specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0051] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0052] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0053] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0054] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, 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 said element.

[0055] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for invoking internal enterprise services, characterized in that, include: The tools to be invoked corresponding to the target enterprise are registered to the corresponding independent MCP server instances, and an independent URL endpoint path containing a domain identifier is constructed for each independent MCP server instance; the tools to be invoked include basic tools under each standard domain and tool combinations selected from several standard domains; the standard domains are business domains divided based on the business type corresponding to the target enterprise; wherein, the first independent MCP server instance created for each standard domain is stored in the standard domain cache, and the second independent MCP server instance created for each preset custom domain is stored in the custom domain cache; When registering a combination of tools selected from several standard domains to a second independent MCP server instance corresponding to a preset custom domain, the tool identifier list of the preset custom domain is parsed, and a bidirectional mapping relationship between the tool identifier and the preset custom domain is established, so as to locate the affected preset custom domain based on the bidirectional mapping relationship; The system receives a service call request initiated by an agent and determines the current domain identifier from the target URL endpoint path of the service call request. It first searches for a first independent MCP server instance corresponding to the current domain identifier in the standard domain cache. If no match is found, it searches for a second independent MCP server instance corresponding to the current domain identifier in the custom domain cache, so as to determine the corresponding target MCP server instance based on the current domain identifier and the independent URL endpoint path. Obtain the tool list in the target MCP server instance, and send the service question in the service call request and the tool list to the target large language model to determine the target calling tool and calling parameters, so as to perform internal service calls to the target enterprise based on the target calling tool and the calling parameters.

2. The enterprise internal service invocation method according to claim 1, characterized in that, The step of registering the tools to be invoked corresponding to the target enterprise to the corresponding independent MCP server instances, and constructing an independent URL endpoint path containing a domain identifier for each of the independent MCP server instances, includes: Load all configured standard domains from the target enterprise's persistent storage and create a first standalone MCP server instance for the standard domains; Register the tools belonging to each standard domain of the target enterprise to the first independent MCP server instance corresponding to each standard domain; The tool combinations selected from several standard domains will be registered to the second independent MCP server instance corresponding to the preset custom domain; Construct independent URL endpoint paths containing domain identifiers for the first independent MCP server instance and the second independent MCP server instance.

3. The enterprise internal service invocation method according to claim 2, characterized in that, The step of registering a combination of tools selected from several standard domains to a second independent MCP server instance corresponding to a preset custom domain includes: Based on the preset configuration interface, obtain the user-defined domain information to determine the preset custom domain; A combination of tools is selected from several of the aforementioned standard domains based on the list of tools specified by the user. A second independent MCP server instance is constructed for the preset custom domain, and the tool combination is registered to the second independent MCP server instance.

4. The enterprise internal service invocation method according to claim 1, characterized in that, The tool list for obtaining the target MCP server instance includes: The path query parameters in the service call request are parsed to determine whether the path query parameters contain tool filtering parameters; If the path query parameters include the tool filtering parameters, then the specified tool set is obtained based on the tool filtering parameters; Based on the specified toolset, all tools in the target MCP server instance are filtered to generate a filtered toolset list containing the tools in the specified toolset, and the filtered toolset list is determined as the toolset list.

5. The enterprise internal service invocation method according to claim 4, characterized in that, The step of filtering all tools in the target MCP server instance based on the specified toolset to generate a filtered tool list containing tools from the specified toolset, and determining the filtered tool list as the tool list, includes: Create a temporary MCP server instance based on the specified toolset; The tools that are online in the target MCP server instance are traversed, and the tools of the specified tool set are registered to the temporary MCP server instance; The temporary MCP server instance is identified as the new target MCP server instance to obtain the tool list in the target MCP server instance.

6. The enterprise internal service invocation method according to claim 1, characterized in that, Also includes: The system receives tool configuration change events in real time through a message subscription channel and parses these events to obtain the event change type and content. The independent MCP server instance is refreshed based on the event change type and the event change content to obtain the changed independent MCP server instance.

7. The enterprise internal service invocation method according to any one of claims 1 to 6, characterized in that, The internal service invocation of the target enterprise based on the target invocation tool and the invocation parameters includes: Based on the calling parameters, the target calling tool is invoked in the backend service of the target enterprise through the target MCP server instance, and the tool calling result is sent to the target large language model to generate the enterprise internal service calling result.

8. An internal service invocation device for an enterprise, characterized in that, include: The instance construction module is used to register the tools to be invoked corresponding to the target enterprise to the corresponding independent MCP server instances, and to construct independent URL endpoint paths containing domain identifiers for each independent MCP server instance; the tools to be invoked include basic tools under each standard domain and tool combinations selected from several standard domains; the standard domains are business domains divided based on the business type corresponding to the target enterprise; wherein, the first independent MCP server instance created for each standard domain is stored in the standard domain cache, and the second independent MCP server instance created for each preset custom domain is stored in the custom domain cache; When registering a combination of tools selected from several standard domains to a second independent MCP server instance corresponding to a preset custom domain, the tool identifier list of the preset custom domain is parsed, and a bidirectional mapping relationship between the tool identifier and the preset custom domain is established, so as to locate the affected preset custom domain based on the bidirectional mapping relationship; The request analysis module is used to receive service call requests initiated by the agent, determine the current domain identifier from the target URL endpoint path of the service call request, first search for the first independent MCP server instance corresponding to the current domain identifier in the standard domain cache, and if no match is found, search for the second independent MCP server instance corresponding to the current domain identifier in the custom domain cache, so as to determine the corresponding target MCP server instance according to the current domain identifier and the independent URL endpoint path. The service invocation module is used to obtain the tool list in the target MCP server instance, and send the service question in the service invocation request and the tool list to the target large language model to determine the target invocation tool and invocation parameters, so as to perform internal service invocation on the target enterprise based on the target invocation tool and the invocation parameters.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the enterprise internal service invocation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs, which, when executed by a processor, implement the enterprise internal service invocation method as described in any one of claims 1 to 7.

Images