Skip to main content
Glama

Get Trace

get_trace
Read-onlyIdempotent

Return the spans of a single trace (up to 10000), plus a trace summary; or, with spanId and path, read one long value of one span.

Prefer correlate when investigating a trace — it returns the same spans plus correlated logs and metric exemplars in one call. Use get_trace only when you need the span tree alone and want to skip the log/exemplar lookup.

Spans come ordered by (timestamp, spanId) ascending; each carries parentSpanId so you can rebuild the tree. The summary gives root operation, span count, error count, total duration, and start time at a glance.

A trace with more spans than one response holds (10000, or fewer when spans are large) comes back with spansTruncated true, its earliest spans and a truncationHint: the spans call that reads the rest.

Returns spans' core fields by default; pass verbose=true to include their attributes (flattened in, plus a resource object). Long string values are capped. For raw columns or custom selection use run_sql.

Reading one long value: pass spanId and path to get one value of one span, in full or in slices, instead of the trace. A run_sql or spans result that cut a long value shows a marker with "truncated": true, the value's full length (chars), its structure (keys) and a "more" call that reads on.

Parameters for a slice: spanId; path, what to read: a column (raw, status_message), an attribute name (input.value), or a JSON path into a column or attribute holding JSON (output.value.results[2].body); find, text to jump to: the slice starts just before its first match at or after offset; offset, the character position to start at (default 0); length, how many characters to return (default 20000, max 50000).

A slice returns: spanId, path, chars (the value's full length), offset, text (the slice), nextOffset (null once the slice reaches the end), matches (every place find matches in the whole value, up to 20, each with its offset and the text around it; the slice starts at the first one at or after offset), and keys (the structure of the value at path, when it is JSON). To read on, call again with offset=nextOffset; to read another match, call again with offset set to that match's offset.

Returns (whole trace): traceId, traceUrl, rootOperation, spanCount, errorCount, totalDurationNanos, startTime, spans[], queryStats, spansTruncated, truncationHint. traceUrl opens this trace as a waterfall in the Fixter app, every span on its timeline with its attributes. When the user asks to see, open or visualize the trace, send them traceUrl rather than drawing the waterfall yourself; attach it whenever you cite the trace as evidence.

Input Schema

NameRequiredDescriptionDefault
findNoText to jump to; the slice starts just before its first match at or after offset.
pathNoWith spanId: column, attribute name, or JSON path, e.g. raw, input.value, output.value.results[2].body
lengthNoCharacters to return. Default 20000, max 50000.
offsetNoCharacter position to start at within the value. Default 0.
spanIdNoSpan id, lowercase hex. With path, returns that value of this span instead of the trace.
traceIdYesLowercase hex trace id
verboseNoReturn full spans incl. attributes and resource. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / find
      Added value: +{
      +  "description": "Text to jump to; the slice starts just before its first match at or after offset.",
      +  "type": "string"
      +}
    • addedInput schema / properties / length
      Added value: +{
      +  "description": "Characters to return. Default 20000, max 50000.",
      +  "format": "int32",
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "description": "Character position to start at within the value. Default 0.",
      +  "format": "int32",
      +  "type": "integer"
      +}
    • addedInput schema / properties / path
      Added value: +{
      +  "description": "With spanId: column, attribute name, or JSON path, e.g. raw, input.value, output.value.results[2].body",
      +  "type": "string"
      +}
    • addedInput schema / properties / spanId
      Added value: +{
      +  "description": "Span id, lowercase hex. With path, returns that value of this span instead of the trace.",
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  3. Added
  4. Removed
  5. First observed

TDQS

A4.5/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description does add real behavior: span ordering by (timestamp, spanId), truncation with spansTruncated/truncationHint, verbose attribute flattening, and long-value capping. It stops short of stating the practical cost of spanSize limits or pagination specifics beyond the truncation hint, so it is valuable rather than exhaustive.

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-loaded with the core purpose and the correlate comparison before any detail, and paragraphs are task-scoped (whole trace vs slice). It is long and slightly repetitive in re-explaining the slice parameters that the schema already lists.

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, the description enumerates the returned fields, the truncation contract, and the full slice return shape. An agent can call it, interpret truncation, and continue reading without guessing.

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

Parameters5/5

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

Coverage is 100%, and the description still adds meaning the schema cannot: how find and offset interact (the slice starts just before the first match at or after offset), how to continue via offset=nextOffset, and what the slice return shape contains. That is interaction semantics, not restatement.

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 and resource (returns the spans of a single trace plus a summary) and a distinct second mode (with spanId and path, read one long value of one span). It explicitly contrasts itself with the correlate sibling, so an agent can distinguish the two without opening either 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?

Gives an explicit routing rule: prefer correlate when investigating a trace because it returns the same spans plus logs and exemplars; use get_trace only when the span tree alone is needed. It also routes raw-column needs to run_sql, and explains the exact when-to-use condition for the slice mode.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources