LabscoMCP early access ↗
dynatrace-ossMCP SERVER

Dynatrace

Reach Dynatrace problems, vulnerabilities and Grail queries from your editor — with the caveat that 2.1.2 was the final release and Dynatrace names two replacements.

by dynatrace-oss ↗Observability, Monitoring & Incident ResponseCommunity

No longer maintained. The GitHub repository for this server is archived — no fixes or security updates are expected.

View project ↗

LABSCO SUMMARY

Final release 2.1.2, with two named successors.

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.

What it is

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.

What you get

  • 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

Requirements

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.

Setup effort

One command plus credentials — npx -y @dynatrace-oss/dynatrace-mcp-server, then supply credentials

See installation options