Skip to main content
Glama
CronusL-1141

AI Team OS

by CronusL-1141
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

task_execution_trace

Retrieve a task's chronological execution timeline with optional checkpoints and stats to analyze performance and decision points.

Instructions

Get a task's execution timeline — plain, or with checkpoints + stats.

The separate task_replay tool was folded in here 2026-07-27: both answered "how did this task actually go", differing only in whether the answer carried the derived summary. include_stats=True is the old replay view.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
task_idYesTask ID
include_statsNoFalse (default) — timeline only (memo records + task lifecycle events, chronological). True — adds `checkpoints` (decision/summary points only) and `stats` (duration, step count, subtask count, memo-type breakdown).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.11.2
    • addedInput schema / properties / include_stats
      Added value: +{
+  "default": false,
+  "description": "False (default) — timeline only (memo records + task\nlifecycle events, chronological). True — adds `checkpoints`\n(decision/summary points only) and `stats` (duration, step count,\nsubtask count, memo-type breakdown).",
+  "type": "boolean"
+}
  2. First observedv1.9.0

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It transparently discloses the tool's history (task_replay fold-in, 2026-07-27) and the behavioral difference of include_stats. However, it doesn't disclose what happens on invalid/missing task_id, whether this is read-only versus potentially expensive, or output characteristics beyond the derived summary distinction.

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?

Efficient and well-structured: a lead sentence stating the core function, then a compact historical note explaining the merge. No wasted words; the tool-fold history is genuinely useful for agents that might remember task_replay.

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?

There's an output schema present, so return-value explanation isn't required. For a two-param read tool with full schema coverage, the description adequately covers behavior. Minor gap: no note about failure modes or performance for stats computation, but this is a fairly complete description for a filtered read tool.

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 description coverage is 100%, so the schema already documents both params. Still, the description adds real value by explaining include_stats in plain terms (the old replay view) and clarifying the distinction between timeline-only versus checkpoints+stats. The chronological memo/lifecycle-event detail goes beyond the schema's terse boolean description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Get a task's execution timeline' with the choice of plain vs checkpoints+stats. It's identifiable against siblings like task_status or task_run, though it doesn't explicitly name a distinguishing alternative.

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?

The description explains the plain-timeline vs include_stats distinction well. It doesn't explicitly name sibling alternatives to use instead ('when not to use this'), but the use-case framing around 'how did this task actually go' is clear. Notably it folds in task_replay history, which helps an agent understand the consolidation.

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

Deploy Server

Other Tools