Skip to main content
Glama
KevinBuettner

docent-terminal-mcp

wait

Block until a running session command produces new output, then return only the unseen lines. Poll repeatedly to stream fresh results and the exit status.

Instructions

Keep waiting for what is running in the session -- what your last call left running (a run that timed out, settled, or returned at until), or else a command a human or another agent started -- and return its region: only the lines not shown before. The interactive form of sleep 30; tail log: call it as often as needed, with timeout_s up to the client's patience; each reply is new output only, and the command's exit status when it ends. Commands of others that finished since your last call are reported at once (regions lists the session without waiting). When a human's (or another agent's) unsubmitted text holds the prompt, waits for it to be erased or submitted, and says which. After a run into a program (gdb, python), waits for the program's prompt; after a shell command, for it to finish. show filters the lines as for run; until returns at a pattern, last_lines and save_to work as for run.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
showNoregex: reply with only the output lines matching it, in order, plus the last few (like `| grep`, but the command runs unfiltered and the log keeps everything), e.g. "error:|warning:|^FAIL" for a build -- or a program's answer: gdb's `step` under `set debug infrun 1`
untilNoregex: return as soon as output not shown to you before matches it, the command still running (as for `run`); one that never matches is a plain wait
save_toNoa file to copy the command's output into, as `> FILE 2>&1` would, while the command itself runs unredirected (the reply and the log are as usual): written at once, kept up to date while it runs, written in full when it ends. A relative path is in the session's current directory; the file is on the machine this server runs on, even for a session over ssh. For a later diff or grep by other tools; `read` and `search` need no file
sessionYesthe session's name (from session_create or session_list)
max_linesNolines of output shown in the reply; longer output is clipped in the middle, led by its summary lines (test results, compiler errors, make's failure) when the middle holds them; all of it stays readable with `read`/`search`
timeout_sNoseconds to keep waiting (the command keeps running after; `wait` again); at most 1500
last_linesNoreply with only the last N lines of the output (like `| tail -N`, but the command runs unfiltered and the log keeps everything; the reply says where the rest is); with `show`, how many last lines follow the matches (default 3)
show_afterNowith `show`: also this many lines after each match (like `grep -A N`); a match is numbered "N:", a line after one "N-"

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that only not-shown lines are returned, that the command keeps running after timeout and needs another wait, that exit status is returned on completion, and how it behaves when a human's unsubmitted text holds the prompt. It omits error/failure modes but covers the core runtime behavior thoroughly.

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 purpose is front-loaded, but the body is a dense paragraph of em-dash and parenthetical clauses that is harder to parse than necessary. Given the tool's complexity the length is defensible, yet several clauses could be tightened without losing information.

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?

An output schema exists, so return values need not be explained. For an 8-parameter interactive wait with rich per-parameter docs, the description covers the key scenarios (program prompt vs. shell completion, human-held prompt, repeated polling) well; only error/edge handling is thin.

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 coverage is 100% and each parameter already has a rich description, so the baseline is 3. The description's references to `show`, `until`, `last_lines` and `save_to` mostly defer to 'as for `run`' rather than adding meaning beyond the schema, so it neither compensates nor detracts.

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 opening states a specific verb (keep waiting) and resource (what is running in the session), then narrows the scope to two cases: your last `run` that timed out/settled/returned-at-until, or a command a human/other agent started. It explicitly distinguishes itself from siblings, noting `regions` lists the session without waiting and that `read`/`search` need no file, so an agent can route without opening another 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?

It gives clear context: call repeatedly with `timeout_s` up to the client's patience, after a `run` into a program wait for the prompt, after a shell command wait for it to finish. Alternatives are named (`regions` for a non-blocking listing, `read`/`search` for reading logs), though it stops short of an explicit 'when not to use'.

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