> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Dynatrace AI Connector
> Connect Rootly AI to Dynatrace's hosted MCP server with an environment name and Platform token for read-only incident investigation.
## Overview
The **Dynatrace** AI connector lets Rootly AI query your Dynatrace environment during incident investigations. Rootly AI can run DQL, inspect problems and vulnerabilities, find entities, review Kubernetes events, and use Dynatrace Intelligence analysis tools without leaving the investigation.
Rootly connects to Dynatrace's hosted MCP server for your environment. Setup requires your Dynatrace environment name and a Platform token; Dynatrace does not support the public OAuth and Dynamic Client Registration flow used by one-click AI connectors.
Rootly AI exposes a curated read-only Dynatrace tool set. Tools that create notebooks or events, send email or Slack messages, or perform other write operations are filtered out.
***
## Before You Start
The identifier before `.apps.dynatrace.com` in your Dynatrace URL. For `https://abc12345.apps.dynatrace.com`, enter `abc12345`.
A Platform token for a user with access to the Dynatrace data Rootly AI should query. The user and token both need `mcp-gateway:servers:invoke` and `mcp-gateway:servers:read`, plus the permissions required by each Dynatrace MCP tool you want Rootly AI to use.
Connecting a data source requires permission to manage AI connectors on your Rootly account. If **Connect** is unavailable, ask a Rootly admin.
Treat the Platform token as a secret. Rootly stores it encrypted and never displays it again after setup. Create a dedicated token with only the Dynatrace permissions needed for investigation.
### Recommended Platform token scopes
To enable every Dynatrace tool that Rootly currently allows, grant the full permission set that Dynatrace recommends for access to all MCP tools:
| Capability | Scopes |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| MCP gateway | `mcp-gateway:servers:invoke`, `mcp-gateway:servers:read` |
| Dynatrace Intelligence | `ai:operator:execute`, `davis-copilot:conversations:execute`, `davis-copilot:nl2dql:execute`, `davis-copilot:document-search:execute`, `davis-copilot:dql2nl:execute` |
| Davis analyzers | `davis:analyzers:read`, `davis:analyzers:execute` |
| Documents | `document:documents:read` |
| Grail data | `storage:bizevents:read`, `storage:buckets:read`, `storage:system:read`, `storage:spans:read`, `storage:entities:read`, `storage:user.events:read`, `storage:user.sessions:read`, `storage:user.replays:read`, `storage:smartscape:read`, `storage:events:read`, `storage:metrics:read`, `storage:logs:read`, `storage:files:read`, `storage:security.events:read` |
Both the Platform token and its Dynatrace user must have these permissions. Their effective access is the intersection of the two.
Dynatrace publishes the complete scope set for all MCP tools rather than a guaranteed minimum for each individual tool. If you reduce the token further, test every Rootly capability you expect to use. DQL can query different Grail data types, so the scopes needed by `execute-dql` depend on the query.
The following mapping explains how Rootly's curated tools use those capability groups:
| Rootly tool | Relevant capability or data scopes |
| ----------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `ask-dynatrace-docs` | `ai:operator:execute`, `davis-copilot:conversations:execute`, and `davis-copilot:document-search:execute` |
| `create-dql` | `ai:operator:execute` and `davis-copilot:nl2dql:execute` |
| `explain-dql` | `ai:operator:execute` and `davis-copilot:dql2nl:execute` |
| `execute-dql` | The `storage:*:read` scopes for every Grail data type addressed by the query |
| `find-documents`, `find-troubleshooting-guides` | `document:documents:read` and `davis-copilot:document-search:execute` |
| `get-entity-id`, `get-entity-name` | `storage:entities:read`; related lookups can also use `storage:smartscape:read` and `storage:system:read` |
| `query-problems`, `get-problem-by-id`, `get-events-for-kubernetes-cluster` | `storage:events:read`, `storage:entities:read`, `storage:smartscape:read`, and `storage:system:read` |
| `get-dynatrace-compliance-findings`, `get-dynatrace-vulnerabilities`, `get-security-event-details`, `get-security-events-summary` | `storage:security.events:read` and `storage:entities:read` |
| `log-pattern-extractor` | `davis:analyzers:read`, `davis:analyzers:execute`, and `storage:logs:read` |
| `adaptive-anomaly-detector`, `seasonal-baseline-anomaly-detector`, `static-threshold-analyzer`, `timeseries-forecast`, `timeseries-novelty-detection` | `davis:analyzers:read`, `davis:analyzers:execute`, `storage:metrics:read`, and any additional storage scope needed by the input DQL |
See [Dynatrace MCP server permissions](https://docs.dynatrace.com/docs/dynatrace-intelligence/dynatrace-mcp#get-mcp-related-permissions) for Dynatrace's current source-of-truth permission list.
***
## Connecting
In Dynatrace, create a [Platform token](https://docs.dynatrace.com/docs/manage/identity-access-management/access-tokens-and-oauth-clients/platform-tokens#my-platform-tokens) for the user and permissions Rootly AI should inherit.
For the complete Rootly tool set, grant all scopes in [Recommended Platform token scopes](#recommended-platform-token-scopes). You can use a narrower token, but unavailable scopes disable the corresponding tools or data types.
Choose an expiration date that follows your organization's token policy, and plan to replace the token through the Dynatrace connector before it expires.
In Rootly, go to **AI & Agents → Connectors** and click **Connect** on the **Dynatrace** card.
Enter your Dynatrace environment name without the protocol or `.apps.dynatrace.com` suffix. Paste the Platform token, then click **Connect Dynatrace**.
Rootly builds the fixed Dynatrace MCP endpoint for your environment and probes it before saving the connection. An invalid environment name or token leaves any existing working connection unchanged.
After the probe succeeds, the Dynatrace card shows **Connected**. Rootly AI can now query the allowed Dynatrace tools during investigations.
***
## What Rootly AI Can Read
The curated Dynatrace MCP tool set covers:
* **DQL** — generate, execute, and explain Dynatrace Query Language queries.
* **Problems and security** — query problems, compliance findings, vulnerabilities, and security-event details and summaries.
* **Entities** — resolve entity IDs and names.
* **Kubernetes** — inspect Kubernetes events available in Dynatrace.
* **Dynatrace Intelligence** — extract log patterns and run anomaly detection, static and seasonal threshold analysis, forecasting, and novelty detection.
* **Documentation** — search Dynatrace documentation, troubleshooting guides, and documents available to the token.
Rootly AI can only retrieve data that both the token and its Dynatrace user can access. Missing permissions usually appear as an authorization error or an empty result for the affected signal.
When AI service-context ingestion is enabled for your Rootly account, Rootly also runs read-only DQL aggregations over recent spans and stores the resulting service identities and dependency relationships. Rootly does not persist the underlying spans or raw DQL result set as a copy of your Dynatrace telemetry.
***
## During an Incident
*"Checkout errors began at 14:12. Dynatrace shows a new spike in `payment-api` failures, and the affected Kubernetes workload restarted three times in the same window."*
Rootly AI can correlate Dynatrace problems, logs, spans, metrics, entities, and Kubernetes events with the Rootly incident timeline. It uses those results to identify affected services, likely causes, and the scope of impact.
***
## Best Practices
* **Use a dedicated Platform token.** A separate token makes rotation and revocation independent from personal MCP clients.
* **Grant only required permissions.** Start with the MCP gateway permissions and the read scopes for the signals your responders use.
* **Use a stable service user.** The token inherits its user's permissions. Removing the user or its access can break future queries.
* **Rotate through the Dynatrace card.** Submit the replacement token from the connector setup flow. Rootly keeps the existing connection if the new token fails its probe.
* **Test a representative query.** After connecting, ask Rootly AI to inspect a known Dynatrace problem or a recent log window.
***
## Troubleshooting
Enter only the environment identifier. If your Dynatrace URL is `https://abc12345.apps.dynatrace.com`, enter `abc12345`. Don't paste the full URL or another Dynatrace hostname.
Confirm that the token is active and belongs to the same Dynatrace environment. Verify that both the token and its user have `mcp-gateway:servers:invoke` and `mcp-gateway:servers:read`.
Check the signal-specific permissions on both the Platform token and its user. For example, log queries require `storage:logs:read`. Dynatrace applies the intersection of token and user permissions.
Open the Dynatrace card and connect again with the replacement token. Rootly validates the new token before replacing the saved connection.
***
## Frequently Asked Questions
Dynatrace's hosted MCP server does not support public OAuth clients or Dynamic Client Registration. Rootly uses the bearer-token method recommended by Dynatrace for this connection type.
No. Rootly applies an allowlist of read and analysis tools. The `create-dql` tool generates query text; it does not create Dynatrace data. Write-capable tools, including event creation and outbound notifications, are excluded even when the Platform token has broader permissions.
One Dynatrace AI connector can be active per Rootly team. Connect the environment that contains the observability data used by that team.
No. The alert source sends Dynatrace alerts into Rootly. The AI connector lets Rootly AI read Dynatrace context during an investigation. Configure each surface separately.
***
## Related Pages
Compare all Rootly AI connectors and setup flows.
Configure Dynatrace as an alert source for Rootly.
Review connector data handling, retention, and model-training controls.