Skip to main content
Glama
yunusemregul

dynatrace-bridge-mcp

by yunusemregul
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

trace_statistics

Rank endpoints by response time, total time, CPU usage, or failures by aggregating a metric over requests, split by a dimension, across services.

Instructions

Multidimensional analysis over traces: aggregates one metric over all matching requests, split by one dimension, across all services or for one. The tool for "which endpoints are the slowest / cost the most time / burn the most CPU / fail the most".

Recipes (the metric defaults to RESPONSE_TIME and the dimension to the request name {Request:Name}; add request_kind: "web" to rank HTTP endpoints only, because without it SQL statements dominate an environment-wide ranking; add service for one service):

  • slowest endpoints: aggregation: "P95" (or "AVERAGE", the default for time metrics) with min_calls: 20, so that requests seen once or twice do not win;

  • most time-consuming endpoints: aggregation: "SUM";

  • most CPU: metric: "CPU_TIME", aggregation: "SUM";

  • most errors: metric: "FAILED_REQUEST_COUNT" (or HTTP_5XX_ERROR_COUNT), a count metric, ranked by its COUNT by default;

  • by something else: dimension: "{Relative-URL}", "{HTTP-Status}", "{Exception:Class}", "{Service:Name}", or a request attribute as "{RequestAttribute:<name>}".

list_definitions: true lists the metrics, dimensions and request attributes this environment has. aggregation picks the column the rows are ranked by; the header names it. The table shows every aggregate Dynatrace returns. For a time metric these are requests (the number of requests), avg, median, p90, p95, the chosen percentile, max, min and sum. For a count metric (Dynatrace returns a COUNT for it) they are printed under Dynatrace's own names, COUNT, COUNT_PER_MINUTE, LOAD, AVERAGE, MIN, MAX, with a line saying what is known about them. timeseries: true adds the top values over time. Each row prints the request id and, without service, the service it belongs to. Dynatrace returns at most its top 100 values, those with the largest total (sum, or COUNT for a count metric), and leaves out values with too few sampled requests. Ranking by anything else (avg, p95, max, …) re-sorts only those 100, so a rarely called slow request outside them is missing; the output says when that happened.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of dimension values to print. Default 25, at most 200. The output says how many were omitted.
failedNotrue = only failed requests, false = only successful requests. Omit for both.
metricNoMetric to aggregate, e.g. RESPONSE_TIME, CPU_TIME, WAIT_TIME, REQUEST_COUNT, FAILED_REQUEST_COUNT, FAILURE_RATE, HTTP_5XX_ERROR_COUNT, EXCEPTION_COUNT, DATABASE_CHILD_CALL_COUNT, DATABASE_CHILD_CALL_TIME. Default RESPONSE_TIME. List them with list_definitions.
requestNoOne request (endpoint, SQL statement, job) of `service`: its name or a part of the name (e.g. '/cart/checkout'), or its SERVICE_METHOD-… id. A name is looked up among the requests of `service` (one extra request), so it needs `service`; several matches return the candidates instead of guessing. An id works without a lookup.
serviceNoRestrict to one service, as an entity id (SERVICE-1234567890ABCDEF) or a name. A name that matches several entities returns the candidates instead of guessing. Omit for all services.
time_toNoAbsolute end time, ISO 8601; without a zone it is read as UTC. Without time_from, the window starts minutes_lookback before this. Must not be in the future.
dimensionNoDimension to split by, in braces, e.g. {Request:Name}, {Relative-URL}, {URL:Host}, {HTTP-Status}, {HTTP-Method}, {Exception:Class}, {Service:Name}, {Request:Failure}, or a request attribute as {RequestAttribute:<name>}. Default {Request:Name}. List them with list_definitions.
http_codeNoHTTP response code filter: one code ('404'), a class ('4xx', '5xx') or a range ('400-599').
min_callsNoLeave out rows with fewer requests than this: the `requests` column of a time metric; for other metrics it is compared with Dynatrace's `LOAD` aggregate. Use about 20 when ranking by AVERAGE, P95 or MAX so that rarely called requests do not win. Default 0.
time_fromNoAbsolute start time, ISO 8601 (e.g. '2026-09-23T10:28:00Z'). A timestamp without a zone (Z or ±hh:mm) is read as UTC. Without time_to, the window runs from here to now. Must not be in the future.
percentileNoPercentile (1-99) for the PERCENTILE aggregation, shown as an extra column. Default 80.
timeseriesNoAlso summarise the top dimension values over time. Default false.
aggregationNoAggregate the rows are ranked by. Default: COUNT for count metrics (those Dynatrace returns a COUNT for: REQUEST_COUNT, FAILED_REQUEST_COUNT, …), AVERAGE for every other metric. SUM = total time (on a count metric it means COUNT). LOAD = the number of requests of a time metric (the `requests` column). PERCENTILE needs `percentile`. An aggregate the metric does not have is an error that lists the available ones.
environmentNoWhich Dynatrace environment to query, as named in the Dynatrace Bridge extension popup. Omit it for the default, the first environment configured there. The names are not listed here because the extension had not connected yet when this description was built; `dynatrace_bridge_status` lists them.
http_methodNoHTTP method of the request.
raw_filtersNoEscape hatch for servicefilter types without a dedicated argument. Each entry is {type, values}; type is a numeric id or one of CPU_TIME, CALL_INSTANCE_ID, CALL_TREE, CALL_URI, CALL_TAG, WAIT_TIME, SYNC_TIME, SUSPENSION_TIME, CALLEE, CALLER, PROXY, SERVICE_ID, EXCEPTION, DATABASE_STATEMENT, DATABASE_TABLE, FLAWS, DISK_IO_TIME, NETWORK_IO_TIME, NUMBER_OF_DB_CALLS, NUMBER_OF_NON_DB_CALLS, TIME_SPENT_IN_DB_CALLS, TIME_SPENT_IN_NON_DB_CALLS, TRACE_ID, THREAD_NAME, PROCESSING_TIME, DATABASE_VENDOR, DATABASE_NAME, ENTITY_TAG, PG_NAME, PG_TAG, DATABASE_ROW_COUNT, DATABASE_FETCH_COUNT, WEBREQUEST_HOSTNAME, KEY_REQUEST, RELEASE, BUILD, STAGE, PRODUCT, SPAN_NAME, SPAN_ATTRIBUTE, ENTRY_POINT. Value formats of these types are not verified; time values are microseconds.
request_kindNoweb = only requests of web request and web services (HTTP endpoints, including calls to unmonitored hosts); database = only SQL statements. Omit for every kind (also background activity, custom and messaging services).
url_containsNoOnly web requests whose URL contains this text. The quick way to filter by a URL path fragment (e.g. '/checkout') without knowing the service or the request: it works with or without `service`. It matches nothing for non-web requests (SQL statements, cron jobs, messaging, custom services), which have no URL; use `request` for those.
merge_servicesNotrue = one row per dimension value across services; false (default) = one row per dimension value and service. Ignored when `service` is given.
definitions_viewNoWhich built-in analysis view list_definitions reads. Default topweb (web requests); topdb / topsql for database statements, exceptions for exception analysis.
list_definitionsNoDiscovery mode: list the available metrics and dimensions instead of running an analysis.
minutes_lookbackNoWindow length in minutes. Default 120. With neither time_from nor time_to it means the last N minutes up to now; with only time_to it means the N minutes ending at time_to; ignored when time_from is given. The response header always shows the resolved absolute UTC window.
request_group_idNoA request type as a SERVICE_METHOD_GROUP-… id. For a 'Requests to unmonitored hosts' service this id is the target host (printed by list_service_requests; there the host name can also be passed as `request`).
request_group_nameNoDisplay name belonging to request_group_id, exactly as printed next to the id. Pass it together with request_group_id.
request_attribute_idNoOnly with metric REQUEST_ATTRIBUTE: the id of the numeric request attribute, as printed by list_definitions.
response_time_max_msNoOnly requests whose response time is at most this many milliseconds.
response_time_min_msNoOnly requests whose response time is at least this many milliseconds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the top-100 Dynatrace cap, that ranking by non-default aggregates only re-sorts those 100 (so rare slow requests are missing), that low-sample values are dropped, and that the output flags omissions. It also uniquely discloses the browser-extension execution path and instructs the agent to report errors rather than escalate to automation.

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?

It is long, but well front-loaded: the one-line purpose comes first, then the recipes, then the output/caveat notes. Nearly every sentence carries operational information, though a few (e.g., the repeated enumeration of count-metric aggregate names) could be tightened.

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?

For a 27-parameter, zero-required tool with no output schema and no annotations, the description is unusually complete: it documents defaults, ranking semantics, the 100-value truncation caveat, output columns, and the environment/extension dependency. Nothing essential for correct invocation is left unaddressed.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it explains defaulting behavior (metric defaults to RESPONSE_TIME, dimension to {Request:Name}), why min_calls ~20 matters when ranking by AVERAGE/P95/MAX, and how aggregation maps to the ranked column. This is meaningful value on top of already-documented parameters.

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?

The description opens with a precise verb+resource ('aggregates one metric over all matching requests, split by one dimension') and frames it as the tool for ranking endpoints by latency/cost/CPU/failures. This clearly separates it from siblings like list_traces, get_trace, or analyze_response_time, which enumerate or drill into individual traces rather than aggregate.

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?

It gives explicit recipes tied to distinct intents (slowest endpoints, most time-consuming, most CPU, most errors) with the exact parameter combinations, and names the alternative discovery path (`list_definitions: true`). It also states when to add `request_kind: "web"` and why (SQL statements otherwise dominate), which is actionable when-to-use guidance.

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

Deploy Server

Other Tools