Skip to main content
Glama

Trace Execution

trace_execution

Trace code execution line-by-line for a specific input, revealing which statements ran, in what order, with variable values and branch decisions. See exact paths taken versus skipped to debug why behavior occurred.

Instructions

Debug WHY, line by line, for the ONE input you actually ran it on: which statements fired, in what order, with what variable values at each step, and which if/elif/while/for/try branch was taken versus never taken. Want just the printed output instead? Use execute_code.

Returns events: ordered {step, line, event, func, locals}, one entry per traced line/call/return/exception in YOUR code only (library internals excluded). locals on each entry is only the names that changed since the previous step in that same call — not a full dump every line. A return entry also carries return_value; an exception entry carries exception_type/exception_message.

Also returns branches (hit count per if/elif/while/for/try line), lines_executed / lines_never_executed (coverage from a static parse), and truncated/truncated_reason when max_events or an internal size ceiling stopped RECORDING early (the underlying stdout/exit code are unaffected either way).

TRUST: the trace is produced BY the traced program at its OWN privilege — a debugging aid, not an attestation of behaviour, exactly as trustworthy as that program's own stdout. discarded_events / events_consistent are a best-effort tamper/corruption signal (never a guarantee) computed independently of the file's own content. unenforced may additionally note "only the main thread is traced" (sys.settrace is per-thread) or, fallback backend only, an OLE exit_code race.

For a structural Big-O guess with nothing executed, use analyze_complexity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesSource code to trace line by line
stdinNoText piped to the program's standard input; empty means no input
no_netNoBlock outbound network access for this run; best-effort on platforms without seccomp
max_cpuNoPer-call CPU-time ceiling in seconds; 0 means no explicit limit is set
timeoutNoWall-clock seconds before the run is killed; clamped to a 120s ceiling
languageYesRuntime to trace; only 'python3' is supported, any other value is refused
providerNoExecution backend id; only 'local' (the default) is supported here
max_eventsNoMax trace events to record before truncating; the run's own stdout/exit code are unaffected
max_memory_mbNoPer-call memory ceiling in MiB; 0 means no explicit limit is set
max_output_kbNoStdout/stderr capture cap in KiB per stream; 0 uses the 64 KiB default, hard-clamped to 240

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.12.0
    • addedInput schema / properties / code / description
      Added value: +"Source code to trace line by line"
    • addedInput schema / properties / language / description
      Added value: +"Runtime to trace; only 'python3' is supported, any other value is refused"
    • addedInput schema / properties / max_cpu / description
      Added value: +"Per-call CPU-time ceiling in seconds; 0 means no explicit limit is set"
    • addedInput schema / properties / max_events / description
      Added value: +"Max trace events to record before truncating; the run's own stdout/exit code are unaffected"
    • addedInput schema / properties / max_memory_mb / description
      Added value: +"Per-call memory ceiling in MiB; 0 means no explicit limit is set"
    • addedInput schema / properties / max_output_kb / description
      Added value: +"Stdout/stderr capture cap in KiB per stream; 0 uses the 64 KiB default, hard-clamped to 240"
    • addedInput schema / properties / no_net / description
      Added value: +"Block outbound network access for this run; best-effort on platforms without seccomp"
    • addedInput schema / properties / provider / description
      Added value: +"Execution backend id; only 'local' (the default) is supported here"
    • addedInput schema / properties / stdin / description
      Added value: +"Text piped to the program's standard input; empty means no input"
    • addedInput schema / properties / timeout / description
      Added value: +"Wall-clock seconds before the run is killed; clamped to a 120s ceiling"
  2. Addedv0.11.0

TDQS

A4.8/5.0
Behavior5/5

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

Even with no annotations carrying a safety profile, the description goes deep: it discloses that only user code is traced (library internals excluded), that `locals` only includes changed names, that `truncated` stops recording but leaves stdout/exit code unaffected, and the TRUST section warns the trace is not an attestation and that only the main thread may be traced.

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?

The description is substantial but well-organized into paragraphs: the core behavior, return details, then TRUST limitations. No redundant sentences exist, but the TRUST section is long and could be tightened without sacrificing value. It's slightly verbose, but every sentence does carry content.

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?

For a complex tool with ten parameters and an output schema, the description covers the outcome shape (`events`, `branches`, `lines_executed`, etc.), the semantics of truncation, and honest limitations like thread-only tracing and fallback backend races. An agent has enough to call the tool correctly and interpret its output.

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 alone defines the parameters. The description adds behavior context for `max_events` (recording truncates, stdout/exit unaffected) and mentions `max_events`/`max_cpu`/`max_memory_mb` semantics implicitly. It doesn't fully explain every property (e.g., `provider`) but those are already described in the schema, so the increment over the schema is meaningful though not exhaustive.

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 clearly states the tool 'Debug WHY, line by line' and specifies it traces the one input you ran it on, showing statements fired, order, variable values, and branches taken. It explicitly contrasts with execute_code (printed output) and analyze_complexity (Big-O guess), so an agent can distinguish it from relevant siblings without opening schemas.

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?

The description includes direct 'when-not' guidance: 'Want just the printed output instead? Use execute_code' and 'For a structural Big-O guess with nothing executed, use analyze_complexity.' It also implies when to use (debugging line-by-line behavior) and clearly separates from passive analysis.

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