cygnus-ssh-mcp

Official

Overview Schema Source Related Servers Discussions Admin

ssh_cmd_history

Retrieve SSH command execution history with optional stdout and stderr snippets, filterable by pattern and ordered oldest or newest first.

Instructions

Retrieve command execution history with optional output snippets.

Returns: List of dictionaries containing command history, ordered from oldest to newest by default. Each entry contains: - id: Command handle ID - command: Executed command - exit_code: Exit status - start_time: Execution start timestamp - end_time: Execution end timestamp - origin: 'user' for a directly user-requested command, or an internal-plumbing label ('tool_internal', 'connection_probe', 'sudo_probe') for a helper command issued by another tool - parent_tool: Name of the MCP tool that triggered this command, when origin != 'user' - output: Stdout snippet (if include_output=True) - stderr is NOT included here, even for a failed command; see the separate 'stderr' field - stderr: Stderr snippet (if include_output=True) - often the more useful stream for a failed command; retrieved the same way ssh_cmd_output(stream='stderr') would

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Number of history entries to return
`pattern`	No	Filter commands containing this pattern
`reverse`	No	Return in reverse order (newest first)
`output_lines`	No	Number of output lines to include (0 for none)
`include_output`	No	Include command output snippets
`include_internal`	No	Include internal/plumbing commands issued by other tools (e.g. ssh_file_write's sudo mv/chown/chmod dance, ssh_conn_connect's OS-detection probe, ssh_conn_verify_sudo's sudo check, ssh_dir_transfer's temp-archive handling). Set False to see only commands the user directly asked for via ssh_cmd_run/ssh_task_launch.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.6.1Oct 5, 2026

addedInput schema / properties / include_internal

Added value: +{
+  "default": true,
+  "description": "Include internal/plumbing commands issued by other tools (e.g. ssh_file_write's sudo mv/chown/chmod dance, ssh_conn_connect's OS-detection probe, ssh_conn_verify_sudo's sudo check, ssh_dir_transfer's temp-archive handling). Set False to see only commands the user directly asked for via ssh_cmd_run/ssh_task_launch.",
+  "type": "boolean"
+}

First observedv1.3.0May 28, 2026

TDQS

B3.4/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 it does substantial work: it defines the origin taxonomy ('user' vs tool_internal/connection_probe/sudo_probe), explains parent_tool linkage, and flags the non-obvious behavior that stderr is NOT folded into output even for a failed command. It does not cover permissions, connection requirements, or pagination/cost limits.

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 sentence is front-loaded and good, but the bulk of the text is a field-by-field return-value dump that largely duplicates the existing output schema. That padding dilutes the genuinely useful behavioral notes (origin labels, stderr exclusion).

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 the description is not obligated to enumerate return fields, yet it does so thoroughly and adds the origin/parent_tool and stderr semantics an agent needs. Missing pieces are usage routing and connection prerequisites, which are moderate rather than critical given the rich schema.

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 baseline is 3. The description reinforces include_output and the output/stderr split but adds no syntax or semantics beyond the schema's own parameter descriptions (limit, pattern, reverse, output_lines, include_internal are all documented there).

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 opening sentence gives a specific verb and resource ('Retrieve command execution history') and the field breakdown makes clear this is a history-listing tool rather than a single-command output fetch. It implicitly contrasts with ssh_cmd_output (by noting stderr is 'retrieved the same way ssh_cmd_output(stream='stderr') would') and with origin/parent_tool fields, but never explicitly states how it differs from siblings like ssh_cmd_check_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance. The description never says to reach for this tool instead of ssh_cmd_output or ssh_cmd_check_status, nor does it state prerequisites (e.g. that a connection must exist). The only scoping hints live in the schema's include_internal description, not in the tool description itself.

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

Deploy Server