selfhosted-sentry-mcp

get_trace_details

Read-onlyIdempotent

Retrieve a distributed trace as a flat, tree-ordered span list with depths, totals, and unattached errors to diagnose request flow and performance issues. Searches the last 90 days.

Instructions

Get a distributed trace as a compact, flat list of spans/transactions (id, parent id, op, description, transaction, project, duration ms, start time, linked errors) in tree order with depth, plus totals and errors not attached to any span. Searches the last 90 days. Requires performance/tracing data.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "trace_id": "<trace_id>"
    },
    "name": "get_trace_details"
  }
}

Input Schema

Name	Required	Description	Default
`trace_id`	Yes	Trace ID (32-character hex string).
`max_spans`	No	Max spans to return (1-500, default: 100). Totals always cover the whole trace.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 21, 2026

changedInput schema / properties / max_spans / description

Previous value: -"Max spans to return (1-500, default: 100)."New value: +"Max spans to return (1-500, default: 100). Totals always cover the whole trace."

changedInput schema / properties / trace_id / description

Previous value: -"Trace ID."New value: +"Trace ID (32-character hex string)."

First observedv1.2.0Jul 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, idempotentHint and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond them: the hard 90-day retention window, the requirement for performance/tracing data to be present, the tree-order-with-depth shape of results, and that errors unattached to any span are also returned. It stops short of describing truncation behavior or response volume limits, which the schema partly covers.

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?

Front-loaded verb and resource, then a single dense parenthetical enumerating fields, then two short constraint sentences. No filler, no repetition of the title, and every clause carries information an agent needs.

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?

With no output schema, the description carries the burden of explaining the return value, and it does so well: flat span list with fields, tree order plus depth, totals, and unattached errors. What it omits is pagination/truncation guidance tied to max_spans and whether the response indicates a truncated trace — a meaningful gap for a tool that can return up to 500 spans.

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 both trace_id (32-char hex) and max_spans (1-500, default 100) are already documented, including the note that totals always cover the whole trace. The description's parenthetical field list mirrors the output rather than adding syntax or constraints for the inputs. 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?

Specific verb ('Get') plus resource ('a distributed trace') with an explicit enumeration of the returned span fields and the fact it is returned as a flat, tree-ordered list. An agent can immediately tell this is a read of one trace's span structure, distinct from the issue/event/release tools among the 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?

It states a precondition ('Requires performance/tracing data') and a scope constraint ('Searches the last 90 days'), which are useful gating facts. However, it never says when to prefer this over an alternative (e.g. get_stack_frames or get_sentry_event_details) or what to do when the trace is older than 90 days or tracing is unavailable. Usage is implied rather than directed.

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