Skip to main content
Glama

read_output

Retrieve pending output from a background Kali task by session ID. Waits up to the timeout, then returns available lines—useful for polling long-running commands.

Instructions

Read or poll bounded output from a background command job.

Typical workflow:

  1. send_input(session_id, "whoami\n")

  2. read_output(session_id, timeout=5) -> returns the command's output

The backend will wait up to timeout seconds for new output before returning whatever is available (which may be empty if the process has not produced anything yet).

Args: session_id: The session identifier to read from. timeout: Maximum seconds the backend should wait for new output before returning (default: 5). Use a higher value for slow commands (e.g. nmap, compilation). lines: Maximum number of output lines to return (default: 100). Older lines are trimmed first when the buffer exceeds this.

Returns: dict with at minimum: - success (bool): whether the read succeeded - output (str): the collected output text - session_id (str): echo of the session targeted - lines_returned (int): number of lines in output - error (str, optional): present only on failure

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linesNo
timeoutNo
session_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/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 of behavioral disclosure, and it does this well: it explains that the backend waits up to timeout seconds, may return empty output, and trims older lines when the limit is exceeded. One minor gap is that it does not clarify whether reading consumes/clears the buffer or returns the same accumulated output on repeated polls.

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?

The description is well-structured and efficient: summary sentence, minimal workflow, then Args and Returns bullets. There is no filler, and the most important usage semantics are front-loaded.

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?

For a simple poll/read tool with three parameters, the description covers the workflow, timeout behavior, line limiting, and return fields. It is complete enough for an agent to call correctly, though it could be stronger with an explicit note on whether repeated reads return new output only.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add meaning to all three parameters. It does: session_id is 'the session identifier to read from', timeout includes default, waiting semantics, and a 'use a higher value' heuristic, and lines explains default and trimming behavior. This fully compensates for the schema's lack of descriptions.

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?

The description opens with a clear verb and resource: 'Read or poll bounded output from a background command job.' It also shows a two-step workflow with send_input, making the tool's role concrete. However, it does not explicitly distinguish itself from sibling tools like job_output, so it stops short of full differentiation.

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 typical workflow example ('send_input(session_id, "whoami\n")' then 'read_output(session_id, timeout=5)') clearly tells an agent when this tool is relevant. It also gives practical advice on raising timeout for slow commands. It does not explicitly mention alternatives or when not to use it, but the context is clear.

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