Dynatrace Managed data is now queryable from MCP clients

On 21 August, SitePoint reported that Dynatrace Managed data can now be queried from Claude, AWS Kiro, GitHub Copilot and any other MCP-compatible client (Query Dynatrace Managed data directly in Claude, AWS Kiro, GitHub Copilot, and other MCP-compatible clients). The word that makes the announcement interesting is Managed: the self-hosted edition of Dynatrace, the one many companies keep in their own data centre for compliance or data sovereignty reasons.

Connectors like this usually land first on the SaaS version and take months to reach on premise installations, if they ever do. MCP support showing up in the self-managed variant says a lot about who is asking for the integration: not the team that tries things out on Friday afternoons, but operations in regulated environments.

What an observability MCP server solves

Observability has an old problem: the data is there, but asking is expensive. You need to know the platform query language, know which dashboard each metric lives in and translate what you see into what happens in the code. An MCP server in front of the platform turns that into a tool call: the agent asks for the traces of a service in a specific time window and gets structured data it can cross with the repository it already has open.

The obvious use case is triage. An error spikes in production, the agent queries metrics and traces, locates the affected service, looks at the recent commits touching that service and proposes a hypothesis. None of that is magic: it saves the fifteen minutes of tab hopping that separate the alert from the first useful clue.

Why the self-hosted detail matters

Keeping Dynatrace in house usually answers a specific need: telemetry cannot leave the perimeter. It is worth being precise here, because a local MCP server does not by itself guarantee that condition holds. If the client is a cloud hosted model, the data the server returns travels to the model inside the tool response. The server is inside, the conversation is not.

That does not invalidate the approach, but it forces an explicit decision: which fields get returned, what is masked before leaving and which queries are limited to aggregates rather than raw events. In sectors with personal data in the logs, that decision is the serious part of the project.

Who this is useful for

SRE and platform teams already on Dynatrace who want natural language querying without training the whole organisation in the platform query language.
Development teams with Claude Code or Copilot in their daily flow, who gain production context without leaving the editor.
* Organisations with data residency requirements that were until now left out of these integrations.

What we would watch

The first point is credential scope: a read only token, scoped to the relevant environment, and no reusing the admin one. The second is cost. Telemetry responses are huge, and a careless agent can push thousands of tokens of time series into the context to answer a two line question. Filtering and aggregating on the server side, before the data reaches the model, is what separates a usable connector from an expensive one.

We find this one of the more sensible MCP integrations of the year, precisely because it does not pretend the agent will fix the incident: it hands over the data to shorten the diagnosis. That is where these tools deliver today, and it is worth not asking them for more.