dynatrace-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DT_PROXY | No | Proxy URL for Dynatrace calls, e.g. http://proxy.corp:3128. Standard HTTPS_PROXY / NO_PROXY / SSL_CERT_FILE are honored too. | |
| NO_PROXY | No | Standard no-proxy environment variable honored for Dynatrace calls. | |
| DT_REDACT | No | Mask secrets in tool output (passwords, tokens, keys, JWTs, credentials in URLs). The configured tokens are masked even when false. | true |
| DT_TIMEOUT | No | Request timeout in seconds. | 30 |
| DT_BASE_URL | Yes | Managed: https://<host>/e/<env-id>. SaaS: https://<env>.live.dynatrace.com. A trailing /api/v2 or a pasted UI link is trimmed. | |
| HTTPS_PROXY | No | Standard proxy environment variable honored for Dynatrace calls in addition to DT_PROXY. | |
| DT_API_TOKEN | Yes | Dynatrace API token, bare value (no 'Api-Token ' prefix). Read only from the environment; never logged or returned. | |
| DT_CA_BUNDLE | No | PEM file with your company's root/intermediate CAs (Managed with internal certificates). | |
| DT_LOG_LEVEL | No | Server log level; logs go to stderr (Cursor: Output -> MCP Logs). | WARNING |
| DT_ALLOW_HTTP | No | Allow a plain http:// base URL (refused by default because the token would travel unencrypted). | false |
| SSL_CERT_FILE | No | Standard SSL certificate file environment variable honored for Dynatrace calls. | |
| DT_MAX_RETRIES | No | Retries for GET on 429/502/503/504 (honors Retry-After, max 10 s). | 2 |
| DT_ENABLE_WRITE | No | Register add_problem_comment and close_problem write tools. | false |
| DT_INSECURE_TLS | No | Skip TLS verification. Last resort; prefer DT_CA_BUNDLE. | false |
| DT_PLATFORM_URL | No | Optional Grail DQL on SaaS: https://<env>.apps.dynatrace.com (must be set together with DT_PLATFORM_TOKEN to enable DQL tools). | |
| DT_DISABLE_TOOLS | No | Comma-separated tool names to hide (e.g. to stay under Cursor's tool limit). | |
| DT_PLATFORM_TOKEN | No | Optional platform token with storage:logs:read, storage:spans:read, storage:buckets:read (plus other storage:*:read scopes you query) to enable Grail DQL tools. | |
| DT_MAX_OUTPUT_CHARS | No | Output budget per tool call; the largest lists are trimmed and _truncated says what was dropped. | 60000 |
| DT_MAX_LOG_LINE_CHARS | No | Max characters kept per log line. | 2000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_connectionA | Show the active configuration (no secrets) and probe which token scopes work. |
| search_logsB | Search log records (GET /api/v2/logs/search). Needs scope logs.read. |
| aggregate_logsA | Count log records over time and by attribute (GET /api/v2/logs/aggregate). Needs logs.read. |
| get_trace_logsB | Log lines for one distributed trace / PurePath. Classic API v2 has no trace endpoint. |
| list_problemsB | List problems (GET /api/v2/problems). Needs problems.read. |
| get_problemB | Problem details: status, root-cause entity, root-cause evidence, impacts, recent comments. |
| get_problem_evidenceC | Evidence Dynatrace collected for a problem (events, metric change points, transactions). |
| get_problem_impactC | Root cause, affected and impacted entities, and impact analysis (users, services, apps). |
| list_problem_commentsC | Comments on a problem (GET /api/v2/problems/{id}/comments). |
| investigate_problemA | One-shot RCA: correlates the problem's root-cause entity and evidence, change events (deployments, config, restarts) before the start, error logs in the problem window grouped by signature, and key metrics before vs during. Returns findings, a Markdown summary and next steps. |
| list_eventsB | List events (deployments, config changes, restarts, anomalies). Needs events.read. |
| get_eventB | One event with all properties (GET /api/v2/events/{id}). |
| search_entitiesB | Search monitored entities by selector (GET /api/v2/entities). Needs entities.read. |
| find_entity_by_nameB | Find entities by display name (exact first, then contains). |
| get_entityC | Entity details: properties, tags, management zones and relationships (calls, runsOn, ...). |
| query_metricsA | Query metric data (GET /api/v2/metrics/query) with per-series min/max/avg/last. Needs metrics.read. |
| list_metricsB | Find metric keys and their units and dimensions (GET /api/v2/metrics). |
| get_metric_descriptorB | Full descriptor of one metric: unit, dimensions, aggregations, transformations. |
| list_security_problemsB | List vulnerabilities (GET /api/v2/securityProblems). Needs securityProblems.read. |
| get_security_problemB | One vulnerability with risk assessment, affected entities and remediation. |
| list_slosB | List SLOs with status and error budget (GET /api/v2/slo). Needs slo.read. |
| get_sloC | One SLO with evaluated percentage, error budget and burn rate. |
| debug_serviceA | Debug a service: failure rate, request volume and response time (baseline vs recent), failure logs of its process groups grouped by signature, recent deployments/config changes, problems in the window, and callers/callees. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Most tools target a clearly distinct resource+action (logs vs events vs metrics vs entities vs SLOs vs security problems), and pairs like list_metrics/get_metric_descriptor and search_entities/find_entity_by_name are separable from their descriptions. The main fuzziness is within the problem cluster: get_problem already claims to return root-cause evidence and impacts, which overlaps with get_problem_evidence and get_problem_impact, and investigate_problem/debug_service are both RCA-style aggregators that an agent could pick between imprecisely.
Every tool is snake_case verb_noun (list_problems, get_problem_impact, query_metrics, check_connection), including the more elaborate ones like find_entity_by_name and investigate_problem. No camelCase or bare-noun outliers, so the pattern is fully predictable.
23 tools is on the heavy side of the 3-15 sweet spot, but Dynatrace is a broad platform (logs, events, problems, metrics, entities, SLOs, security) and each resource gets a small, coherent list/get pair plus a few aggregate helpers, so nothing looks like pure filler. It is slightly over-scoped rather than bloated.
Read-side coverage is strong and consistent: list/get pairs for problems, events, entities, SLOs, security problems, metrics, plus log search/aggregate and RCA helpers like investigate_problem and debug_service. Gaps are minor but real: there is list_problem_comments with no create-comment/mute/close operation, and no trace listing or trace metadata lookup beyond get_trace_logs, which blocks a few lifecycle workflows.