Dynatrace MCP Server for Atlassian Rovo: Investigate production problems without leaving Jira or JSM

A developer triaging a bug in Jira, or an on-call engineer responding to an alert in Jira Service Management (JSM), can ask their Rovo agent to investigate production issues in Dynatrace using plain language, without leaving Jira or JSM. The Rovo agent answers any relevant questions, calls the appropriate Dynatrace tools, and posts the results back to the Jira workspace. Admins can now complete setup in minutes. Every call runs with the permissions of the requesting user, every action is logged, and data access and cost remain under central control.

Move from "ask the platform team" to "ask the agent"

If your organization uses Dynatrace, much of your production knowledge may reside with the Dynatrace experts on your organization's platform or SRE team. Everyone else (developers triaging Jira bugs, on-call responders running down JSM alerts, or support engineers handling escalations) either learns enough Dynatrace to investigate production issues on their own or pings the platform team and waits for a response.

The Dynatrace Model Context Protocol Server for Rovo moves this valuable production expertise into the Rovo agent, where it's accessible to all Rovo users. The Rovo agent holds the Atlassian context (the bug, the alert, the service it relates to) and calls Dynatrace for the production context (problems, topology, root cause). Meanwhile, the developer asking the question gets a usable answer directly in the tool where they're already working.

How does an on-call engineer use Rovo to triage a JSM alert?

A JSM alert is triggered when a service degradation is detected. The on-call engineer opens the alert's response panel and asks the Rovo Ops Agent, Atlassian's built-in AI agent for JSM incident response, to investigate.

Rovo Ops calls the Dynatrace MCP Server, retrieves the open problem, the root cause, and the related signals, and returns a single answer: what went wrong, what's related, and what to do next. The on-call engineer either acts on this problem context directly or escalates the alert, with the full analysis already attached.

How does a developer triage a Jira bug with Rovo and Dynatrace?

Let's say Jira provides details of a bug in a service that a developer doesn't own. The developer asks the Rovo agent a question in the issue's chat panel: "What's going on with this service right now?" Rovo returns the open Dynatrace problem, the elevated error rate, and the dependency that's causing the issue.

Rovo's answer posts as a comment on the bug in Rovo, so the next person who opens the ticket sees the investigation is already done. From there, the bug typically closes as a duplicate of the active incident or routes to the team that owns the failing deployment, in minutes rather than hours.

How to roll out the Dynatrace MCP Server in Atlassian Rovo

MCP Server setup is a configuration task, not a project. The Dynatrace MCP Server is pre-approved by Atlassian as an external MCP integration and is included with Dynatrace SaaS at no extra cost. In a few clicks, an admin connects Dynatrace using the Rovo admin UI, authenticates against the Dynatrace tenant, and selects which tools to expose. Once connected, the integration is available across Jira, Jira Service Management, and Confluence.

The Dynatrace MCP Server tool set is ready for immediate use, providing data retrieval through Grail, topology and entity context, root cause analysis, active security findings, time-series forecasting, and change-point analysis.

Security, governance, and cost stay under administrator control

Admins keep control over security, governance, audit, and cost on both the Atlassian and Dynatrace sides.

• Per-user enforcement, end-to-end. Every Dynatrace call runs as the requesting user via OAuth 2.1, with authorization based on the user's Dynatrace permissions. On the Atlassian side, Rovo and Rovo Ops only see the Jira and JSM data that the user is already entitled to see.
• Per-tool selection. From a checklist in the admin panel, administrators choose which Dynatrace tools the Rovo agents in the organization can call. (New tools released later must wait for admin approval before they become available.)
• Audit trail on both sides. Every Rovo invocation and every Dynatrace MCP call names the same person, with no stitching required between platforms.
• Usage and costs are observable in Dynatrace. Token consumption and tool call volume are visible in your Dynatrace account management portal, so you can cleanly attribute costs to data owners.
• Adding more Dynatrace users doesn't increase your cost. Dynatrace consumption is priced on data, not per user, so onboarding more developers and on-call engineers doesn't instantly impact your billed costs.

Get started with the Dynatrace MCP Server for Rovo now

The integration is generally available. To connect it:

1. In Atlassian Jira or JSM, go to Atlassian Administration → Rovo → Rovo MCP server.
2. Add the Dynatrace MCP Server and authenticate against your Dynatrace tenant.
3. Select the Dynatrace tools you want to expose to your Rovo agents.

Full setup instructions are available in the Atlassian documentation and the Dynatrace MCP Server documentation.

Because the MCP Server is included with Dynatrace SaaS, you can easily set up a pilot program. Just connect the integration for one dev team, allow them access to a narrow set of tools, and then monitor the team's usage and related costs. The patterns that emerge (which tools are called, by whom, and at what cost) can serve as a basis for a confident wider rollout.