Skip to main content
Glama
yunusemregul

dynatrace-bridge-mcp

by yunusemregul
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

get_trace

Show a single distributed trace as an indented span tree with per-call service, operation, timing, and callURI, so you can pinpoint slow or failing calls.

Instructions

Shows one trace as an indented span tree: for every call the service, the operation (request name or SQL statement), how often it ran, its start offset from the beginning of the trace, response time, self time, CPU / wait / suspension time, the technology, and the callURI of the node.

Pass trace_id and call_uri exactly as printed by list_traces, with a time window that contains the trace (the same window is fine). Runs of identical sibling calls (the same SQL statement 200 times) are collapsed into one line with the call count and total time. Large traces: min_duration_ms hides calls shorter than that, max_depth limits the nesting, limit caps the lines; the output always says what was hidden. Follow up with get_trace_details on a node's callURI for exceptions with stack traces, the code-level method tree, full SQL and HTTP headers.

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 tree lines to print. Default 150, at most 400. The output says how many were omitted.
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.
call_uriYesThe callURI printed next to the traceId by list_traces.
trace_idYesThe traceId printed by list_traces (32 hex characters).
max_depthNoShow only this many nesting levels (1 = only the entry call). Default: all levels.
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.
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.
min_duration_msNoHide calls (with everything below them) that took less than this many milliseconds in total. Default 0 = show all.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.6/5.0
Behavior4/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 well: it discloses sibling-call collapsing, that the output always reports what was hidden, and the operational constraint that the tool runs through the browser extension and that failure should be reported rather than worked around. It stops short of describing permission/authentication requirements or error modes beyond the extension failure.

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?

Front-loads the output shape, then usage, then large-trace controls, then follow-up, then the browser constraint, in four tight paragraphs. The long enumeration of tree fields is the one place that approaches padding, but it earns its place given there is no output schema.

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 9-parameter tool with no output schema and no annotations, the description supplies the missing return-format detail, the window-resolution rule, the large-trace capping semantics, and the runtime environment, so an agent has everything needed to call it correctly.

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 coverage is 100%, so the baseline is 3; the description adds behavior the schema does not state, namely that hidden output is always reported ('the output always says what was hidden', 'the output says how many were omitted') and that the response header shows the resolved absolute UTC window.

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 specific verb and resource ('Shows one trace as an indented span tree') and enumerates exactly what each line contains, so an agent can distinguish it from list_traces (discovery) and get_trace_details (deep dive) without opening the schema.

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 states precisely where the required identifiers come from ('Pass `trace_id` and `call_uri` exactly as printed by `list_traces`') and the follow-up path ('Follow up with `get_trace_details` on a node's `callURI`'). The time-window rule and the alternative tool are both named explicitly, leaving nothing to inference.

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