The Dynatrace Cursor plugin: investigate production without leaving your editor

The scenario is familiar: an alert fires on a service you have just changed, the code is open in your editor, but the answers are somewhere else. You have to open Dynatrace, find the problem, filter the logs, compare with the previous deployment, then come back to the code with a few screenshots in your head. Every round trip costs focus, and that is often where the thread of an investigation gets lost. The Dynatrace Cursor plugin aims to remove precisely those round trips.

Coding assistants can already read a repository and propose a fix. What they lack is ground truth: what is actually happening in production. The Model Context Protocol (MCP) fills part of that gap, and Dynatrace now offers a verified plugin in the Cursor Marketplace that goes one step further: a single installation delivers both the connection to your environment and the know-how needed to query it well.

This article explains what the plugin contains, what it changes compared with a plain MCP connection, and how to set it up without turning every developer workstation into an uncontrolled entry point to your observability data.

Dynatrace Cursor plugin: why MCP alone is not enough

Giving an agent MCP access to Grail opens the door to the data. But an agent that does not know the Dynatrace data model tends to write DQL queries that look plausible and are wrong: a field that does not exist, a badly chained command, an aggregation that mixes incompatible series. The result is either an error or, more awkwardly, an empty response interpreted as « all is well ».

So the plugin bundles two things:

• an MCP server that handles the connection between Cursor and your SaaS environment;
• around thirty skills (the same ones published under the name « Dynatrace for AI ») that describe how the platform is organised: DQL syntax and patterns with dt-dql-essentials, creating Notebooks and Dashboards with dt-app-notebooks and dt-app-dashboards, configuring anomaly detectors with dt-alerting, and so on.

An important point for those worried about flooding the context window: these skills are only loaded when a task calls for them. Installing thirty of them does not mean injecting thirty documents into every conversation.

Analysis grounded in causality

When the agent traces the cause of a problem, it relies on Dynatrace causal analysis and the Smartscape topology, not on a correlation it reconstructed itself. That is a fundamental difference from an agent browsing raw logs: the relationship between the failing service, its database and the restarting pod is already established on the platform side. The agent reports and explains it; it does not have to guess it.

What you can reasonably ask it

Cursor becomes one more surface for the conversational analysis already available in Dynatrace Assist. Three families of questions are particularly well suited to working from the editor:

• incidents: root cause of an identified problem, log patterns on a Kubernetes workload, dependencies between services, real user impact of a shipped regression;
• security: whether a specific CVE affects the workloads actually running in production, not just those listed in a dependency manifest;
• optimisation: oversized hosts, slow database calls at p99, headroom available before scaling.

Conversely, the plugin is designed for reading and analysis. Write operations (creating a Dashboard, triggering a Workflow, applying a configuration with dtctl apply) go through dtctl, the open-source Dynatrace CLI, available in the dynatrace-oss/dtctl repository and usable from the terminal or the Cursor CLI, alongside the MCP server. This separation is healthy: it forces you to decide explicitly when an agent is allowed to change something.

In practice

Step 1 — Prepare a dedicated platform token

The connection relies on a platform token, created in your environment from Access Tokens > Generate new token. The token needs mcp-gateway:servers:invoke and mcp-gateway:servers:read, plus the permissions for the data queried (for example storage:logs:read for logs), and it never acts beyond the rights of the user who created it. Do not reuse an existing admin token: create one per use (ideally per developer or per team), with only the read permissions needed for the data the agent must access, and an expiry date (see also securing an MCP server). The MCP server also accepts an OAuth client (Authorization Code flow) with clients that support it; for the plugin, the token remains the main control point.

Step 2 — Install the plugin

Before starting Cursor, set two environment variables: DT_ENVIRONMENT (https://{environment-id}.apps.dynatrace.com) and DT_PLATFORM_TOKEN (the token). In Cursor, open Customize, search for « Dynatrace », select Install and choose project or user scope (the listing can also be viewed on cursor.com/marketplace). The listing shows what is delivered: an MCP server and the Dynatrace skills.

For an organisation, Teams and Enterprise administrators can publish the plugin to a team marketplace. This is the preferred route: the platform team chooses the version distributed and how developers connect, instead of letting everyone cobble together their own configuration.

Step 3 — Run a first investigation

Imagine an inventory-api service returning 5xx errors since the last deployment. Ask precise, step-by-step questions rather than a vague request:

Is there an open Dynatrace problem on inventory-api in the last 2 hours?
What is the root cause, and which downstream services are affected?
Show the error log patterns for the inventory-api workload over the last hour.
Propose a fix in the open file, based on these errors.

Each answer comes from your real environment, at the moment of the question: it is neither a documentation summary nor a cached result.

Step 4 — Review the generated queries

Get into the habit of asking the agent for the DQL query it ran, then replaying it in a Notebook. This lets you check the scope (cluster, time range, filters) and gives you a reusable query:

fetch logs, from: now()-1h
| filter k8s.workload.name == "inventory-api"
| filter loglevel == "ERROR"
| summarize erreurs = count(), by: { k8s.pod.name }
| sort erreurs desc

If the query looks right, keep it in a team Notebook: it is the memory of the investigation, which chat history does not replace.

Step 5 — Take action with dtctl

Once the cause is understood, actions on the platform (a follow-up Dashboard, a remediation Workflow) are done with dtctl. Keep a separate token for these operations, with limited write permissions, and check the repository documentation for the commands available in your version.

Best practices

• One token per person or per team, read-only for the MCP server, with an expiry date; never commit a token to a repository.
• Distribute the plugin through a team marketplace to keep control over versions.
• Always ask for the underlying DQL query before acting on an important conclusion.
• Separate reading (MCP) and writing (dtctl): an action on the platform must remain an explicit human decision.
• On budget, queries generated by agents run on Grail like any other: watch their volume, and check in your contract how queries are billed.

Frequently asked questions

Can the plugin change my Dynatrace environment?

No, it is designed for reading and analysis. Write operations, such as creating a Dashboard or triggering a Workflow, go through the dtctl CLI, with a separate token that has limited write permissions.

Are thirty or so skills too much for the context window?

No: skills are only loaded when a task calls for them. Installing all of them does not mean injecting thirty documents into every conversation.

How do you roll the plugin out across an organisation?

Cursor Teams and Enterprise administrators can publish it to a team marketplace, which lets the platform team choose the version distributed. Each person or team then uses their own token, read-only and with an expiry date.

Conclusion

The value of the plugin is not about having « Dynatrace in the editor », but about combining direct access to the data with knowledge of how to query it. The agent stops guessing where to look, and the developer can link a production error to the relevant line of code without switching tools. What remains is governing its use: dedicated tokens, centralised distribution, query review. With these guardrails, Cursor becomes a credible entry point for day-to-day diagnosis, alongside Dynatrace Assist and Notebooks.

Further reading: Investigate production issues from Cursor with the Dynatrace plugin (Dynatrace blog).

span.observer is an independent community blog, not affiliated with Dynatrace LLC. Dynatrace is a trademark of Dynatrace LLC. SaaS features evolve quickly: check their availability in your environment and in the official documentation.

Originally published on span.observer. French version: https://span.observer/fr/plugin-dynatrace-cursor-mcp/.