MCP Server Challenge entry #9: R.E.A.D.Y. - Reliability Evidence Assessment for Dynatrace Readiness

MaximilianoML — Tue, 05 May 2026 10:25:12 GMT

R.E.A.D.Y. Project Use Case Write-Up

R.E.A.D.Y. is a Dynatrace-native app that uses Dynatrace Remote MCP, DQL, and Dynatrace platform APIs to transform observability data into two practical operator workflows:

Problems Intelligence for real operational triage
Ready Report Generation for fleet-level operational readiness

The goal is not to create another chatbot-first experience. Instead, R.E.A.D.Y. reduces manual observability work by collecting, normalizing, and scoring evidence before any AI explanation is generated.

The workflow follows a simple pattern:

Dynatrace MCP / DQL / APIs
-> normalized evidence
-> deterministic checks and scoring
-> optional OpenAI summarization
-> operator-ready insight

Problem We Wanted to Solve

In many environments, the signals already exist in Dynatrace, but answering operational questions still requires too many manual steps.

Operators often need to:

review recent Davis Problems
understand which services, applications, or entities are most affected
compare categories such as Error, Slowdown, Resource, Availability, or Custom
inspect duration and recurrence patterns
identify the next entity to investigate
assess whether a service or application fleet is operationally ready

The data is available, but the workflow is fragmented. R.E.A.D.Y. brings that evidence together into a structured, repeatable, and operator-friendly experience.

Tools Used

1. Dynatrace Remote MCP

Dynatrace Remote MCP is used as the main evidence and context bridge.

MCP tools used in the project include:

execute-dql
get-entity-id
get-entity-name
query-problems
get-problem-by-id
find-documents
find-troubleshooting-guides

2. Dynatrace Platform APIs and App Functions

Dynatrace App Functions are used on the backend side of the app to orchestrate evidence collection and report generation securely.

This keeps sensitive configuration and tokens out of the browser and makes the flow more production-friendly.

3. OpenAI API

OpenAI is used only after the evidence has already been collected, normalized, and scored.

The AI layer is optional and is used to generate concise operator-facing explanations from the real evidence set, not to invent conclusions.

4. Playbook based

The Playbooks layer provides structured guidance for the LLM, defining how it should use Dynatrace MCP tools, DQL, and platform evidence during the analysis flow. Instead of allowing the model to guess, each playbook orients the LLM to first collect evidence, resolve entities, query Problems or telemetry when needed, validate the available context, and only then generate an operator-facing explanation. This keeps the output grounded in real Dynatrace data, reduces hallucination risk, and makes the workflow repeatable across different operational scenarios.

Primary Use Case 1: Problems Intelligence for Real Operational Triage

Scenario

An operator wants to understand the health of a selected scope, such as services, applications, frontends, or infrastructure, over a time window like the last 2 hours, 24 hours, 7 days, or 30 days.

Instead of opening multiple Dynatrace views manually, the operator opens the Problems view in R.E.A.D.Y. and filters by:

time window
impact
status
category or type

What the App Does

Queries recent Davis Problems through Dynatrace MCP.
Normalizes the result set into a stable Problems overview payload.
Aggregates total Problems, active vs. closed Problems, status, category, time trends, duration statistics, recurrent Problems, top affected entities, and slowdown-related endpoints or services.
Resolves entity IDs into readable names using MCP.
Links affected entities directly to Dynatrace topology views.
Optionally generates one AI Operator Insight from the real evidence set.

Why MCP Matters

MCP makes the integration practical because the app can use stable, named tools instead of hardcoding every tenant-specific retrieval path into the UI.

It allows the app to:

discover available tools
query Problems consistently
resolve entity names
execute DQL
search related documentation and troubleshooting content

Results Achieved

a live Problems dashboard backed by real Dynatrace data
filtering by scope, status, impact, category, and time window
readable entity names where resolution is possible
direct links to affected entities in Dynatrace
histograms showing how long Problems stay open
category-level duration distribution
recurrence and concentration signals
optional AI-generated operator insight based only on collected evidence

Practical Value

This helps operators answer questions such as:

Are current Problems active pressure or mostly historical noise?
Which category dominates this time window?
Are Slowdown Problems short-lived or staying open too long?
Is one service, application, or entity repeatedly involved?
Which entity should be inspected next?
Where is operational risk concentrated?

Primary Use Case 2: Fleet-Level Ready Reports for Operational Readiness

Scenario

A platform team or SRE team wants to assess whether a fleet is operationally ready.

This is different from simply checking whether telemetry exists. A service may have traces and metrics but still be missing important operational metadata, ownership, documentation, or governance signals.

R.E.A.D.Y. currently supports readiness generation for:

All Services
All Applications

What the App Does

The Ready Report workflow collects evidence for the selected scope and evaluates readiness using deterministic checks.

Example signals include:

ownership metadata
team tags
environment tags
runbook or contact metadata
dashboard evidence
documentation evidence
governance metadata
application or service operational context

The app then generates a structured report containing:

overall readiness score
domain-level results
detected gaps
recommendations
evidence status

The result clearly separates:

evidence present
evidence missing
evidence unknown or unavailable

That distinction is important. R.E.A.D.Y. does not pretend to know more than the data supports.

Why This Is Useful

Readiness reviews are often manual and inconsistent. One team may consider a service ready because it has traffic. Another team may expect ownership, SLOs, dashboards, alerts, documentation, and runbooks.

R.E.A.D.Y. makes that conversation more explicit and repeatable by turning readiness into an evidence-based workflow.

Results Achieved

real fleet-level readiness generation for Services
real fleet-level readiness generation for Applications
deterministic scoring before AI explanation
clear visibility into missing operational metadata
structured recommendations based on the collected evidence
a repeatable report format that can be reused across environments

Repeatable Workflow Pattern

This project is not tied to one specific tenant. The same pattern can be reused in other Dynatrace environments.

Configure the Dynatrace environment URL and platform token.
Configure the Dynatrace MCP server endpoint.
Discover available MCP tools.
Collect evidence through MCP, DQL, and platform APIs.
Normalize the evidence into a stable internal structure.
Apply deterministic checks and scoring.
Use AI only after the evidence is already structured.

This same pattern can be extended to:

Kubernetes workload readiness
synthetic monitor readiness
host readiness
deployment-change correlation workflows
fleet-wide governance audits
service ownership validation
operational metadata quality checks

Why This Is a Good Dynatrace MCP Use Case

This project demonstrates Dynatrace MCP beyond a simple chat interface.

R.E.A.D.Y. uses MCP as part of a real operator workflow for:

evidence discovery
DQL execution
entity resolution
Problems analytics
documentation search
troubleshooting context
readiness assessment

The key value is that MCP becomes an operational building block. It helps answer questions teams already care about:

Where should we investigate first?
What is recurring?
Which entities are driving risk?
What evidence is missing?
Is this fleet operationally ready?
What should be improved before production readiness is accepted?

Architecture Pattern

UI
-> Dynatrace App Function orchestration
-> Dynatrace MCP / DQL / Platform APIs
-> normalized evidence layer
-> deterministic rules and scoring
-> optional AI summarization
-> operator-facing result

This design keeps the system explainable, testable, auditable, extensible, and grounded in Dynatrace data.

What Makes It Creative

The creativity in R.E.A.D.Y. is not about replacing operators with AI.

The creative part is combining Dynatrace-native evidence collection, MCP-powered context retrieval, deterministic operational scoring, and optional AI explanation into one repeatable workflow.

Business and Operational Outcome

R.E.A.D.Y. helps teams:

shorten time to triage
standardize readiness reviews
identify recurring Problems
detect concentration of operational risk
highlight missing ownership or governance metadata
produce structured reports instead of relying on tribal knowledge
make operational readiness more evidence-based

In short, Dynatrace MCP is used here not as a novelty, but as a repeatable operational building block for observability-driven decision support.

Below you have some images of the App:

topic MCP Server Challenge entry #9: R.E.A.D.Y. - Reliability Evidence Assessment for Dynatrace Readiness in AI

MCP Server Challenge entry #9: R.E.A.D.Y. - Reliability Evidence Assessment for Dynatrace Readiness

R.E.A.D.Y. Project Use Case Write-Up

Problem We Wanted to Solve

Tools Used

1. Dynatrace Remote MCP

2. Dynatrace Platform APIs and App Functions

3. OpenAI API

4. Playbook based

Primary Use Case 1: Problems Intelligence for Real Operational Triage

Scenario

What the App Does

Why MCP Matters

Results Achieved

Practical Value

Primary Use Case 2: Fleet-Level Ready Reports for Operational Readiness

Scenario

What the App Does

Why This Is Useful

Results Achieved

Repeatable Workflow Pattern

Why This Is a Good Dynatrace MCP Use Case

Architecture Pattern

What Makes It Creative

Business and Operational Outcome

Problems Intelligence

Fleet-Level Ready Reports for Operational Readiness