mcp-ssh

Overview Schema Source Related Servers Discussions Admin

execute_command

Run any shell command on a remote SSH server and capture stdout/stderr for diagnostics, log tailing, service control, and one-off tasks.

Instructions

Execute a shell command on the remote SSH server.

Runs any shell command and returns stdout + stderr. Suitable for one-off commands, diagnostics, log tailing, service control, etc.

Args: command: The shell command to execute (e.g., "df -h", "systemctl status nginx"). timeout: Maximum seconds to wait for the command to finish (default 60). host_name: Named host from SSH_HOSTS config; uses default host if omitted.

Returns: Command output (stdout), or combined stdout/stderr on error.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "command": "<command>"
    },
    "name": "execute_command"
  }
}

Input Schema

Name	Required	Description	Default
`command`	Yes
`timeout`	No
`host_name`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.5Aug 7, 2026

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It mentions that output includes stdout and stderr, and that on error they are combined. However, it fails to disclose that executing arbitrary shell commands may have side effects, require permissions, or be irreversible. This is a significant gap for a potentially destructive tool.

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 concise and well-structured, starting with a clear verb sentence, followed by a brief explanation, then an Args section, and finally a Returns section. Every sentence adds value, and the format is easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core functionality and parameters, and the presence of an output schema reduces the need to detail return values. However, it omits important context such as whether an SSH connection must be established first, how the host is selected, or warnings about potential destructive consequences. Given the tool's power, this leaves the description incomplete for an agent deciding whether and how to invoke it.

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?

The schema properties lack descriptions (0% coverage), but the description compensates fully with an 'Args' section that explains each parameter: command (with examples), timeout (max seconds, default 60), and host_name (named host from config). This provides complete, useful semantics beyond the schema.

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 clearly states the tool's function: 'Execute a shell command on the remote SSH server' and 'Runs any shell command and returns stdout + stderr.' This is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like execute_script, though the 'any shell command' wording implies a distinction from script-based execution.

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 description provides clear usage context: 'Suitable for one-off commands, diagnostics, log tailing, service control, etc.' This helps the agent understand when to use it. It does not explicitly state exclusions or mention alternative tools, but the context is sufficient to infer appropriate use cases.

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