As a piece of design this one still reads well — DQL gets verified before it is executed, every Grail query counts against a byte budget you set, and the scope list tells you exactly which capability each permission buys. But no further updates are coming, and Dynatrace directs local editor use to Dynatrace-for-AI with `dtctl` and remote use to its own hosted MCP server, so this is worth reading to see how the observability surfaces map onto tools rather than as something to standardise a team on.
The local Dynatrace MCP server: a Node process your MCP client spawns that brings problems, vulnerabilities, exceptions, Kubernetes events and Grail queries into the editor. Its README now opens with a deprecation notice — version 2.1.2 was the final release, no further updates will be made — and points at two actively maintained paths instead: Dynatrace-for-AI with `dtctl` for local development, and the Dynatrace Remote MCP Server for agent-to-agent and remote use, which needs no local setup. The repository also notes the project was never officially supported by Dynatrace; support ran through GitHub Issues.
- Problem and risk surfaces: `list_problems`, `list_vulnerabilities`, `list_exceptions`, `get_kubernetes_events`
- Grail querying: `execute_dql` to run DQL, `verify_dql` to check syntax before you spend on a scan, and `reset_grail_budget` to clear the session's byte counter
- DQL in both directions: `generate_dql_from_natural_language` writes the query, `explain_dql_in_natural_language` reads one back to you in prose
- Entity and environment lookup: `find_entity_by_name`, `get_environment_info`
- Davis: `chat_with_davis_copilot` for questions, `list_davis_analyzers` and `execute_davis_analyzer` for anomaly detection and forecasting
- Getting results out: `send_slack_message`, `send_email`, `send_event`, `create_dynatrace_notebook`, plus `list_documents`, `read_document` and `create_document`
- A session budget for Grail: `DT_GRAIL_QUERY_BUDGET_GB` (default 1000) tracks bytes scanned, warns at 80% of the limit and resets when the server restarts
Node.js v24 or newer, and `DT_ENVIRONMENT` set to your Dynatrace Platform URL — the apps URL, not a classic one. With only that set, the server opens a browser once for the Authorization Code Flow and keeps the token in the OS keychain; in a headless or container environment set `DT_MCP_TOKEN_STORAGE=file` to store it under `~/.config/dynatrace-mcp/` instead. `DT_PLATFORM_TOKEN`, or `OAUTH_CLIENT_ID` with `OAUTH_CLIENT_SECRET`, cover service users and backend-to-backend cases. Scopes are per feature and listed one by one in the README — `app-engine:apps:run` for almost everything, the `storage:*:read` family for what `execute_dql` may read, `email:emails:send` for `send_email`. Running it as an HTTP service additionally requires `MCP_BEARER_TOKEN`; the server refuses to start without it and answers unauthenticated requests with `401`. Telemetry is on by default and is turned off with `DT_MCP_DISABLE_TELEMETRY=true`. Package `@dynatrace-oss/dynatrace-mcp-server` (2.1.2) on npm over stdio. MIT licensed.
One command plus a key — npx -y @dynatrace-oss/dynatrace-mcp-server, then supply credentials