Multi-tenant oriented third-party service calling method, device, system and equipment

Abstract

The disclosure provides a multi-tenant-oriented third-party service calling method, device, system and equipment, the method comprises the following steps: a self-defined transmission agent component parses a remote procedure call request into a protocol message according to an MCP protocol; a self-defined governance processing component determines whether the remote procedure call request contains a calling demand for a third-party service according to the protocol message; if the calling demand for the third-party service is contained, the self-defined governance processing component extracts tenant information in the protocol message and triggers a pre-stored original business processing component; the original business processing component routes the request to an MCP server running instance corresponding to the current tenant, and the MCP server running instance returns at least one third-party service information to the self-defined governance processing component; and the self-defined governance processing component screens out target service information matched with the tenant information from the at least one third-party service information.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, and in particular to a method, apparatus, system and device for invoking third-party services for multi-tenant environments. Background Technology

[0002] With the rapid development of Large Language Model (LLM) technology, the demand for external capabilities during inference is increasing, and the interaction methods between LLMs and external third-party services urgently need standardization. The Model Context Protocol (MCP) is an open standard that emerged in this context, aiming to standardize the communication methods between LLMs and external third-party services (such as tools, resources, and prompts), enabling models to discover and invoke the capabilities exposed by the server in a unified manner during inference.

[0003] The MCP protocol, based on the JSON-RPC 2.0 specification, employs a request-response Remote Procedure Call (RPC) communication model. It provides standardized protocol methods for service list queries, service invocation, and resource list queries, enabling different model clients to discover and invoke third-party service capabilities exposed by the server in a unified manner. In enterprise-level application scenarios, the MCP protocol is widely used to build intelligent agent backend services, third-party service invocation gateways, and AI capability open platforms, becoming a crucial communication foundation connecting large language models with external business systems.

[0004] However, the existing MCP SDK has significant design limitations. The MCP SDK uses a stateless architecture by default, designed to adapt to the horizontal scaling requirements of cloud-native environments. This assumes that any request can be handled independently by any instance, and instances do not need to share or pass context state related to the specific caller. While this design is beneficial for elastic scaling in general scenarios, it exposes many shortcomings in enterprise-level gateway governance scenarios.

[0005] Specifically, during the processing of metadata components such as service list queries, the SDK is unaware of the header information (such as API Key, tenant ID, and tracing ID) carried by the underlying HTTP transport layer. This prevents the gateway from distributing capabilities differentiated based on the caller's identity. This design becomes a fatal flaw in enterprise-level multi-tenant SaaS scenarios, because different tenants often need to see different lists of third-party services and use different resource quotas, while the SDK itself does not provide any identity awareness or permission management capabilities.

[0006] To overcome the above-mentioned shortcomings, existing technologies typically employ the following solutions, but all of them have significant technical problems:

[0007] (a) Directly modify the MCP SDK source code

[0008] Some companies choose to derive from the official SDK repository and hardcode tenant identity extraction and third-party service filtering logic at the source code level. While this approach can meet functional requirements, it is highly intrusive, compromising the SDK's type safety and encapsulation. More seriously, each SDK version upgrade requires re-merging conflicting code, resulting in high maintenance costs and the potential to introduce hidden compatibility flaws, making it difficult to keep up with the rapid evolution of the MCP protocol standard.

[0009] (II) Traditional Web Container Filter Interception Scheme

[0010] Another common approach is to deploy Servlet Filters at the Web container layer to implement authorization verification by intercepting HTTP requests. However, traditional Filters can only process raw HTTP message byte streams and cannot directly inject parsed Java objects (such as UserContext and service metadata) into the business logic of the MCP. Specifically, the Filter needs to manually read and concatenate the request body (InputStream can only be read once, so a request wrapper class must be introduced for stream caching), manually deserialize the JSON string into a generic data structure object, manually check JSON-RPC protocol fields (such as whether the protocol version is equal to "2.0", whether the method field is equal to the service list query method identifier), and manually concatenate the response string conforming to the JSON-RPC protocol and set the content type and character set. The entire process is cumbersome, error-prone, and cannot directly perceive the structure of third-party service objects defined in the business layer, posing serious type security risks.

[0011] (iii) Lack of multi-tenant isolation solutions

[0012] In multi-tenant scenarios, a single gateway container needs to provide isolated third-party service registration and independent MCP service endpoints for multiple tenants (distinguished by the tenant identifier mainInfoId). Existing technologies typically achieve isolation by deploying multiple applications, i.e., deploying an independent MCP service instance for each tenant. This approach consumes a lot of resources, has high operation and maintenance costs, and cannot achieve dynamic creation and destruction of tenant instances. In addition, at the request routing level, existing technologies lack a unified route aggregation mechanism, making it impossible to accurately route requests to the corresponding tenant's MCP server instance based on the tenant identifier in the request path within a single gateway container. This results in chaotic request distribution logic and poor scalability in multi-tenant scenarios.

[0013] (iv) Contextual Discontinuity Issues

[0014] In a stateless architecture, HTTP request context (such as authentication information and tracing IDs) cannot be automatically passed to the callbacks executed by third-party services. Traditional web container filters can only process HTTP messages and cannot pass the parsed identity information to the MCP protocol processing layer and the third-party service execution layer in a protocol-independent manner. This results in the business layer being unable to obtain the caller's identity and failing to achieve identity-based data isolation and operation auditing. This context gap significantly reduces the governance capabilities of enterprise-level gateways in multi-tenant scenarios. Summary of the Invention

[0015] The technical objective of this disclosure is to provide a method, apparatus, system, and device for invoking third-party services for multi-tenant environments.

[0016] Firstly, this disclosure provides a method for invoking third-party services in a multi-tenant environment, including:

[0017] In response to a remote procedure call request from an MCP client, a custom transport proxy component parses the remote procedure call request into a protocol message according to the MCP protocol and triggers a custom governance processing component; the transport proxy component is used to implement the stateless transport service component defined in the MCP SDK;

[0018] The custom governance processing component determines whether the remote procedure call request includes a call to a third-party service based on the protocol message.

[0019] If the request includes a call to a third-party service, the custom governance processing component extracts the tenant information from the protocol message and triggers the pre-stored original business processing component.

[0020] The original business processing component routes the request to the MCP server instance corresponding to the current tenant. The MCP server instance obtains at least one third-party service information corresponding to the call request of the third-party service and returns the at least one third-party service information to the custom governance processing component.

[0021] The custom governance processing component filters out target service information that matches the tenant information from the at least one third-party service information, and returns the target service information to the transport proxy component;

[0022] The transport proxy component encapsulates the target service information into a response to the remote procedure call request and returns it to the MCP client.

[0023] Furthermore, the method also includes:

[0024] During the dynamic creation of the MCP server instance, the transport proxy component is assembled as a gateway component, and the underlying network transport component defined by the SDK is injected as a dependency into the transport proxy component.

[0025] During the MCP SDK startup process, the transport proxy component intercepts the SDK's attempt to bind to the original business processing component and captures the reference of the original business processing component, thereby passing the reference of the original business processing component as a delegate object into the constructor of the transport proxy component.

[0026] The transport proxy component, which receives a reference to the original business processing component, is registered as the underlying network transport component of the MCP server runtime instance in the MCP SDK runtime environment, so that all subsequent remote procedure call requests arriving at the transport layer are received and processed by the transport proxy component.

[0027] Furthermore, the transport proxy component, which receives the reference to the original business processing component, is registered in the runtime environment of the MCP SDK, so that all subsequent remote procedure call requests arriving at the transport layer are received and processed by the transport proxy component, including:

[0028] The transport proxy component instantiates the custom governance processing component and injects the original business processing component as a delegate object into the custom governance processing component;

[0029] The transport proxy component, which contains the custom governance processing component, is registered in the SDK runtime environment as the underlying network transport component of the MCP server running instance. This allows subsequent remote procedure call requests arriving at the transport layer to be directly processed by the instantiated custom governance processing component after the transport proxy component completes protocol parsing.

[0030] Furthermore, the custom governance processing component and the original SDK business processing component are enhanced using the decorator pattern; the custom governance processing component wraps the original SDK business processing component inside it without changing it, and adds permission filtering and governance capabilities for third-party service calls.

[0031] Furthermore, the transmission proxy component implements the functions of the underlying network transmission components defined in the SDK, and the custom governance processing component implements the functions of the original service processing components defined in the SDK.

[0032] Furthermore, the custom governance processing component filters target service information that matches the tenant information from the at least one third-party service information, including:

[0033] The custom governance processing component determines whether the protocol method identifier carried in the parsed protocol message matches the preset service list query method identifier.

[0034] If a match is found, it is determined that the remote procedure call request contains a call requirement to a third-party service;

[0035] If there is no match, it is determined that the remote procedure call request does not contain a call requirement to a third-party service, and the custom governance processing component will directly and transparently delegate the protocol message to the internal original business processing component for processing.

[0036] Furthermore, the method also includes:

[0037] During gateway container initialization or tenant configuration update phases, an independent MCP server instance is allocated to each of the multiple tenants within a gateway container. Each MCP server instance has an independent third-party service registry, resource manager, and prompt word configuration. The route aggregation component is the routing component of the gateway container.

[0038] The routing aggregation component routes the request to the corresponding MCP server instance running for the current tenant based on the tenant identifier carried in the remote procedure call request, including:

[0039] The routing aggregation component extracts the tenant identifier of the remote procedure call request from the request path during the routing process;

[0040] The routing aggregation component searches for and matches the corresponding MCP server running instance from the tenant routing registry based on the tenant identifier, and transmits the remote procedure call request to the MCP server running instance corresponding to the tenant identifier, so as to invoke the MCP server running instance to process the remote procedure call request.

[0041] Furthermore, the method also includes:

[0042] When a new tenant is added, a mapping record between the tenant's tenant identifier and the corresponding MCP server running instance is added to the tenant routing registry.

[0043] Furthermore, the method also includes:

[0044] When updating an existing MCP server running instance of a tenant, a new MCP server running instance is created, and an update mapping record containing the new MCP server running instance is built in memory. The existing mapping record is replaced with the update mapping record using the CAS mechanism.

[0045] Asynchronously shut down the existing running instance of the MCP server.

[0046] Furthermore, the custom governance processing component extracts tenant information from the protocol message, including:

[0047] When parsing a remote procedure call request, the transport proxy component reads the authentication credentials and link tracing identifier from the request header of the remote procedure call request through a preset context extraction function, and encapsulates the authentication credentials and link tracing identifier into the metadata of a protocol-independent transport context object;

[0048] When processing protocol messages, the custom governance processing component extracts the authentication credentials from the metadata of the transport context object as tenant information.

[0049] Furthermore, the custom governance processing component filters target service information that matches the tenant information from the at least one third-party service information, including:

[0050] Based on the extracted tenant information, the preset tenant permission policy is queried to obtain the corresponding permission policy object, which includes a whitelist set and a blacklist set;

[0051] The system uses streaming computing to traverse at least one third-party service information returned by the original business processing component, and retains third-party service information items that do not belong to the blacklist set but belong to the whitelist set through predicate judgment.

[0052] The filtered set of third-party service information items is determined as the target service information.

[0053] Secondly, this disclosure provides a third-party service invocation device for multi-tenant environments, comprising:

[0054] The response module is configured to respond to remote procedure call requests from MCP clients. It uses a custom transport proxy component to parse the remote procedure call request into a protocol message according to the MCP protocol and triggers a custom governance processing component. The transport proxy component is used to implement the stateless transport service component defined in the MCP SDK.

[0055] The determination module is configured to use the custom governance processing component to determine, based on the protocol message, whether the remote procedure call request contains a call request to a third-party service.

[0056] The extraction module is configured to, if it contains a call requirement to a third-party service, use the custom governance processing component to extract tenant information from the protocol message and trigger the pre-stored original business processing component.

[0057] The routing module is configured to use the original business processing component to route requests to the MCP server running instance corresponding to the current tenant, and the MCP server running instance obtains at least one third-party service information corresponding to the call request of the third-party service, and returns the at least one third-party service information to the custom governance processing component.

[0058] The filtering module is configured to use the custom governance processing component to filter out target service information that matches the tenant information from the at least one third-party service information, and return the target service information to the transport proxy component;

[0059] The return module is configured to encapsulate the target service information into a response to the remote procedure call request using the transport proxy component, and then return it to the MCP client.

[0060] The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above function.

[0061] In one possible design, the above-described device includes a memory and a processor. The memory stores one or more computer instructions that support the device in performing the corresponding methods described above, and the processor is configured to execute the computer instructions stored in the memory. The device may also include a communication interface for communicating with other devices or communication networks.

[0062] Thirdly, this disclosure provides a third-party service invocation system for multi-tenant environments, including:

[0063] The routing aggregation module, as the global traffic entry point of the gateway container, is used to route the remote procedure call request to the corresponding MCP server running instance of the current tenant based on the tenant identifier carried in the remote procedure call request of the MCP client.

[0064] The transport proxy component is deployed inside the MCP server instance to implement the stateless transport service interface defined in the MCP SDK. It serves as the proxy entry point between the SDK and the underlying network layer. It is assembled as a gateway component during gateway container initialization and intercepts the SDK's attempt to bind to the original business processing component. It captures the reference of the original business processing component and registers the construction rules of the custom governance processing component internally. It has the ability to dynamically create the custom governance processing component.

[0065] A custom governance processor is used to implement the standard business processing interface defined by the SDK. As a proxy object, the original business processing component is injected into it as a delegate object. After receiving a remote procedure call request, it determines whether the request contains a call requirement for a third-party service according to the protocol message. If it does, it extracts the tenant information and triggers the original business processing component to obtain at least one third-party service information. Then, it filters out the target service information that matches the tenant information from the at least one third-party service information.

[0066] Furthermore, the system also includes:

[0067] A gateway container is used to assemble the transport proxy component into a gateway component during the dynamic creation of the MCP server instance, and to inject the underlying network transport components defined by the SDK as dependencies into the transport proxy component.

[0068] During the MCP SDK startup process, the transport proxy component intercepts the SDK's attempt to bind to the original business processing component and captures the reference of the original business processing component, thereby passing the reference of the original business processing component as a delegate object into the constructor of the transport proxy component.

[0069] The transport proxy component, which receives a reference to the original business processing component, is registered as the underlying network transport component of the MCP server runtime instance in the MCP SDK runtime environment, so that all subsequent remote procedure call requests arriving at the transport layer are received and processed by the transport proxy component.

[0070] Furthermore, the transport proxy component instantiates a custom governance processing component and injects the original business processing component as a delegate object into the custom governance processing component;

[0071] The transport proxy component, which contains the custom governance processing component, is registered in the SDK runtime environment as the underlying network transport component of the MCP server running instance. This allows subsequent remote procedure call requests arriving at the transport layer to be directly processed by the instantiated custom governance processing component after the transport proxy component completes protocol parsing.

[0072] Furthermore, the custom governance processing component and the original SDK business processing component are enhanced using the decorator pattern; the custom governance processing component wraps the original SDK business processing component inside it without changing it, and adds permission filtering and governance capabilities for third-party service calls.

[0073] Furthermore, the transmission proxy component implements the functions of the underlying network transmission components defined in the SDK, and the custom governance processing component implements the functions of the original service processing components defined in the SDK.

[0074] Furthermore, the custom governance processing component determines whether the protocol method identifier carried in the parsed protocol message matches the preset service list query method identifier; if they match, it is determined that the remote procedure call request contains a call requirement for a third-party service; if they do not match, it is determined that the remote procedure call request does not contain a call requirement for a third-party service, and the custom governance processing component directly and transparently delegates the protocol message to the internal original business processing component for processing.

[0075] Furthermore, during the gateway container initialization or tenant configuration update phase, an independent MCP server running instance is allocated to each of the multiple tenants within a gateway container. Each MCP server running instance has an independent third-party service registry, resource manager, and prompt word configuration. The route aggregation component is the routing component of the gateway container.

[0076] The routing aggregation component routes the request to the corresponding MCP server instance running for the current tenant based on the tenant identifier carried in the remote procedure call request, including:

[0077] The routing aggregation component extracts the tenant identifier of the remote procedure call request from the request path during the routing process;

[0078] The routing aggregation component searches for and matches the corresponding MCP server running instance from the tenant routing registry based on the tenant identifier, and transmits the remote procedure call request to the MCP server running instance corresponding to the tenant identifier, so as to invoke the MCP server running instance to process the remote procedure call request.

[0079] Furthermore, the system also includes:

[0080] The tenant route registration module is used to add a mapping record between the tenant identifier of the new tenant and the corresponding MCP server running instance to the tenant route registry when a new tenant is added.

[0081] Furthermore, the system also includes:

[0082] The atomic replacement engine component is used to create a new MCP server running instance when updating an existing MCP server running instance of a tenant, build an update mapping record containing the new MCP server running instance in memory, replace the existing mapping record with the update mapping record using a CAS mechanism, and asynchronously shut down the existing MCP server running instance.

[0083] Furthermore, when parsing a remote procedure call request, the transport proxy component reads the authentication credentials and link tracing identifier from the request header of the remote procedure call request through a preset context extraction function, and encapsulates the authentication credentials and link tracing identifier into the metadata of a protocol-independent transport context object;

[0084] When processing protocol messages, the custom governance processing component extracts the authentication credentials from the metadata of the transport context object as tenant information.

[0085] Furthermore, the custom governance processing component queries the preset tenant permission policy based on the extracted tenant information to obtain the corresponding permission policy object, which includes a whitelist set and a blacklist set; it uses streaming computing to traverse at least one third-party service information returned by the original business processing component, and retains third-party service information items that do not belong to the blacklist set but belong to the whitelist set through predicate judgment; and determines the filtered set of third-party service information items as the target service information.

[0086] Fourthly, embodiments of this disclosure provide an electronic device, including a memory and a processor. The memory stores one or more computer instructions that support any of the aforementioned devices in executing the corresponding methods described above. The processor is configured to execute the computer instructions stored in the memory. Any of the aforementioned devices may further include a communication interface for communicating with other devices or communication networks.

[0087] Fifthly, embodiments of this disclosure provide a computer-readable storage medium for storing computer instructions used by any of the above-described devices, including computer instructions for performing any of the above-described methods.

[0088] In a sixth aspect, embodiments of this disclosure provide a computer program product comprising computer instructions which, when executed by a processor, are used to implement the steps of the methods described in any of the preceding aspects.

[0089] The technical solutions provided in this disclosure may have the following beneficial effects:

[0090] This solution dynamically injects custom permission filtering logic into the protocol processing chain by triggering and wrapping "pre-stored original business processing components" without modifying the MCP SDK source code, achieving complete decoupling between governance logic and SDK source code. Furthermore, this solution only executes tenant information extraction and filtering logic when there are requests for third-party services (such as service list queries), allowing other protocol requests to pass directly, avoiding the performance overhead of full request interception. In addition, this disclosure directly manipulates the parsed protocol messages and third-party service information (Java objects), avoiding the type error risk caused by manually deserializing JSON strings in traditional Filter solutions; simultaneously, the underlying network transmission component is responsible for protocol parsing, and the custom governance processing component is responsible for business filtering, clearly defining responsibilities. This disclosure also ensures that different tenants can only see and call the third-party services they are authorized to access by extracting tenant information and dynamically filtering the returned third-party service information, fundamentally achieving capability isolation in multi-tenant scenarios.

[0091] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the embodiments of this disclosure. Attached Figure Description

[0092] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used in conjunction with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings:

[0093] Figure 1 A flowchart illustrating a multi-tenant-oriented third-party service invocation method according to an embodiment of the present disclosure is shown.

[0094] Figure 2 A flowchart illustrating a transport layer Handler injection mechanism according to an embodiment of the present disclosure is shown;

[0095] Figure 3 A flowchart illustrating multi-tenant dynamic instance management and route aggregation according to an embodiment of this disclosure is shown;

[0096] Figure 4 A flowchart illustrating protocol-level permission filtering according to an embodiment of the present disclosure is shown;

[0097] Figure 5 This is a schematic diagram of the structure of a computer system suitable for implementing a multi-tenant third-party service invocation method according to an embodiment of the present disclosure. Detailed Implementation

[0098] To make the purpose, technical solution and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings.

[0099] Corresponding to the description of the background art, the technical problems to be solved by this disclosure include:

[0100] Technical Problem 1: How to achieve non-intrusive, protocol-level governance logic injection without modifying the MCP SDK source code? Existing technologies, which directly modify the SDK source code, result in highly invasive code, high maintenance costs, and difficulties in version upgrades. This disclosure designs an injection mechanism based on the decorator pattern. By implementing the underlying network transmission components and original business processing components defined in the SDK, governance logic is dynamically injected into the SDK's protocol processing chain, achieving complete decoupling between the governance logic and the SDK source code.

[0101] Technical Issue 2: How to achieve end-to-end identity pass-through in a stateless architecture. The stateless design of the MCP SDK prevents the HTTP request context from being automatically passed to the third-party service execution callback, making it impossible for the business layer to obtain the caller's identity. This disclosure constructs a four-layer context passing chain from the access layer, transport layer, protocol layer to the execution layer, using a protocol-independent transport context object as an intermediate carrier to achieve seamless identity pass-through from HTTP request to third-party service execution.

[0102] Technical Issue 3: How to achieve multi-tenant MCP server instance isolation and dynamic management within a single gateway container. In multi-tenant scenarios, it is necessary to allocate an independent MCP server instance for each tenant, achieving complete isolation of third-party service registries, resource managers, and prompt word configurations. This disclosure designs a route aggregation component as the global traffic entry point for the gateway container. Based on the tenant identifier in the request path, it accurately routes requests to the corresponding tenant's MCP server instance and supports the dynamic creation and destruction of tenant instances.

[0103] Technical Issue 4: How to achieve hot updates of tenant instances without service interruption. When a tenant's third-party service configuration changes or a new service needs to be hot-loaded, traditional solutions require restarting the service instance, resulting in a large service unavailability window. This disclosure designs an atomic replacement mechanism, adopting a "build first, then switch" strategy to ensure that the service unavailability window is minimized during instance replacement, achieving hot updates that are imperceptible to the business.

[0104] Technical Issue 5: How to implement fine-grained dynamic filtering of third-party service lists. Different tenants and roles have different access permissions to third-party services, requiring dynamic whitelist / blacklist filtering of the third-party service list based on tenant identity. This disclosure intercepts service list query requests at the protocol layer, processes the third-party service list in a streaming manner based on a preset permission policy, and only returns metadata of third-party services that the current caller is authorized to access.

[0105] Technical Issue 6: How to ensure data isolation and end-to-end auditing capabilities among multiple tenants. In a multi-tenant scenario, it is essential to ensure that third-party service calls by tenant A do not affect tenant B, and that each third-party service call records the caller's identity and traceability information for troubleshooting and compliance auditing. This disclosure achieves strong isolation and end-to-end traceability among tenants through an independent third-party service registry, a context pass-through mechanism, and audit log recording.

[0106] To address the aforementioned technical issues, this disclosure proposes a transport layer Handler injection and context passing governance scheme for multi-tenant MCP gateways. This scheme employs a non-intrusive dynamic governance mechanism involving protocol layer interception and extraction, and delegated call filtering. Instead of intercepting the raw byte stream using traditional Web Filters, it allows the underlying network transport component to parse the request into protocol messages according to the MCP protocol, directly triggering a custom governance processing component. This custom governance processing component intelligently determines whether the current request contains a call to a third-party service (such as a service list query) based on the parsed protocol message. If a call request is detected, it extracts the tenant information from the protocol message and then triggers a pre-stored original business processing component. The original business processing component routes the request to the current tenant's MCP server instance to obtain full third-party service information. After obtaining the full information, the custom governance processing component filters based on the extracted tenant information, retaining only the target service information matching the tenant's permissions and returning it. This solution dynamically injects custom permission filtering logic into the protocol processing chain by triggering and wrapping "pre-stored original business processing components" without modifying the MCP SDK source code, achieving complete decoupling between governance logic and SDK source code. Furthermore, this solution only executes tenant information extraction and filtering logic when there are requests for third-party services (such as service list queries), allowing other protocol requests to pass directly, avoiding the performance overhead of full request interception. In addition, this disclosure directly manipulates the parsed protocol messages and third-party service information (Java objects), avoiding the type error risk caused by manually deserializing JSON strings in traditional Filter solutions; simultaneously, the underlying network transmission component is responsible for protocol parsing, and the custom governance processing component is responsible for business filtering, clearly defining responsibilities. This disclosure also ensures that different tenants can only see and call the third-party services they are authorized to access by extracting tenant information and dynamically filtering the returned third-party service information, fundamentally achieving capability isolation in multi-tenant scenarios.

[0107] To facilitate understanding of the technical solution of this invention, the relationship between the gateway container, the MCP software development kit (SDK), and the MCP server in the MCP architecture will first be explained:

[0108] The gateway container (such as an application container built on the Spring Boot framework) is the basic runtime environment that hosts the entire application, responsible for managing component lifecycles, dependency injection, and auto-configuration. The MCP SDK (such as the Spring AI MCPSDK) is a development toolkit for building MCP servers, providing underlying network transmission logic and raw business processing components. The MCP server is a server-side instance built using the MCP SDK, providing MCP protocol services to MCP clients. These three components form a hierarchical relationship of "runtime host—build tool—runtime instance": the gateway container provides the infrastructure upon which the application depends, the MCPSDK provides the tools and capabilities required for building, and the MCP server is the final runtime entity that provides services to the outside world after the combination of the two.

[0109] In terms of operational mechanism, the relationship among the three is as follows: When the gateway container starts, the initialization of the MCP SDK is triggered through the automatic configuration mechanism; during the initialization process, the MCP SDK creates the underlying network transmission component (i.e., the component that implements the underlying network transmission logic, responsible for receiving HTTP requests and encoding / decoding MCP protocol messages) and the original business processing component (i.e., the component that implements the various business processes specified by the MCP protocol, responsible for the various business processes specified by the MCP protocol), and binds the two to build an MCP server instance; this MCP server instance runs in the gateway container, receives remote procedure call requests from MCP clients through the underlying network transmission component, and hands them over to the original business processing component for processing.

[0110] From the perspective of the request processing chain, after a remote procedure call request is sent by the MCP client, it first reaches the underlying network transmission component for HTTP reception and protocol parsing. Then, the original business processing component completes the corresponding business processing according to the MCP protocol, and finally returns the processing result to the MCP client along the original chain. In other words, the gateway container is the runtime host of the MCP server, the MCP SDK is the tool foundation for building the MCP server, and the MCP server is the runtime entity that ultimately provides services to the MCP client. The governance scheme described in this invention operates precisely during the gateway container startup and MCP server initialization phases. By dynamically injecting governance logic between the transport layer and the business processing layer of the MCP SDK, non-intrusive multi-tenant access control is achieved.

[0111] Figure 1 A flowchart illustrating a multi-tenant third-party service invocation method according to an embodiment of this disclosure is shown, such as... Figure 1 As shown, the method for invoking third-party services for multi-tenants includes the following steps:

[0112] In step S101, in response to the remote procedure call request from the MCP client, the custom transport proxy component parses the remote procedure call request into a protocol message according to the MCP protocol parsing, and triggers the custom governance processing component; the transport proxy component is used to implement the stateless transport service component defined in the MCP SDK;

[0113] In step S102, the custom governance processing component determines whether the remote procedure call request includes a call to a third-party service based on the protocol message;

[0114] In step S103, if there is a request to call a third-party service, the custom governance processing component extracts the tenant information from the protocol message and triggers the pre-stored original business processing component.

[0115] In step S104, the original business processing component routes the request to the MCP server running instance corresponding to the current tenant. The MCP server running instance obtains at least one third-party service information corresponding to the call request of the third-party service and returns the at least one third-party service information to the custom governance processing component.

[0116] In step S105, the custom governance processing component filters out target service information that matches the tenant information from the at least one third-party service information, and returns the target service information to the transport proxy component;

[0117] In step S106, the transport proxy component encapsulates the target service information into a response to the remote procedure call request and returns it to the MCP client.

[0118] First, the overall architecture of the system described in this invention will be explained to better understand the collaborative relationships between the various embodiments. The system of this invention is architecturally divided into two core layers from top to bottom:

[0119] The first layer is the route aggregation layer: it is undertaken by the route aggregation component (`CompositeMcpRouterFunction`), which serves as the global traffic entry point for the gateway container and is responsible for routing remote procedure call requests to the corresponding tenant's MCP server instance based on the tenant identifier in the request path.

[0120] The second layer is the transport and governance layer: deployed within the MCP server instance of each tenant, it consists of a transport proxy component (`HandlerWrappingTransport`), a custom governance processing component (`ToolsListFilteringHandler`), and a raw business processing component (SDK internal Handler), responsible for protocol parsing, permission filtering, and business processing. The transport proxy component replaces the SDK's default underlying network transport component (`McpStatelessServerTransport`), and the custom governance processing component wraps the SDK's raw business processing component (`McpStatelessServerHandler`). Both use the decorator pattern to enhance capabilities without modifying the SDK source code.

[0121] The complete sequence of request processing is as follows: The MCP client initiates a remote procedure call request → The routing aggregation component routes the request to the corresponding tenant's MCP server instance based on the tenant identifier → The transport proxy component of that instance parses the protocol message and triggers the custom governance processing component → The custom governance processing component determines whether it is a third-party service call request; if so, it extracts the tenant information and triggers the original business processing component → The original business processing component returns the third-party service information → The custom governance processing component filters the target service information → The transport proxy component encapsulates the response and returns it to the MCP client.

[0122] Figure 1 The scheme shown is used for third-party service calls by the corresponding MCP client after the MCP server is running. It should be noted that the third-party services can include, but are not limited to, tools / components that can provide additional capabilities for large language models.

[0123] Before the MCP server starts running, in some embodiments, the method further includes:

[0124] During the dynamic creation of the MCP server instance, a custom transport proxy component is assembled as a gateway component, and the underlying network transport component is injected as a dependency into the transport proxy component; the transport proxy component is used to implement the stateless transport service component defined in the MCP SDK.

[0125] During the MCP SDK startup process, the transport proxy component intercepts the SDK's attempt to bind to the original business processing component and captures the reference of the original business processing component, thereby passing the reference of the original business processing component as a delegate object into the constructor of the transport proxy component.

[0126] The transport proxy component, which receives a reference to the original business processing component, is registered as the underlying network transport component of the MCP server runtime instance in the MCP SDK runtime environment, so that all subsequent remote procedure call requests arriving at the transport layer are received and processed by the transport proxy component.

[0127] In this embodiment, in order to achieve multi-tenant isolation in a multi-tenant scenario, an MCP server instance can be instantiated for each tenant, and the business logic for that tenant can be executed on that MCP server instance.

[0128] Therefore, during the dynamic construction of each tenant's MCP server instance, this embodiment assembles a custom transport proxy component as a gateway component. This injects the original underlying network transport component defined within the SDK as a dependency into the transport proxy component. During the MCP SDK startup process, the transport proxy component intercepts the operations of the original business processing component that the SDK attempts to bind to and captures a reference to that original business processing component. The purpose is to store this reference in the transport proxy component so that after the MCP server starts running, the transport proxy component can call the original business processing component to execute the corresponding business processing logic. The transport proxy component, which receives a reference to the original business processing component, is registered as the underlying network transport component of the MCP server instance in the SDK runtime environment. Thus, logic that would normally require processing by the original underlying network transport component defined within the SDK runtime environment is handled by the transport proxy component. For example, upon receiving a remote procedure call request from an MCP client, traditionally, this would be handled by the original underlying network transport component defined within the SDK; however, in this embodiment, it is handled by the transport proxy component.

[0129] In some embodiments, the transport proxy component, which receives a reference to the original business processing component, is registered in the runtime environment of the MCP SDK, so that all subsequent remote procedure call requests arriving at the transport layer are received and processed by the transport proxy component, including:

[0130] The transport proxy component instantiates the custom governance processing component and injects the original business processing component as a delegate object into the custom governance processing component;

[0131] The transport proxy component, which contains the custom governance processing component, is registered in the SDK runtime environment as the underlying network transport component of the MCP server running instance. This allows subsequent remote procedure call requests arriving at the transport layer to be directly processed by the instantiated custom governance processing component after the transport proxy component completes protocol parsing.

[0132] In this embodiment, when the transport proxy component is registered to the SDK runtime environment, it first instantiates a custom governance processing component and injects the original business processing component it intercepts and captures as a delegate object into the custom governance processing component. After the transport proxy component is registered to the SDK runtime environment, if a remote procedure call request is received, the transport proxy component completes the protocol parsing and triggers the instantiated custom governance processing component to process it. The custom governance processing component can implement the extended functions of this disclosure and can also call the original business processing component to process the original business.

[0133] In some embodiments, the custom governance processing component and the original SDK business processing component are enhanced using the decorator pattern; the custom governance processing component wraps the original SDK business processing component inside it without changing the original SDK business processing component, and adds permission filtering governance capabilities for third-party service calls.

[0134] In some embodiments, the transport proxy component implements the functionality of the underlying network transport component defined in the SDK, and the custom governance processing component implements the functionality of the original service processing component defined in the SDK. In other words, the transport proxy component replaces the underlying network transport component defined within the SDK, thus implementing the functionality of the underlying network transport component, while the custom governance processing component replaces the original service processing component defined within the SDK, thus implementing the functionality of the original service processing component.

[0135] In some embodiments, the custom governance processing component filters target service information that matches the tenant information from the at least one third-party service information, including:

[0136] The custom governance processing component determines whether the protocol method identifier carried in the parsed protocol message matches the preset service list query method identifier.

[0137] If a match is found, it is determined that the remote procedure call request contains a call requirement to a third-party service;

[0138] If there is no match, it is determined that the remote procedure call request does not contain a call requirement to a third-party service, and the custom governance processing component will directly and transparently delegate the protocol message to the internal original business processing component for processing.

[0139] The details of this disclosure are illustrated below through embodiments corresponding to the above-described architectural layers.

[0140] Example 1: Transport Layer Handler Injection Mechanism

[0141] This embodiment details how the present invention achieves non-intrusive governance logic injection through a transport proxy component within an MCP server runtime instance. The core of this embodiment lies in dynamically injecting a custom governance processing component into the SDK's protocol processing chain by implementing the underlying network transport logic defined in the SDK without modifying the MCP SDK source code, thus establishing an interception point for subsequent permission filtering.

[0142] As mentioned above, the gateway container (in this embodiment, an application container built on the Spring Boot framework is used as an example) is the basic runtime environment that supports the entire application and is responsible for managing the lifecycle of components, dependency injection, and automatic configuration. The MCP SDK (in this embodiment, the Spring AI MCP SDK is used as an example) is a development toolkit for building the MCP server, providing underlying network transport components (such as the `McpStatelessServerTransport` component) and raw business processing components (such as the `McpStatelessServerHandler` component). The MCP server is a server instance built using the MCP SDK and running within the gateway container, which receives remote procedure call requests from MCP clients through underlying network transport logic.

[0143] See Figure 2 As shown, the transport layer Handler injection mechanism in this embodiment mainly includes the following four steps:

[0144] Step S201: Component Assembly. During the gateway container initialization phase or tenant configuration update phase, the custom transport proxy component (`HandlerWrappingTransport`) is assembled as a gateway component using Spring Boot's auto-configuration mechanism. The transport proxy component implements the underlying network transport component defined by the MCP SDK (corresponding to the interface responsibilities defined by the `McpStatelessServerTransport` component), serving as the proxy entry point between the SDK and the underlying network layer. During the assembly process, the SDK's default underlying network transport component (i.e., the default implementation of `McpStatelessServerTransport`, responsible for underlying HTTP request reception and MCP protocol message encoding / decoding) is injected as a dependency into the transport proxy component, enabling the transport proxy component to delegate the actual message sending and receiving work to this underlying network transport component.

[0145] Step S202: Interception and Capture. During the MCP SDK startup process, the SDK calls the `setMcpHandler` method to attempt to bind the original business processing component (i.e., the Handler instance created internally by the SDK that implements the `McpStatelessServerHandler` component) to the transport layer. The transport proxy component intercepts this call, captures the reference to the original business processing component that the SDK is attempting to bind, and passes this reference as a delegate object to the transport proxy component for storage. This step is crucial to the entire injection mechanism, enabling the transport proxy component to gain access to the original business processing component without compromising the SDK's encapsulation.

[0146] Step S203: Rule Registration and Component Mounting. The transport proxy component registers the construction rules of the custom governance processing component (`ToolsListFilteringHandler`) internally, enabling it to dynamically create custom governance processing components. Subsequently, the transport proxy component, injected with the delegate object, is registered as the underlying network transport logic of the MCP server runtime instance in the SDK runtime environment, replacing the SDK's default underlying network transport component. In this way, all subsequent remote procedure call requests arriving at the transport layer will trigger the custom governance processing component for processing after the transport proxy component completes protocol parsing.

[0147] Step S204: Request Processing Flow. When the transport proxy component receives a remote procedure call request, the processing flow is as follows: The instantiated custom governance processing component intercepts the remote procedure call request, determines whether the request contains a call to a third-party service based on the protocol message, and if so, extracts the tenant information and triggers the original business processing component to obtain the third-party service information. Then, it filters out the target service information that matches the tenant information from the returned third-party service information; finally, the transport proxy component encapsulates the target service information into a response and returns it to the MCP client.

[0148] It is important to note that in this embodiment, the custom governance processing component and the original SDK business processing component are enhanced using the decorator pattern. After intercepting and capturing the original SDK business processing component, the transport proxy component injects it as a delegate object into the custom governance processing component. Thus, without altering the original SDK business processing component, the custom governance processing component wraps the original business processing component internally, thereby non-intrusively adding governance capabilities such as multi-tenant permission filtering. In other words, the custom governance processing component implements the interface corresponding to the original business processing component defined by the SDK and adds governance responsibilities at the outer layer; all subsequent remote procedure call requests will first be governed and judged by the outer custom governance processing component, and then executed as needed by the inner original business processing component, achieving seamless replacement and enhancement of the request chain. Through the above mechanism, this embodiment successfully injects a custom governance processing component with multi-tenant governance capabilities into the MCP protocol request processing chain without modifying the SDK source code, establishing an interception point for subsequent dynamic filtering.

[0149] In some embodiments, the method further includes:

[0150] During gateway container initialization or tenant configuration update, an independent MCP server instance is allocated to each of the multiple tenants within a gateway container. Each MCP server instance has an independent third-party service registry, resource manager, and prompt word configuration. The route aggregation component is the routing component of the gateway container.

[0151] The routing aggregation component routes the request to the corresponding MCP server instance running for the current tenant based on the tenant identifier carried in the remote procedure call request, including:

[0152] The routing aggregation component extracts the tenant identifier of the remote procedure call request from the request path during the routing process;

[0153] The routing aggregation component searches for and matches the corresponding MCP server running instance from the tenant routing registry based on the tenant identifier, and transmits the remote procedure call request to the MCP server running instance corresponding to the tenant identifier, so as to invoke the MCP server running instance to process the remote procedure call request.

[0154] In some embodiments, the method further includes:

[0155] When a new tenant is added, a mapping record between the tenant's tenant identifier and the corresponding MCP server running instance is added to the tenant routing registry.

[0156] In some embodiments, the method further includes:

[0157] When updating an existing MCP server running instance of a tenant, a new MCP server running instance is created, and an update mapping record containing the new MCP server running instance is built in memory. The existing mapping record is replaced with the update mapping record using the CAS mechanism.

[0158] Asynchronously shut down the existing running instance of the MCP server.

[0159] The above multi-tenant scenario is described below through corresponding embodiments.

[0160] Example 2: Multi-tenant Dynamic Instance Management and Route Aggregation

[0161] This embodiment, based on Embodiment 1, further elaborates on the routing aggregation and dynamic instance management workflow of the gateway container when handling multi-tenant requests. This embodiment aims to solve the problem of how a single gateway container can provide isolated third-party service registration and independent endpoints for multiple tenants, and is the core implementation of the routing aggregation layer in the architecture of this invention.

[0162] As mentioned earlier, the MCP server is a server-side instance built using the MCP SDK and running within a gateway container. This embodiment creates an independent MCP server instance for each tenant within a single gateway container. The overall architecture comprises four core components: a tenant routing registry (`TenantRouterRegistry`), a tenant-specific MCP server instance, a route aggregation component (`CompositeMcpRouterFunction`), and an atomic replacement engine component. See also... Figure 3 As shown, this embodiment includes:

[0163] Step S301: Construct the route aggregation component. This component implements the gateway container's routing component (such as the `RouterFunction` component in Spring WebFlux), serving as the global traffic entry point for the gateway container. In the routing method, the tenant identifier of the current request (e.g., `mainInfoId` in the path ` / mcp / {mainInfoId}`) is first extracted from the request path using a path variable extraction method (e.g., the `ServerRequest.pathVariable` method). Then, the corresponding MCP server instance is searched in the tenant routing registry. If a corresponding instance is found, the routing logic within that instance is called to process the request; otherwise, a "not found" response is returned directly. This step is the "first checkpoint" before the request enters the MCP server instance, ensuring that each request is accurately routed to the corresponding tenant instance.

[0164] Step S302: Implement tenant-level MCP server instance isolation. Each tenant's MCP server instance is bound to a dedicated third-party service registry during initialization. When tenant A registers a third-party service, the service metadata is stored only in the memory of tenant A's MCP server instance. When tenant B initiates a service list query request, the routing aggregation component routes it to tenant B's MCP server instance, thus naturally achieving isolation of the third-party service list. This instance-based isolation method ensures that third-party service calls between tenants do not interfere with each other, meeting the compliance requirements of enterprise-level SaaS for tenant data isolation. It is important to emphasize that each tenant's MCP server instance deploys the transport proxy component and custom governance processing component described in Example 1, forming a complete transport and governance layer.

[0165] Step S303: Implementation Mechanism of the Atomic Replacement Engine Component. This step describes the data structures and concurrency control mechanisms used by the atomic replacement engine component within the tenant routing registry, providing underlying capabilities for subsequent hot updates. Instance replacement methods (such as the `replaceServer` method) are implemented in the tenant routing registry. These methods internally employ either a read-write lock (`ReentrantReadWriteLock`) or an atomic reference (`AtomicReference`). <map>To ensure concurrency safety, it maintains an internal mapping record of "tenant identifier → MCP server running instance" and provides atomic record replacement capability: after constructing an updated mapping record containing the new instance in memory, it uses a CAS (Compare-And-Swap) mechanism to atomically replace the existing mapping record with the updated mapping record. Because it uses a lock-free CAS mechanism or a read-write lock mechanism, the replacement process is not blocking, and newly arriving requests are immediately routed to the new instance after the replacement is complete.

[0166] Step S304: Dynamic Instance Replacement Process (Hot Update). This step describes the complete process of hot update, where the mechanism described in step S303 is invoked end-to-end after a configuration change is triggered on the operations and maintenance side. When the operations and maintenance system triggers a third-party service configuration update for a tenant (e.g., `tenant_1001`), the atomic replacement engine component executes in the following order:

[0167] 1. Background pre-built instance: Create a new MCP server instance in the background and complete the registration and initialization of the new third-party service; at this time, the old MCP server instance is still providing services to the outside world;

[0168] 2. Construct update mapping record: Construct an update mapping record in memory containing the new running instance of the MCP server;

[0169] 3. Atomic replacement: Invoke the instance replacement method described in step S303, and use the CAS mechanism to atomically replace the existing mapping record in the tenant routing registry with the updated mapping record. At this time, newly arriving requests will be immediately routed to the new instance.

[0170] 4. Asynchronous shutdown: The existing MCP server instance is shut down asynchronously. The system will wait for the old instance to finish processing the currently executing requests before safely destroying and releasing resources.

[0171] Through the above mechanism, the entire hot update process is almost imperceptible to the business side, completely eliminating the "window period" in the service replacement process, and the service unavailability window can be controlled at the millisecond level.

[0172] Step S305: Linear Scalability. Adding a new tenant only requires adding a mapping record between the tenant identifier and the running instance of the MCP server in the tenant routing registry, without modifying the core routing code. This design aligns with the scalability requirements of multi-tenant SaaS architectures, allowing the system to support linear scaling from dozens to tens of thousands of tenants, and adding a new tenant will not affect the service stability of existing tenants.

[0173] The technical solution in this embodiment achieves strong isolation (each tenant runs an independent MCP server instance), dynamic seamlessness (atomic replacement mechanism ensures seamless hot updates), and linear scalability (adding a new tenant only requires adding a mapping record), which meets the expansion requirements of multi-tenant SaaS architecture.

[0174] In some embodiments, the custom governance processing component extracts tenant information from the protocol message, including:

[0175] When parsing a remote procedure call request, the transport proxy component reads the authentication credentials and link tracing identifier from the request header of the remote procedure call request through a preset context extraction function, and encapsulates the authentication credentials and link tracing identifier into the metadata of a protocol-independent transport context object;

[0176] When processing protocol messages, the custom governance processing component extracts the authentication credentials from the metadata of the transport context object as tenant information.

[0177] This embodiment implements a four-layer context passing chain. This chain includes: an access layer, a transport layer, a protocol layer, and an execution layer. The access layer intercepts all requests pointing to the MCP service path through an access layer filter, parses the caller identity (such as authentication credentials and tracing identifiers) from the remote procedure call request header, and temporarily stores it in the request attributes of the remote procedure call request. The transport layer is executed by a transport proxy component, which calls a custom context extraction function when processing remote procedure call requests to read request attributes from the remote procedure call request, thereby encapsulating the caller identity into the metadata of a protocol-independent transport context object. The protocol layer is executed by a custom governance processing component, which extracts the caller identity from the metadata of the transport context object and performs permission filtering. In the execution layer, before the original business processing component prepares to execute a specific third-party service callback, it extracts the caller identity from the metadata of the transport context object and constructs it into the execution context, enabling the specific third-party service implementation method to directly obtain the current caller identity from the execution context.

[0178] The details of this disclosure are described below in terms of the upper and lower layers of the overall architecture.

[0179] Example 3: Full-link transparent transmission of the four-layer context passing link

[0180] This embodiment addresses the pain point of the MCP SDK in stateless mode, where HTTP request context (such as authentication information, tracing ID, etc.) cannot be automatically passed to the execution callback of third-party services. It proposes a "four-layer context passing link" from the network layer to the business execution layer, achieving end-to-end identity pass-through and auditing. The core of this embodiment lies in breaking down the isolation between the gateway container and the MCP protocol layer, constructing a standardized context passing channel. The four layers, from top to bottom, are the access layer, transport layer, protocol layer, and execution layer, respectively handled by the gateway container's access layer filter, transport proxy component, custom governance processing component, and original business processing component, corresponding one-to-one with the components of this invention.

[0181] Layer 1 - Access Layer: Identity Injection. This layer is implemented by the access layer filter of the gateway container. The filtering method intercepts all requests pointing to the MCP service path, parses the authentication credentials and link tracing identifier in the network request header, and temporarily stores them in the request attributes.

[0182] The second layer, the transport layer, is responsible for context extraction. This layer is handled by the transport proxy component described in Example 1. When the transport proxy component intercepts a remote procedure call request and performs protocol parsing, it triggers a pre-defined custom context extraction function. This function reads the request attributes temporarily stored in the access layer from the network request object and encapsulates them into the metadata of a protocol-independent transport context object.

[0183] The third layer, the protocol layer, is the permission interception layer. This layer is handled by the custom governance processing component described in Example 1. When processing protocol messages, the custom governance processing component extracts the caller's identity from the metadata of the transport context object generated by the transport proxy component, thus completing permission filtering.

[0184] The fourth layer, the execution layer, is the business pass-through layer. This layer occurs after the original business processing component routes the request and before executing the third-party service. Before the original business processing component prepares to execute the specific third-party service callback, the system extracts identity information from the current transport context object and manually constructs it into the execution context, enabling the specific third-party service implementation method to directly obtain the caller's identity.

[0185] The end-to-end timing sequence is as follows:

[0186] 1. Access Request: The MCP client initiates a remote procedure call request, with the authentication credential `X-API-KEY: abc-123` carried in the request header;

[0187] 2. Route Aggregation: The route aggregation component routes requests to the corresponding tenant's MCP server instance based on the tenant identifier in the request path;

[0188] 3. Access layer injection: The access layer filter intercepts the request and executes `request.setAttribute("ctx_apiKey", "abc-123")`;

[0189] 4. Transport Layer Extraction: The context extraction function of the transport proxy component is triggered, reads the request properties, and generates a transport context object containing authentication credentials;

[0190] 5. Protocol layer authentication: A custom governance processing component receives requests, extracts authentication credentials from the transport context object, and completes permission filtering for service list queries;

[0191] 6. Execution layer construction: When a user calls a specific third-party service, the execution layer injection module injects authentication credentials into the execution context;

[0192] 7. Business Execution: The specific third-party service implementation class obtains authentication credentials from the execution context, executes business logic with tenant isolation, and records audit logs containing tracing identifiers.

[0193] Through the technical solution of this embodiment, the system achieves end-to-end connectivity (seamless identity pass-through from HTTP request to third-party service execution), protocol decoupling (business logic is completely unaware of the underlying transport protocol), and security auditing (a unified context passing mechanism provides a technical foundation for multi-tenant data isolation and end-to-end operation auditing).

[0194] In some embodiments, the custom governance processing component filters target service information that matches the tenant information from the at least one third-party service information, including:

[0195] Based on the extracted tenant information, the preset tenant permission policy is queried to obtain the corresponding permission policy object, which includes a whitelist set and a blacklist set;

[0196] The system uses streaming computing to traverse at least one third-party service information returned by the original business processing component, and retains third-party service information items that do not belong to the blacklist set but belong to the whitelist set through predicate judgment.

[0197] The filtered set of third-party service information items is determined as the target service information.

[0198] Example 4: Specific Implementation of Protocol-Level Permission Filtering Algorithm

[0199] This embodiment details the implementation of a fine-grained permission filtering algorithm for the service list query component. Based on stream computing (Stream API) and predicate judgment, the algorithm dynamically filters the original list of third-party services returned by the SDK, returning only information on third-party services that the current caller is authorized to access.

[0200] Scenario Description: Tenant A (authentication credentials: `abc123`) requests a list of third-party services. The system needs to hide the "Database Management Service". Assume the original third-party service list includes: [Code Editor, Database Manager, File Uploader] . See also Figure 4 As shown, this embodiment includes:

[0201] Step S401: Handler Injection. During the gateway container startup and MCP server instance initialization process, the assembly, interception, injection, and registration process described in Example 1 is executed. The transport proxy component successfully injects a custom governance processing component with multi-tenant governance capabilities into the MCP protocol request processing chain, establishing an interception point for subsequent dynamic filtering.

[0202] Step S402: Route Aggregation and Request Distribution. The MCP client initiates a service list query request with the request path ` / mcp / tenant_A / tools / list`. The route aggregation component extracts the tenant identifier `tenant_A` from the request path, finds the corresponding MCP server instance in the tenant route registry, and distributes the request to that instance. The transport proxy component of that instance receives the request, parses the protocol message, and triggers the custom governance processing component.

[0203] Step S403: Protocol-level dynamic permission filtering. When the custom governance processing component receives a request, the process is as follows:

[0204] 1. Interception and Extraction: The custom governance processing component extracts the caller's identity identifier (authentication credential: `abc123`) from the currently bound transport context object.

[0205] 2. Policy Matching: Based on the extracted identity identifier, query the preset tenant permission policy and obtain the permission policy object corresponding to the authentication credential. For example, the whitelist set `allowSet = {code editor, file uploader}` and the blacklist set `denySet = {database manager}`.

[0206] 3. Streaming Filtering: The custom governance processing component first triggers the internally delegated original business processing component to obtain the full list of third-party services. Then, it uses the Stream API to iterate through the full list of third-party services, applying predicate judgments for filtering during the iteration—only retaining third-party service information items that meet the condition of "not belonging to the blacklist set (`denySet`) and belonging to the whitelist set (`allowSet`)". For example, for "Database Manager", it is determined that it belongs to `denySet`, the predicate judgment is `false`, and it is removed; for "Code Editor", it is determined that it does not belong to `denySet` and belongs to `allowSet`, the predicate judgment is `true`, and it is retained.

[0207] 4. Response Return: The filtered set of third-party service information items is determined as the target service information. The transmission proxy component, which serves as the underlying network transmission logic, encapsulates the information into an MCP protocol response and returns it to the MCP client, thereby achieving isolation of third-party service resources in a multi-tenant environment.

[0208] Step S404: Context Transmission and Auditing. In the third-party service callback method, directly obtain the caller information (including authentication credentials and tracing identifier) ​​from the execution context and record the operation log. The log content includes key information such as caller identity, call time, name of the called third-party service, and tracing identifier, for subsequent troubleshooting and compliance auditing.

[0209] Data structure definition: Third-party service metadata includes two attributes: a unique service identifier and the service visibility scope; tenant permission policies include two attributes: a whitelist set and a blacklist set. Permission policies are stored in a Redis cache or a relational database, supporting dynamic updates. When tenant permissions change, only the policy records in the cache or database need to be updated, without restarting the service.

[0210] Through the technical solution of this embodiment, the system achieves non-intrusiveness (no need to modify the MCP SDK source code, and realizes functional extension through the decorator pattern), type safety (directly operate on the SDK's native business objects, avoiding type errors caused by manually parsing JSON strings) and flexible governance (dynamic third-party service list filtering based on tenant identity, meeting the multi-tenant isolation requirements of enterprise-level SaaS).

[0211] The technical solution of the present invention has significant advantages:

[0212] 1. Non-intrusive protocol-level injection: This invention intercepts the operation of the SDK binding the original business processing component at the protocol layer through the transport proxy component, and passes the original business processing component as a delegate object to the custom governance processing component. The entire interception process is completed in the protocol processing link of the SDK without manipulating the original byte stream, thereby overcoming the problems of strong intrusion of "directly modifying the SDK source code" and insecurity of "traditional filter interception of the original byte stream" in the background technology.

[0213] 2. Type-safe operation of native objects: This invention directly operates on the SDK's native business objects and uses streaming computing for streaming filtering, eliminating the need for manual deserialization of JSON strings and ensuring type safety;

[0214] 3. Protocol-independent context passing: This invention passes identity information through a protocol-independent transmission context object, without requiring modification of the request / response format, and completely decouples governance logic from business logic;

[0215] 4. Multi-tenant isolation and dynamic management: This invention also realizes the isolation and dynamic management (including atomic replacement hot update) of multi-tenant MCP server running instances through the route aggregation component, which is a capability that traditional Filter solutions cannot achieve.

[0216] In summary, the solution of this invention is significantly superior to traditional Web container Filter solutions in terms of code simplicity, type safety, maintainability, multi-tenant isolation capability, and performance.

[0217] According to an embodiment of this disclosure, a third-party service invocation device for multi-tenants can be implemented as part or all of an electronic device through software, hardware, or a combination of both. The third-party service invocation device for multi-tenants includes:

[0218] The response module is configured to respond to remote procedure call requests from MCP clients. It uses a custom transport proxy component to parse the remote procedure call request into a protocol message according to the MCP protocol and triggers a custom governance processing component. The transport proxy component is used to implement the stateless transport service component defined in the MCP SDK.

[0219] The determination module is configured to use the custom governance processing component to determine, based on the protocol message, whether the remote procedure call request contains a call request to a third-party service.

[0220] The extraction module is configured to, if it contains a call requirement to a third-party service, use the custom governance processing component to extract tenant information from the protocol message and trigger the pre-stored original business processing component.

[0221] The routing module is configured to use the original business processing component to route requests to the MCP server running instance corresponding to the current tenant, and the MCP server running instance obtains at least one third-party service information corresponding to the call request of the third-party service, and returns the at least one third-party service information to the custom governance processing component.

[0222] The filtering module is configured to use the custom governance processing component to filter out target service information that matches the tenant information from the at least one third-party service information, and return the target service information to the transport proxy component;

[0223] The return module is configured to encapsulate the target service information into a response to the remote procedure call request using the transport proxy component, and then return it to the MCP client.

[0224] The third-party service invocation device for multi-tenancy corresponds to the third-party service invocation method for multi-tenancy mentioned above. For details, please refer to the description of the third-party service invocation method for multi-tenancy mentioned above, which will not be repeated here.

[0225] According to an embodiment of the multi-tenant third-party service invocation system disclosed herein, the device can be implemented as part or all of an electronic device through software, hardware, or a combination of both. The multi-tenant third-party service invocation system includes:

[0226] The routing aggregation module, as the global traffic entry point of the gateway container, is used to route the remote procedure call request to the corresponding MCP server running instance of the current tenant based on the tenant identifier carried in the remote procedure call request of the MCP client.

[0227] The transport proxy component is deployed inside the MCP server instance to implement the stateless transport service interface defined in the MCP SDK. It serves as the proxy entry point between the SDK and the underlying network layer. It is assembled as a gateway component during gateway container initialization and intercepts the SDK's attempt to bind to the original business processing component. It captures the reference of the original business processing component and registers the construction rules of the custom governance processing component internally. It has the ability to dynamically create the custom governance processing component.

[0228] A custom governance processor is used to implement the standard business processing interface defined by the SDK. As a proxy object, the original business processing component is injected into it as a delegate object. After receiving a remote procedure call request, it determines whether the request contains a call requirement for a third-party service according to the protocol message. If it does, it extracts the tenant information and triggers the original business processing component to obtain at least one third-party service information. Then, it filters out the target service information that matches the tenant information from the at least one third-party service information.

[0229] In some embodiments, the system further includes:

[0230] A gateway container is used to assemble the transport proxy component into a gateway component during the dynamic creation of the MCP server instance, and to inject the underlying network transport components defined by the SDK as dependencies into the transport proxy component.

[0231] During the MCP SDK startup process, the transport proxy component intercepts the SDK's attempt to bind to the original business processing component and captures the reference of the original business processing component, thereby passing the reference of the original business processing component as a delegate object into the constructor of the transport proxy component.

[0232] The transport proxy component, which receives a reference to the original business processing component, is registered as the underlying network transport component of the MCP server runtime instance in the MCP SDK runtime environment, so that all subsequent remote procedure call requests arriving at the transport layer are received and processed by the transport proxy component.

[0233] In some embodiments, the transport proxy component instantiates a custom governance processing component and injects the original business processing component as a delegate object into the custom governance processing component;

[0234] The transport proxy component, which contains the custom governance processing component, is registered in the SDK runtime environment as the underlying network transport component of the MCP server running instance. This allows subsequent remote procedure call requests arriving at the transport layer to be directly processed by the instantiated custom governance processing component after the transport proxy component completes protocol parsing.

[0235] In some embodiments, the custom governance processing component and the original SDK business processing component are enhanced using the decorator pattern; the custom governance processing component wraps the original SDK business processing component inside it without changing the original SDK business processing component, and adds permission filtering governance capabilities for third-party service calls.

[0236] In some embodiments, the transport proxy component implements the functionality of the underlying network transport component defined by the SDK, and the custom governance processing component implements the functionality of the original service processing component defined by the SDK.

[0237] In some embodiments, the custom governance processing component determines whether the protocol method identifier carried in the parsed protocol message matches a preset service list query method identifier; if they match, it is determined that the remote procedure call request contains a call requirement for a third-party service; if they do not match, it is determined that the remote procedure call request does not contain a call requirement for a third-party service, and the custom governance processing component directly and transparently delegates the protocol message to the internal original business processing component for processing.

[0238] In some embodiments, during gateway container initialization or tenant configuration update phases, an independent MCP server running instance is allocated to each of the multiple tenants in a gateway container. The MCP server running instance has an independent third-party service registry, resource manager, and prompt word configuration; wherein, the route aggregation component is the routing component of the gateway container.

[0239] The routing aggregation component routes the request to the corresponding MCP server instance running for the current tenant based on the tenant identifier carried in the remote procedure call request, including:

[0240] The routing aggregation component extracts the tenant identifier of the remote procedure call request from the request path during the routing process;

[0241] The routing aggregation component searches for and matches the corresponding MCP server running instance from the tenant routing registry based on the tenant identifier, and transmits the remote procedure call request to the MCP server running instance corresponding to the tenant identifier, so as to invoke the MCP server running instance to process the remote procedure call request.

[0242] In some embodiments, the system further includes:

[0243] The tenant route registration module is used to add a mapping record between the tenant identifier of the new tenant and the corresponding MCP server running instance to the tenant route registry when a new tenant is added.

[0244] In some embodiments, the system further includes:

[0245] The atomic replacement engine component is used to create a new MCP server running instance when updating an existing MCP server running instance of a tenant, build an update mapping record containing the new MCP server running instance in memory, replace the existing mapping record with the update mapping record using a CAS mechanism, and asynchronously shut down the existing MCP server running instance.

[0246] In some embodiments, when parsing a remote procedure call request, the transport proxy component reads the authentication credentials and link tracing identifier from the request header of the remote procedure call request through a preset context extraction function, and encapsulates the authentication credentials and link tracing identifier into the metadata of a protocol-independent transport context object;

[0247] When processing protocol messages, the custom governance processing component extracts the authentication credentials from the metadata of the transport context object as tenant information.

[0248] In some embodiments, the custom governance processing component queries a preset tenant permission policy based on the extracted tenant information to obtain a corresponding permission policy object, wherein the permission policy object includes a whitelist set and a blacklist set; it uses streaming computing to traverse at least one third-party service information returned by the original business processing component, and retains third-party service information items that do not belong to the blacklist set but belong to the whitelist set through predicate judgment; and determines the filtered set of third-party service information items as the target service information.

[0249] The technical features and their corresponding explanations and descriptions involved in the above-described device embodiments are the same as, corresponding to, or similar to the technical features and their corresponding explanations and descriptions involved in the above-described method embodiments. For the technical features and their corresponding explanations and descriptions involved in the above-described device embodiments, please refer to the technical features and their corresponding explanations and descriptions involved in the above-described method embodiments. This disclosure will not repeat them here.

[0250] This disclosure also discloses an electronic device, which includes a memory and a processor; wherein...

[0251] The memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement any of the above method steps.

[0252] Figure 5 This is a schematic diagram of the structure of a computer system suitable for implementing a multi-tenant third-party service invocation method according to an embodiment of the present disclosure.

[0253] like Figure 5 As shown, the computer system 500 includes a processing unit 501, which can execute various processes described above based on a program stored in a read-only memory (ROM) 502 or a program loaded from a storage section 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the computer system 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0254] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 510 as needed so that computer programs read from it can be installed into storage section 508 as needed. The processing unit 501 can be implemented as a CPU, GPU, TPU, FPGA, NPU, etc.

[0255] In particular, according to embodiments of this disclosure, the methods described above can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program tangibly embodied on a readable medium thereof, the computer program containing program code for performing the data transmission method. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511.

[0256] This disclosure also discloses a computer program product, which includes a computer program / instructions that, when executed by a processor, implement any of the above-described method steps.

[0257] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0258] The units or modules described in the embodiments of this disclosure can be implemented in software or hardware. The described units or modules can also be located in a processor, and the names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0259] In another aspect, embodiments of this disclosure also provide a computer-readable storage medium, which may be a computer-readable storage medium included in the apparatus described in the above embodiments; or it may be a standalone computer-readable storage medium not assembled into a device. The computer-readable storage medium stores one or more programs, which are used by one or more processors to perform the methods described in embodiments of this disclosure.

[0260] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.< / map>

Claims

1. A method for invoking third-party services in a multi-tenant environment, characterized in that: include: In response to a remote procedure call request from an MCP client, the custom transport proxy component parses the remote procedure call request into a protocol message according to the MCP protocol and triggers the custom governance processing component. The transport proxy component is used to implement the stateless transport service component defined in the MCP SDK; The custom governance processing component determines whether the remote procedure call request includes a call to a third-party service based on the protocol message. If the request includes a call to a third-party service, the custom governance processing component extracts the tenant information from the protocol message and triggers the pre-stored original business processing component. The original business processing component routes the request to the MCP server instance corresponding to the current tenant. The MCP server instance obtains at least one third-party service information corresponding to the call request of the third-party service and returns the at least one third-party service information to the custom governance processing component. The custom governance processing component filters out target service information that matches the tenant information from the at least one third-party service information, and returns the target service information to the transport proxy component; The transport proxy component encapsulates the target service information into a response to the remote procedure call request and returns it to the MCP client.

2. The method according to claim 1, characterized in that, The method further includes: During the dynamic creation of the MCP server instance, the transport proxy component is assembled as a gateway component, and the underlying network transport component defined by the SDK is injected as a dependency into the transport proxy component. During the MCP SDK startup process, the transport proxy component intercepts the SDK's attempt to bind to the original business processing component and captures the reference of the original business processing component, thereby passing the reference of the original business processing component as a delegate object into the constructor of the transport proxy component. The transport proxy component, which receives a reference to the original business processing component, is registered as the underlying network transport component of the MCP server runtime instance in the MCP SDK runtime environment, so that all subsequent remote procedure call requests arriving at the transport layer are received and processed by the transport proxy component.

3. The method according to claim 2, characterized in that, The transport proxy component, which receives a reference to the original business processing component, is registered in the MCP SDK runtime environment, so that all subsequent remote procedure call requests arriving at the transport layer are received and processed by the transport proxy component, including: The transport proxy component instantiates the custom governance processing component and injects the original business processing component as a delegate object into the custom governance processing component; The transport proxy component, which contains the custom governance processing component, is registered in the SDK runtime environment as the underlying network transport component of the MCP server running instance. This allows subsequent remote procedure call requests arriving at the transport layer to be directly processed by the instantiated custom governance processing component after the transport proxy component completes protocol parsing.

4. The method according to claim 2 or 3, characterized in that, The custom governance component enhances the business component by using the decorator pattern with the original SDK business component. The custom governance component wraps the original SDK business component inside it without changing it, and adds permission filtering and governance capabilities for third-party service calls.

5. The method according to claim 2 or 3, characterized in that, The transmission proxy component implements the functions of the underlying network transmission components defined in the SDK, and the custom governance processing component implements the functions of the original service processing components defined in the SDK.

6. A third-party service invocation device for multi-tenant environments, characterized in that, include: The response module is configured to respond to remote procedure call requests from MCP clients by using a custom transport proxy component to parse the remote procedure call request into a protocol message according to the MCP protocol and trigger a custom governance processing component. The transport proxy component is used to implement the stateless transport service component defined in the MCP SDK; The determination module is configured to use the custom governance processing component to determine, based on the protocol message, whether the remote procedure call request contains a call request to a third-party service. The extraction module is configured to, if it contains a call requirement to a third-party service, use the custom governance processing component to extract tenant information from the protocol message and trigger the pre-stored original business processing component. The routing module is configured to use the original business processing component to route requests to the MCP server running instance corresponding to the current tenant, and the MCP server running instance obtains at least one third-party service information corresponding to the call request of the third-party service, and returns the at least one third-party service information to the custom governance processing component. The filtering module is configured to use the custom governance processing component to filter out target service information that matches the tenant information from the at least one third-party service information, and return the target service information to the transport proxy component; The return module is configured to encapsulate the target service information into a response to the remote procedure call request using the transport proxy component, and then return it to the MCP client.

7. A third-party service invocation system for multi-tenancy, characterized in that, include: The routing aggregation module, as the global traffic entry point of the gateway container, is used to route the remote procedure call request to the corresponding MCP server running instance of the current tenant based on the tenant identifier carried in the remote procedure call request of the MCP client. The transport proxy component is deployed inside the MCP server instance to implement the stateless transport service interface defined in the MCP SDK. It serves as the proxy entry point between the SDK and the underlying network layer. It is assembled as a gateway component during gateway container initialization and intercepts the SDK's attempt to bind to the original business processing component. It captures the reference of the original business processing component and registers the construction rules of the custom governance processing component internally. It has the ability to dynamically create the custom governance processing component. A custom governance processor is used to implement the standard business processing interface defined by the SDK. As a proxy object, the original business processing component is injected into it as a delegate object. After receiving a remote procedure call request, it determines whether the request contains a call requirement for a third-party service according to the protocol message. If it does, it extracts the tenant information and triggers the original business processing component to obtain at least one third-party service information. Then, it filters out the target service information that matches the tenant information from the at least one third-party service information.

8. An electronic device comprising a memory and a processor; wherein, The memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the steps of the method according to any one of claims 1-5.

9. A computer-readable storage medium having computer instructions stored thereon, wherein, When executed by a processor, the computer instructions implement the steps of the method according to any one of claims 1-5.

10. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1-5.

Images