Skip to main content
Glama

Get workflow run traces

get_workflow_run_traces
Read-onlyIdempotent

Get the full per-step execution trace of a run by run id (paged). Each step lists its blocks with the input each consumed and the output it produced, plus any error_message, and the variable scope captured at that step. Use this to debug why an expression or block produced the wrong value. Large captured values are shortened, with a marker saying so: a scope entry may point at the block output beside it rather than repeat it (the value is in the same trace). On UNATTENDED runs only — a live endpoint serve, a schedule falling due — text copied verbatim from the definition (a literal expression) is also replaced by its path there; read it with get_workflow_version. Those runs are shortened harder overall too, so to capture a value in full, re-run it yourself (run_workflow / preview_dynamic_endpoint / run_schedule_now) — runs you trigger keep everything, literals included. A loop block, and an llm block with tools (an agent), lists iterations: each loop iteration or agent turn with the blocks it ran (iterations_total is how many actually ran; a long run keeps the first and last and may drop some between). A run with many or large steps stores some of them with it, from its start and its end (a sub-workflow's steps count, one each), and keeps the complete set separately for two weeks; these pages read the complete set when there is one, and trace_truncated says only part of the run was stored with it. For an agent turn the first block is an llm block recording that one model call — its output carries stop_reason, input/output tokens, tool_calls and the start of the reply, and started_at/finished_at give how long the call took — followed by the tools it called.

Input Schema

NameRequiredDescriptionDefault
run_idYesthe run id returned by run_workflow
page_sizeNomaximum number of step traces to return in this page
page_tokenNotoken from a previous response's next_page_token to fetch the next page

Output Schema

NameRequiredDescriptionDefault
stepsYes
next_page_tokenYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / steps / items / properties / blocks / items / properties / iterations
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "blocks": {
      +        "items": {
      +          "additionalProperties": false,
      +          "properties": {
      +            "block": {
      +              "type": "string"
      +            },
      +            "error_message": {
      +              "type": "string"
      +            },
      +            "finished_at": {
      +              "type": "integer"
      +            },
      +            "input": {
      +              "additionalProperties": true,
      +              "type": "object"
      +            },
      +            "iterations_total": {
      +              "type": "integer"
      +            },
      +            "output": {
      +              "additionalProperties": true,
      +              "type": "object"
      +            },
      +            "started_at": {
      +              "type": "integer"
      +            },
      +            "status": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "block",
      +            "status"
      +          ],
      +          "type": "object"
      +        },
      +        "type": [
      +          "null",
      +          "array"
      +        ]
      +      },
      +      "index": {
      +        "type": "integer"
      +      }
      +    },
      +    "required": [
      +      "index",
      +      "blocks"
      +    ],
      +    "type": "object"
      +  },
      +  "type": [
      +    "null",
      +    "array"
      +  ]
      +}
  2. Changed1 schema field changed
    • removedOutput schema / properties / steps / items / properties / blocks / items / properties / iterations
      Removed value: -{
      -  "items": {
      -    "additionalProperties": false,
      -    "properties": {
      -      "blocks": {
      -        "items": {
      -          "additionalProperties": false,
      -          "properties": {
      -            "block": {
      -              "type": "string"
      -            },
      -            "error_message": {
      -              "type": "string"
      -            },
      -            "input": {
      -              "additionalProperties": true,
      -              "type": "object"
      -            },
      -            "iterations_total": {
      -              "type": "integer"
      -            },
      -            "output": {
      -              "additionalProperties": true,
      -              "type": "object"
      -            },
      -            "status": {
      -              "type": "string"
      -            }
      -          },
      -          "required": [
      -            "block",
      -            "status"
      -          ],
      -          "type": "object"
      -        },
      -        "type": [
      -          "null",
      -          "array"
      -        ]
      -      },
      -      "index": {
      -        "type": "integer"
      -      }
      -    },
      -    "required": [
      -      "index"
      -    ],
      -    "type": "object"
      -  },
      -  "type": [
      -    "null",
      -    "array"
      -  ]
      -}
  3. Changed1 schema field changed
    • addedOutput schema / properties / steps / items / properties / blocks / items / properties / iterations
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "blocks": {
      +        "items": {
      +          "additionalProperties": false,
      +          "properties": {
      +            "block": {
      +              "type": "string"
      +            },
      +            "error_message": {
      +              "type": "string"
      +            },
      +            "input": {
      +              "additionalProperties": true,
      +              "type": "object"
      +            },
      +            "iterations_total": {
      +              "type": "integer"
      +            },
      +            "output": {
      +              "additionalProperties": true,
      +              "type": "object"
      +            },
      +            "status": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "block",
      +            "status"
      +          ],
      +          "type": "object"
      +        },
      +        "type": [
      +          "null",
      +          "array"
      +        ]
      +      },
      +      "index": {
      +        "type": "integer"
      +      }
      +    },
      +    "required": [
      +      "index"
      +    ],
      +    "type": "object"
      +  },
      +  "type": [
      +    "null",
      +    "array"
      +  ]
      +}
  4. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Goes far beyond the readOnly/idempotent annotations: discloses output truncation of large captured values, the marker-and-pointer convention for scope entries, harsher shortening and literal-path substitution on UNATTENDED runs, two-week retention of the complete step set, the trace_truncated flag, and iteration behavior for loop and agent blocks. This is exactly the kind of context annotations cannot carry.

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

Conciseness3/5

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

The core purpose is front-loaded, but the description is a single dense wall of text with heavy parentheticals and em-dash asides (unattended-run caveats, loop/agent iteration detail, retention, agent turn block layout). Most sentences earn their place, but the lack of structure makes it harder to scan than it needs to be.

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?

Despite an output schema already existing, the description supplies the interpretive context an agent needs to read a trace correctly: truncation markers, trace_truncated, iteration counts, and per-turn token/tool_calls fields. Nothing material is missing for correct invocation or interpretation.

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 all three params (run_id, page_size, page_token) are already documented in the schema. The description says the output is 'paged' but adds no format or range detail beyond the schema's own page_token/page_size descriptions, so the baseline of 3 applies.

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+resource+scope: 'Get the full per-step execution trace of a run by run id (paged)'. It then differentiates itself from the run-summary sibling by explaining the step/block/variable-scope content and its debugging purpose ('debug why an expression or block produced the wrong value'). An agent can tell this apart from get_workflow_run or list_runs without opening a schema.

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 an explicit use case ('Use this to debug why an expression or block produced the wrong value') and names concrete alternatives when trace data is lossy: re-run with run_workflow / preview_dynamic_endpoint / run_schedule_now to capture values in full. It stops short of stating when NOT to use it (e.g. use get_workflow_run for run status only), so it is strong but not fully exhaustive.

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