cygnus-ssh-mcp

Official

Overview Schema Source Related Servers Discussions Admin

ssh_cmd_output

Retrieve captured stdout or stderr from a previously run SSH command by handle_id, enabling progress checks after timeouts or paging through truncated output without rerunning.

Instructions

Retrieve captured output from a command started with ssh_cmd_run, identified by its handle_id. Useful after an io_timeout/wait_timeout to see progress so far - including output produced after that call returned, since background monitoring keeps collecting it - to page through output a response didn't include in full (ssh_cmd_run returns at most the last ~32 KB of each stream inline and says so via output_truncated/output_note), or to re-inspect an earlier command's output without rerunning it.

stdout and stderr are captured in separate buffers, not interleaved - stream picks which one to retrieve.

The server keeps up to ~2 MB of each stream per command; beyond that the EARLIEST lines are dropped. Asking for a dropped line with start_line gives an error naming the first line still available. For very large output, redirect it to a file (or use ssh_task_launch) and read that instead.

Raises an error if handle_id doesn't exist (e.g. from a previous connection - handles don't survive reconnects).

Returns: A plain list of output lines from the selected stream - not a dict. For total line counts and whether anything was dropped, use ssh_cmd_check_status (output_lines) or ssh_cmd_history.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lines`	No	How many lines to return. Without start_line: the most recent N lines (default 50). With start_line: N lines from there (default 50).
`stream`	No	Which captured stream to retrieve - stdout (default) or stderr. These are NOT interleaved into one combined stream - call this twice (once per stream) if you need both	stdout
`handle_id`	Yes	Command handle ID - the 'id' field from ssh_cmd_run's response
`start_line`	No	Page through the output: return lines starting at this line number (1 = the command's first line). Use it to read what a truncated ssh_cmd_run response didn't include (see its output_note).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.6.1Oct 5, 2026

changedInput schema / properties / handle_id / description

Previous value: -"Command handle ID to retrieve output for"New value: +"Command handle ID - the 'id' field from ssh_cmd_run's response"

changedInput schema / properties / lines / description

Previous value: -"Number of lines to retrieve (None for all)"New value: +"How many lines to return. Without start_line: the most recent N lines (default 50). With start_line: N lines from there (default 50)."

addedInput schema / properties / start_line

Added value: +{
+  "anyOf": [
+    {
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Page through the output: return lines starting at this line number (1 = the command's first line). Use it to read what a truncated ssh_cmd_run response didn't include (see its output_note)."
+}

addedInput schema / properties / stream

Added value: +{
+  "default": "stdout",
+  "description": "Which captured stream to retrieve - stdout (default) or stderr. These are NOT interleaved into one combined stream - call this twice (once per stream) if you need both",
+  "enum": [
+    "stdout",
+    "stderr"
+  ],
+  "type": "string"
+}

First observedv1.3.0May 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden and does so richly: separate non-interleaved stdout/stderr buffers, ~2 MB per-stream retention with earliest lines dropped, an error naming the first available line for dropped requests, a ~32 KB inline truncation limit on ssh_cmd_run, and handles not surviving reconnects.

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?

Front-loaded with the core purpose and useful scoping/alternative guidance in the first two sentences, and clearly sectioned. It is somewhat long, and the explicit 'Returns' block partially restates what the output schema already provides, so a small amount of trimming is possible.

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?

Given 4 params, no annotations, and an available output schema, the description covers limits, error cases, retention behavior, and alternatives thoroughly. An agent has everything needed to call it correctly and interpret its results.

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 description coverage is 100%, so the schema already documents lines, stream, handle_id, and start_line semantics. The description reinforces the stream distinction and line-paging idea but adds little syntax or format detail beyond the schema, matching the baseline 3 when the schema does the heavy lifting.

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+resource ('Retrieve captured output from a command started with ssh_cmd_run, identified by its handle_id') and ties the resource directly to its producing sibling. An agent can distinguish it from ssh_cmd_check_status/ssh_cmd_history, which the description explicitly routes elsewhere.

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?

Gives concrete when-to-use conditions: after an io_timeout/wait_timeout to see progress, to page through output a response didn't include in full, or to re-inspect output without rerunning. It also names alternatives (ssh_cmd_check_status, ssh_cmd_history, ssh_task_launch) for adjacent needs.

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

Deploy Server