Multi‑Tenant Support for Dynatrace MCP Server

Enabling Multi-Tenancy in Dynatrace MCP Server

The Dynatrace Managed Control Plane (MCP) Server, in its current state, is designed to operate with a single Dynatrace tenant per instance. This limitation poses significant challenges for large organizations that utilize multiple Dynatrace SaaS tenants. Maintaining separate MCP instances for each tenant introduces operational overhead, increases complexity, and complicates overall maintenance. This article explores the need for multi-tenant support in the MCP Server and potential solutions.

The Problem: Operational Overhead and Scalability

Consider a large financial enterprise managing 15 or more Dynatrace SaaS tenants. Each tenant likely corresponds to different business units, application portfolios, or development environments. Deploying and maintaining a dedicated MCP Server instance for each of these tenants results in a fragmented operational landscape. The administrative burden increases significantly, requiring duplicated efforts for configuration, monitoring, and updates across numerous servers. This approach is not scalable and becomes increasingly difficult to manage as the number of tenants grows.

Root Cause: Single-Tenant Architecture

The root cause of this limitation lies in the MCP Server's original design, which assumes a one-to-one relationship between the server instance and a Dynatrace tenant. This design simplifies initial setup and configuration but lacks the flexibility required for enterprise-scale deployments with multiple tenants. The server's internal components, such as authentication mechanisms and data access layers, are inherently tied to a single tenant configuration.

Proposed Solution: Native Multi-Tenant Support

The ideal solution involves introducing native multi-tenant support within a single MCP Server instance. This would enable the server to manage and interact with multiple Dynatrace tenants simultaneously. The key components of this solution include:

1. Tenant Configuration: A mechanism to configure and manage multiple Dynatrace tenants within the MCP Server. This could involve storing tenant-specific credentials, API endpoints, and other relevant configuration parameters.
2. Tenant Context: A way to associate each request or operation with a specific Dynatrace tenant. This ensures that the server interacts with the correct tenant's data and resources.
3. Authentication and Authorization: Robust authentication and authorization mechanisms to ensure that users and applications can only access the data and resources of the tenants they are authorized to access.

One approach to implementing this involves:

1. Introducing a new tool, for example, list_dt_environments, to list all configured Dynatrace environments.
2. Providing a parameter, such as dt_environments: string[] | undefined, for every tool. This parameter would specify the Dynatrace environments to query. If the parameter is undefined, the tool could default to querying the first environment in the list.
3. Extending the response for every tool to include information about the environment used.

Here's an example of how this might look in practice:

{
  "tool": "get_problems",
  "dt_environments": ["abc", "xyz"],
  "parameters": {
    "severity": "ERROR"
  }
}

This request would query the "abc" and "xyz" Dynatrace environments for problems with a severity of "ERROR". The response would then include information about which environment each problem originated from.

Alternative Solutions and Their Drawbacks

While running multiple MCP Server instances is a functional workaround, it is not a scalable solution. Custom modifications to the MCP Server code can provide multi-tenant support, but maintaining a fork long-term is not sustainable due to the effort required to keep up with upstream changes.

Practical Tips and Considerations

• OAuth Client Configuration: Configure multiple Dynatrace environments using a single OAuth client at the account level. This simplifies authentication and authorization.
• Dynamic Environment Switching: Implement a mechanism to dynamically switch the active Dynatrace environment based on user requests. This can be achieved through tools like switch_environment.
• Performance Optimization: Consider the performance implications of querying multiple Dynatrace environments in parallel. Implement caching and other optimization techniques to minimize latency.
• Security Considerations: Carefully review and implement security measures to protect sensitive data and prevent unauthorized access to Dynatrace tenants.

By implementing native multi-tenant support, the Dynatrace MCP Server can significantly reduce operational overhead, improve scalability, and align with enterprise-scale deployment models. This enhancement would greatly benefit large organizations that rely on multiple Dynatrace SaaS tenants.