Rius

Get Agent Trace

get_agent_trace

Read-only

Get one agent trace's span waterfall (spans in time order, indented by depth).

The header names the root span's agent and each row carries its own, so a multi-agent run shows which agent owned which span; pass either name back to list_agent_traces or list_spans as agent to see that agent's other work. The header also names who sent the trace — the sending ingest key's own email, which a console-made key usually carries too (it falls back to its creator's own email). Blank only when the key could not be resolved or the trace predates attribution.

The header also names the root span's session; pass it to list_spans(session_id=...) for the rest of that conversation. A session equal to the trace id means the run carried no session of its own. A trace whose spans carry more than one session gets a per-span session column.

trace_id: the trace id (from list_agent_traces). workspace: optional workspace id, name, or org-name/workspace-name when the same name occurs in two of your orgs (defaults to your default; use list_workspaces to discover them). include_content: when true, also return each span's captured content: LLM input/output messages, agent/tool input/output values, status messages and events. Off by default because full message content can be very large; pass true when you need to see what an LLM, agent, or tool span actually said, received, or returned (e.g. to inspect prompts, completions, or tool I/O).

Captured content is subject to the workspace's privacy controls: spans exported with capture_content=False or a mask have nothing extra to show.

Example:

Break down trace 4bf92f3577b34da6a3ce929d0e0e4736 for me.

{
    "name": "get_agent_trace",
    "arguments": { "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736" }
}

What did the LLM actually say in that failed span?

{
    "name": "get_agent_trace",
    "arguments": {
        "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
        "include_content": true
    }
}

Input Schema

TableJSON Schema

Name	Required	Description	Default
`trace_id`	Yes
`workspace`	No
`include_content`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, yet the description adds real behavior: include_content is off by default because content can be very large, captured content is subject to workspace privacy controls (capture_content=False or masks yield nothing), and the attribution field is blank only when the key can't be resolved or the trace predates attribution. That is substantive disclosure beyond the safety hints.

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 tool's action, then parameter docs, then worked examples. Most sentences earn their place, but the multi-sentence digression on the ingest key's own email and its fallback to the creator's email is deeper detail than an agent needs to select or call the tool.

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?

An output schema exists so return values need not be explained, and the description still covers the waterfall layout, the header/row agent attribution, session semantics, and the multi-session per-span column. For a read-only three-parameter tool this is complete.

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?

Schema description coverage is 0%, so the description carries the full burden and does: trace_id is sourced from list_agent_traces, workspace accepts an id/name/`org-name/workspace-name` disambiguator and defaults to the default workspace, and include_content's semantics and default are spelled out. All three parameters gain meaning not present in the bare schema.

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?

Opens with a specific verb and resource plus the exact output shape: 'Get one agent trace's span waterfall (spans in time order, indented by depth).' It also implicitly distinguishes itself from list_agent_traces (enumerating traces) and list_spans (per-span queries) by describing the waterfall-of-one-trace scope.

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

Usage Guidelines4/5

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

Gives concrete follow-up routing ('pass either name back to list_agent_traces or list_spans as `agent`', 'pass it to `list_spans(session_id=...)` for the rest of that conversation') and states exactly when to set include_content=true. It never states when not to use this tool, but the context for use is unambiguous.

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

All Rius tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?