Skip to main content
Glama

dialogbrain

by io.github.saloprj
OverviewDiscussionsAdmin

agents_trace_get

Read-onlyIdempotent

Fetch the full execution detail for a single trace — tool executions, events timeline, LLM call spans (with error_message on failures), and what the run cost.

cost_usd is the run's billed cost in USD, recorded even when the workspace pays with its own vendor key; 0 means nothing billable was recorded, null means the lookup could not run. Per-token detail is on each LLM span (input_tokens, output_tokens, cache_read_tokens, cache_creation_tokens).

Use after agents.traces_list identifies a specific trace of interest (failed run, slow run, unexpected outcome).

By default LLM system_prompt and prompt_messages are stripped — set include_llm_bodies=true to fetch them when diagnosing prompt engineering issues (emits a WARNING audit log). Set full=true to disable all field truncation. completion_text on failed LLM calls is always returned (capped at 8 KB).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNoDisable all field truncation. Escape hatch for a human operator. OMIT for the standard truncated view.
agent_idYesExpected agent_id — used for scope validation. Mismatch returns not_found.
trace_idYesTrace identifier returned by agents.traces_list.
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
include_llm_bodiesNoInclude system_prompt and prompt_messages in LLM spans. Audited at WARNING level. OMIT to keep them stripped (the default).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
+  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
+  "type": "integer"
+}
  2. Added
  3. Removed
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. Beyond that, the description discloses non-obvious behavior: LLM system_prompt and prompt_messages are stripped by default, include_llm_bodies=true triggers a WARNING-level audit log, full=true disables truncation, and completion_text is capped at 8 KB. This is substantial disclosure the annotations do not carry.

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?

Purpose and payload are front-loaded in the first sentence, followed by cost semantics, usage routing, then option defaults. Dense and nearly waste-free, though three paragraphs is longer than strictly needed for a single-trace getter and some field detail (per-token names) could have been left to the payload itself.

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?

There is no output schema, so the description carries the return-value burden and does so: it names the span fields, explains cost_usd's 0-vs-null distinction, and covers token-level fields. For a 5-param read tool with full schema coverage, an agent has everything needed to call and interpret it.

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 schema already documents each parameter; the baseline would be 3. The description adds marginal-but-real semantics: include_llm_bodies is for 'diagnosing prompt engineering issues' and its audit consequence, and full is framed as a 'human operator' escape hatch rather than a routine option.

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 ('Fetch the full execution detail for a single trace') and enumerates the payload (tool executions, events timeline, LLM spans with error_message, cost). It is immediately distinguishable from agents_traces_list (enumeration) and agents_traces_stats (aggregates), which appear as siblings.

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 explicitly says 'Use after agents.traces_list identifies a specific trace of interest (failed run, slow run, unexpected outcome)', naming the upstream sibling and the triggering conditions. The agent knows both the prerequisite call and the scenarios that select this tool.

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

All dialogbrain toolsInspect
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