tracehub-mcp

Overview Schema Source Related Servers Discussions Admin

Get Trace

get_trace

Read-onlyIdempotent

Retrieve complete trace details by trace ID, including all spans and attributes. Returns parsed OpenTelemetry data for LLM operations to analyze performance and errors.

Instructions

Get complete trace details by trace ID.

Returns all spans with attributes, including parsed Opentelemetry data for LLM operations.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`trace_id`	Yes	Trace identifier
`detail_level`	No	"full" (default) returns every attribute/event value in full, unchanged from this tool's original behavior. "summary" elides known-large gen_ai.* fields (input/output messages, system instructions, retrieval documents) and truncates long event-attribute values, for callers that don't need full prompt/completion bodies.	full

Output Schema

TableJSON Schema

Name	Required	Description	Default
`spans`	Yes
`status`	Yes
`trace_id`	Yes
`has_errors`	Yes
`span_count`	Yes
`start_time`	Yes
`duration_ms`	Yes
`llm_summary`	No
`detail_level`	Yes
`service_name`	Yes
`root_operation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.11.0Sep 19, 2026

addedInput schema / properties / detail_level / description

Added value: +"\"full\" (default) returns every attribute/event value\nin full, unchanged from this tool's original behavior. \"summary\"\nelides known-large gen_ai.* fields (input/output messages, system\ninstructions, retrieval documents) and truncates long\nevent-attribute values, for callers that don't need full\nprompt/completion bodies."

addedInput schema / properties / trace_id / description
```
Added value: +"Trace identifier"
```

Changed16 schema fields changedv0.9.0Sep 17, 2026

addedInput schema / properties / detail_level

Added value: +{
+  "default": "full",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}

addedOutput schema / description

Added value: +"Structured response shape for the get_trace tool - see\nSearchTracesResult's docstring for why this is a real model rather than\na bare str.\n\ndetail_level echoes back what was actually applied: \"full\" reproduces\nthis tool's original byte-for-byte behavior; \"summary\" elides/truncates\nthe same known-large gen_ai.* fields that LLMSpanAttributes.prompt_preview/\ncompletion_preview already only ever preview (e.g. gen_ai.input.messages,\ngen_ai.output.messages) instead of dumping them in full."

addedOutput schema / properties / detail_level

Added value: +{
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / duration_ms
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / has_errors
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / llm_summary

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

removedOutput schema / properties / result

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / root_operation
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / service_name
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / span_count
```
Added value: +{
+  "type": "integer"
+}
```

addedOutput schema / properties / spans

Added value: +{
+  "items": {
+    "description": "Full per-span detail for the get_trace tool - see TraceDetail's\ndocstring for why this is a real model rather than a bare str.",
+    "properties": {
+      "attributes": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "duration_ms": {
+        "type": "number"
+      },
+      "events": {
+        "items": {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "llm_attributes": {
+        "anyOf": [
+          {
+            "additionalProperties": true,
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "operation_name": {
+        "type": "string"
+      },
+      "parent_span_id": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "service_name": {
+        "type": "string"
+      },
+      "span_id": {
+        "type": "string"
+      },
+      "start_time": {
+        "format": "date-time",
+        "type": "string"
+      },
+      "status": {
+        "enum": [
+          "OK",
+          "ERROR",
+          "UNSET"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "span_id",
+      "parent_span_id",
+      "operation_name",
+      "service_name",
+      "start_time",
+      "duration_ms",
+      "status",
+      "attributes",
+      "events"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / start_time

Added value: +{
+  "format": "date-time",
+  "type": "string"
+}

addedOutput schema / properties / status

Added value: +{
+  "enum": [
+    "OK",
+    "ERROR",
+    "UNSET"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / trace_id
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "result"
-]New value: +[
+  "trace_id",
+  "service_name",
+  "root_operation",
+  "start_time",
+  "duration_ms",
+  "status",
+  "span_count",
+  "has_errors",
+  "spans",
+  "detail_level"
+]

removedOutput schema / x-fastmcp-wrap-result
```
Removed value: -true
```

First observedv0.1.0Sep 12, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond annotations: it promises 'all spans with attributes,' flags parsed OTLP LLM data as included, and — via the detail_level parameter — discloses that 'full' retains original behavior while 'summary' elides known-large gen_ai.* fields (input/output messages, system instructions, retrieval documents) and truncates long event-attribute values. No contradiction with annotations.

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

Conciseness5/5

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

Two front-loaded sentences carry the entire tool purpose with zero filler: the primary action comes first, followed by a single sentence detailing return richness. The detail_level parameter text is longer but every clause earns its place by explaining behavioral consequences (elision targets and truncation behavior). Nothing is redundant with the input schema.

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

Completeness4/5

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

For a point-lookup tool with a full output schema, safety annotations, and 100% schema coverage, the description is nearly complete: it states what is returned, mentions OTLP data specifically, and the detail_level parameter explains the only behavioral switch. The one gap is that it does not explicitly route the agent to search_traces for trace discovery when an ID is not known, but this is a minor omission given the tool's straightforward name and signature.

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 description coverage is 100%, so the schema already documents both trace_id and detail_level thoroughly. The description adds no format or syntax detail for trace_id beyond 'by trace ID,' and the detail_level parameter description in the schema is already rich. With full schema coverage, the baseline of 3 is appropriate; the description gestures at the parameter's purpose but does not materially extend it.

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 states a specific verb and resource ('Get complete trace details by trace ID') and clarifies the return content ('all spans with attributes, including parsed Opentelemetry data for LLM operations'). The 'by trace ID' framing makes this a point-lookup tool, clearly distinct from siblings like search_traces and get_llm_usage. The 'complete... all spans' language positions it precisely against the search/list siblings.

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

Usage Guidelines3/5

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

Usage context is implied rather than explicit: the agent can infer 'use this when you already have a trace ID and want full details,' but the description never says when not to use it or names an alternative such as search_traces for discovery. The detail_level parameter does provide conditional guidance ('for callers that don't need full prompt/completion bodies'), which earns partial credit, but no explicit when/when-not routing exists.

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