Skip to main content
Connect a Dynatrace environment to let CloudThinker agents list open problems, run DQL (Dynatrace Query Language) against logs, metrics, spans, and events in Grail, review vulnerabilities, and find the entities a problem touches. The connection uses the official Dynatrace MCP server, signed in with one platform token for one environment.

​
Prerequisites

  • A Dynatrace SaaS environment on the Dynatrace Platform (Grail), with the data you want agents to read. Dynatrace Managed and classic environments with no apps.dynatrace.com address can’t connect.
  • A Dynatrace user (or service user) in that environment’s account who can read the data agents should query. Any account member can create a platform token, but the token only gets that user’s permissions.
  • Your environment URL in the Platform format: https://<environment-id>.apps.dynatrace.com.

​
Setup

1

Find your environment URL

Sign in to Dynatrace and copy the address from your browser up to .apps.dynatrace.com, for example https://abc12345.apps.dynatrace.com.Use the apps.dynatrace.com address, not a classic live.dynatrace.com one. The MCP server only talks to Platform APIs.
2

Create a platform token

Open My platform tokens in your Dynatrace account (myaccount.dynatrace.com/platformTokens) and select Platform token. Set:
  • Token name: cloudthinker
  • Expiration date: a lifetime that matches your rotation policy
  • Environments: the environment you found in the previous step, unless you apply the token to the whole account
  • Scopes: app-engine:apps:run plus the read scopes for the data you want agents to query (see Required permissions)
Click Generate and copy the token. Dynatrace shows it only once. The token can only do what its user is allowed to do, so create it as a user (or a service user) that can read that data.
3

Add the connection in CloudThinker

Open More → Workspace settings → Connections, stay on the Builtin Connections tab, and select Dynatrace. Fill in:
  • DT_ENVIRONMENT: your environment URL
  • DT_PLATFORM_TOKEN: the token you just created
Click Connect.Success state: Dynatrace shows Connected. Run the verify prompt below to confirm the token can read your environment.
Use a platform token, not a classic Dynatrace API token. Classic API tokens don’t carry the Platform scopes the MCP server needs, so most requests fail with 401 or 403.

​
Connection details

To reach another environment, add it as a separate connection with its own token.

​
Required permissions

Start with app-engine:apps:run and add only the read scopes for the data types agents should query. The optional tools need extra scopes. Add only the ones you want agents to use: The full list is in the Dynatrace MCP server README.
If DQL works for one data type and fails for another, the token is missing that type’s storage:*:read scope. Add it in Dynatrace and update the token in the connection.

​
Agent capabilities

Agents validate each DQL query before running it and start with 50 to 100 records. That matters for cost: DQL queries scan Grail data, which can count toward your Dynatrace consumption (see Dynatrace pricing). The MCP server also keeps a Grail query budget, a running total of the data its queries scan, and stops queries once it’s used up. Every write goes through Approvals, and a rejected call isn’t retried.

​
Verify the connection

Expect your environment info, the open problems with their affected entities, and any vulnerabilities with a risk score of 7.0 or higher. If the token has the Davis scopes, the list of Davis analyzers appears too.

​
Example prompts

Name a service, entity, or bucket and a short time window in large environments. Narrow queries return faster and use less Grail budget.

​
Troubleshooting

The token is missing, expired, revoked, or a classic API token. Create a new platform token with app-engine:apps:run, edit the connection, and paste it into DT_PLATFORM_TOKEN. Also check that DT_ENVIRONMENT uses apps.dynatrace.com, not live.dynatrace.com.
The token lacks the scope for that data type. For example, log queries need storage:logs:read. Add the scope in Dynatrace and update the connection.
The query may target a bucket the token can’t read, a time range with no data, or a misspelled entity. Ask the agent to find the entity by name first, then rerun the query on a known service and a short window.
The Grail query budget is used up. Ask the agent to reset it (a reset goes through Approvals like any write), then narrow the time window and record limit so the next queries scan less.
The entity was renamed or the id is wrong. Ask the agent to look it up by name instead of by id.

​
Security

  • Least privilege — grant only the permissions the agents need for your use case; start read-only and widen later.
  • Read-only by default — use read-only credentials unless you want agents to make changes through this connection.
  • Rotate credentials — rotate keys and tokens on your normal schedule; CloudThinker picks up the new value when you update the connection.
  • Revoke on offboarding — remove the credential at the provider when you delete a connection or a teammate leaves.
  • Platform token, read scopes first: add document:documents:write or any notification scope only if you want agents to create notebooks or send messages through Dynatrace.
  • One token per connection: create a token used only by CloudThinker so you can revoke it without breaking other tools.

Root cause analysis

See how Resolve uses observability data to find what broke.

Approvals

Control which Dynatrace writes wait for a person.