TL;DR: We open-sourced dtmgd, a kubectl-style CLI for Dynatrace Managed (self-hosted). Query problems, entities, events, logs, metrics, SLOs, and security vulnerabilities across one Managed environment, or across every Managed environment you have configured, in a single command. Single binary, no dependencies, read-only today. Install it with brew install dynatrace-oss/tap/dtmgd.
If you run Dynatrace Managed, you operate your own environments, and there is usually more than one: production, staging, development, often spread across several clusters. dtmgd gives you one terminal-native way to ask all of them the same question.
What is dtmgd?
dtmgd is a single Go binary for Linux, macOS, and Windows. Verb first, resource second. If you've used kubectl, you already know the grammar:
dtmgd get problems --status OPEN # what's broken right now
dtmgd get entities --selector 'type(SERVICE)' # topology, filtered
dtmgd describe problem <problem-id> # full detail as JSON
dtmgd query logs --query "timeout" --from now-1h # log search
dtmgd get slos --evaluate # SLO status, freshly evaluated
It was inspired by dtctl, the CLI for Dynatrace SaaS, and follows the same conventions, so if you already use dtctl there is nothing new to learn. The project is Apache 2.0 and lives on GitHub: dynatrace-oss/dtmgd.
One command, every environment
This is the part Managed users tend to care about most. Register as many environments as you like, then fan out across them:
dtmgd get problems --env "prod;stage" # two named environments
dtmgd get problems --env ALL_ENVIRONMENTS # every environment you configured
Requests run in parallel and results come back merged, keyed by context. The environments are fully independent: they can sit on one cluster or on separate clusters, in different locations, running different Dynatrace versions. The --env flag works with every get, describe, and query command.
CLI or MCP: same capabilities
dtmgd has full feature parity with the Dynatrace Managed MCP Server. Every MCP tool has a matching dtmgd command, with one exception: remote (HTTP) mode.
For AI-assisted work the CLI has a practical advantage: it is noticeably lighter on context. An MCP server's tool schemas occupy the model's context window for the whole session, while dtmgd ships an embedded Agent Skill that loads only when needed, and table output is far terser than the equivalent JSON tool results. One command installs the skill:
dtmgd skills install # auto-detects Claude Code, Copilot, Cursor, Kiro, and others
Running inside an AI agent, dtmgd detects it and wraps output in a structured envelope ({ok, result, context}), so failures are as parseable as successes. Choose the MCP server when you want a server, and the CLI when you want a binary.
A closed feedback loop for AI-assisted development
This gets more interesting combined with two community projects. ai-containers builds isolated development containers carrying JDK, Go, Node, Python, Rust, Maven, Gradle, and kubectl, plus dtmgd, dtctl, and their Agent Skills as installable components. The dev-workflows plugin adds implementation, documentation, testing, bug-fixing, dependency-upgrade, and vulnerability workflows.
Put together, an AI agent working inside one container can read the open problems from your production environment, fix the code, test it, ship to staging, then compare staging against production, without ever leaving the container. And because both CLIs are available side by side, that same container reaches Dynatrace Managed and Dynatrace SaaS environments, which is a useful place to stand during a Managed-to-SaaS migration.
Get started
brew install dynatrace-oss/tap/dtmgd
dtmgd config set-context prod \
--host https://managed.company.com \
--env-id <environment-id> \
--token-ref prod-token
dtmgd config set-credentials prod-token --token <api-token>
dtmgd get environments # verify connectivity and cluster version
dtmgd get problems --status OPEN
Tokens are stored in your OS keyring wherever one is available. The dtmgd README lists the API token scopes you need.
What's next
dtmgd is read-only today. That was a scoping decision, not a design principle. Write operations are on the roadmap: pushing events, closing problems, and writing settings.
We'd love your feedback
This is an early release, v0.0.28 at the time of writing, and it is community-supported. If you run Dynatrace Managed, point it at your environments and tell us what is missing by opening an issue on GitHub. And if it saves you a trip to the UI, star the repo so other Managed users can find it.
1 Comment
