Skip to main content
Glama

Watch live or recent task stream transcript

watch_task

Tail a task's live stream transcript to monitor an in-flight general_task/explore_task sub-agent; omit stream_file for the latest run and check running/modified to spot abandoned work.

Instructions

Tails a task's live stream transcript. No args = latest run. Call it while a general_task/explore_task is in flight (this or any session) to watch the sub-agent work; the returned 'running' field plus 'modified' tell a live run from an abandoned one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tail_linesNoNumber of trailing lines to return (1..2000, default 400; 0 returns the full transcript, hard-capped at 200,000 chars).
stream_fileNoStream transcript to read. Omit for the latest task_<id>.stream in AGY_MCP_STATE_DIR. Accepted forms: an absolute path under AGY_MCP_STATE_DIR, a bare file name like "task_f8870173.stream", or a task id like "task_f8870173" / "f8870173".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does disclose useful behavior: it can watch runs in any session, and the returned 'running' plus 'modified' fields let an agent distinguish a live run from an abandoned one. It does not cover blocking behavior, cost, or permission requirements, but 'tails a transcript' clearly implies a read-only operation.

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?

Three short sentences, front-loaded with the core action, then the default-argument behavior, then the call condition. Nothing is wasted and no sentence repeats the schema or title verbatim.

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 two-parameter read-only tool with no output schema, the description covers what it does, when to invoke it, the cross-session scope, and the meaning of the key return fields. An agent has everything needed to invoke it correctly.

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 baseline is 3, but the description adds real meaning beyond the schema by stating that zero arguments selects the latest run, which ties the two optional params to a concrete default scenario. The remaining specifics (tail counts, path forms) are fully documented in the 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?

States a specific verb and resource ('Tails a task's live stream transcript') and scopes it precisely to observing a run rather than starting one. The relationship to general_task/explore_task makes it distinguishable from the sibling set, which otherwise contains only task-launching and listing tools.

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 trigger ('Call it while a general_task/explore_task is in flight (this or any session)'), including the cross-session case, plus the default behavior with no args. It stops short of stating when not to use it (e.g. after a run is complete, or vs. reading a finished log).

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