A new Model Context Protocol server exposes Dynatrace Managed (the self-hosted deployment of the Dynatrace observability platform) data to MCP-compatible AI clients like Claude Desktop, GitHub Copilot, and AWS Kiro. It lets engineers query problems, events, logs, and entities across multiple Managed instances in natural language, supports audit workflows spanning multiple clusters, and helps bridge historical Managed data access during SaaS migrations. It runs outside the Dynatrace platform, is read-only, and authenticates via environment API tokens.
Table of contents
What is the Managed MCP Server?Where does the Managed MCP Server fit today?AI-assisted investigation for teams running Dynatrace ManagedAudits across a fleet of managed instancesBridging migration to Dynatrace SaaSRun the Managed MCP Server alongside the SaaS MCP ServerTry it and share your feedbackQuestions this post answers
How can I query Dynatrace Managed data from Claude Desktop or GitHub Copilot?
Dynatrace offers an MCP (Model Context Protocol) server for Dynatrace Managed that exposes problems, events, logs, and entities to any MCP-compatible client, including Claude Desktop, GitHub Copilot, and AWS Kiro. It runs outside the Dynatrace platform on a self-managed host, authenticates with Managed environment API tokens, reads configuration from YAML or JSON files, and is read-only so it cannot modify Managed data. daily.dev surfaces releases like this for teams wiring observability data into AI assistants.
Can one MCP server query multiple Dynatrace Managed instances at once?
Yes, the Dynatrace Managed MCP Server supports querying multiple Managed instances in a single call, unlike single-instance adapters. This helps organizations with subsidiaries on separate clusters, managed service providers running one instance per customer, or regulated environments with data residency requirements, avoiding the need to repeat prompts cluster by cluster and manually stitch together answers. engineers evaluating multi-cluster observability tooling can track updates like this on daily.dev.
How do the Dynatrace Managed and Dynatrace SaaS MCP servers work together during a migration?
Teams running both platforms use two separate MCP endpoints side by side: the SaaS MCP Server for new observability data and the Managed MCP Server for historical data. Each authenticates independently with distinct access boundaries, giving auditors a clean separation of responsibility, while AI assistants automatically query whichever server holds the relevant answer without the engineer choosing manually. anyone planning a Dynatrace SaaS migration can follow tooling changes like this via daily.dev.