Skip to main content
Glama
yunusemregul

dynatrace-bridge-mcp

by yunusemregul

dynatrace_bridge_status

Check whether the Dynatrace Bridge is usable: server and extension versions, connected browsers, and configured environments. Run this first when another Dynatrace tool fails.

Instructions

Reports whether the Dynatrace Bridge is usable: server version and whether a newer release exists, whether the browser extension is connected and its version (each browser when several are connected), and the Dynatrace environments configured in the extension (name, environment id, URL).

Call this first when another Dynatrace tool fails with a connection, environment or session error, or when the user asks which environments are available. Works even when no extension is connected. Pass check_session: true to also run one small request per environment and see whether the browser is still logged in.

Where to start with the other tools. All take environment. All except get_problem, find_metrics, list_dashboards and read_settings also take the time arguments minutes_lookback / time_from / time_to (timestamps without a zone are read as UTC); those four have no time window.

  • An incident, or "what is wrong": list_problems, then get_problem with the P- id.

  • A slow or failing service: list_services (sort: "response_time" or "failure_rate") to find it, service_overview, then analyze_response_time or analyze_failures, then list_traces and get_trace for single requests.

  • Across all services, trace_statistics with request_kind: "web" and: slowest endpoints aggregation: "P95" (or "AVERAGE") plus min_calls: 20; most time-consuming endpoints aggregation: "SUM"; most CPU metric: "CPU_TIME", aggregation: "SUM"; most errors metric: "FAILED_REQUEST_COUNT" (a count metric, ranked by its COUNT).

  • Exceptions: top_exceptions. Slow or expensive SQL: top_database_statements. Slow or long-running cron jobs: cron_job_statistics.

  • Pod restarts, OOM kills, throttling: list_workloads, then pod_resources and pod_events. CPU or memory of a process: cpu_by_process_group, method_hotspots, process_runtime.

  • Anything else: find_entities for ids, find_metrics and query_metrics for the data behind any chart.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
check_sessionNoAlso verify each environment with one small read request. When no Dynatrace tab is open for an environment, the extension opens one in the foreground of the user's browser. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and does so well: it states the tool works with no extension connected, that check_session opens a Dynatrace tab in the foreground of the user's browser, and that it verifies login state per environment. It is honest about a side effect (opening tabs), though it doesn't cover latency/cost of probing all environments.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded: purpose first, then when-to-call, then the optional parameter, then the routing guide. The extensive per-tool routing block is genuinely useful but concerns the sibling tools rather than this one, so it dilutes conciseness somewhat even though each line is dense and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description fully compensates by enumerating the returned fields (version, upgrade availability, per-browser extension version, environment name/id/URL) and the error-recovery role. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter's schema already documents the read-request behavior and the default of false. The description adds only the goal framing ('see whether the browser is still logged in'), which is a slight enrichment but largely overlaps the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: reports bridge usability, server version/upgrade availability, extension connection and version per browser, and configured environments with name/id/URL. This is clearly a status/meta tool, cleanly distinguished from the diagnostic siblings (list_problems, service_overview, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger conditions: 'Call this first when another Dynatrace tool fails with a connection, environment or session error, or when the user asks which environments are available.' It also notes exclusions (works even with no extension connected) and provides a full routing map to siblings, so an agent knows exactly when this tool applies vs. alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.