What can you do with this server?

The SSH MCP Server enables comprehensive remote server administration via SSH, allowing secure command execution, file transfer, interactive sessions, and operation history management. * Profile & Connection Management: List configured SSH profiles, connect/disconnect from remote servers, and check connection status including uptime. * Command Execution: Execute remote commands, with PTY support for interactive programs and automatic prompt responses (e.g., sudo passwords). Dangerous commands (e.g., rm -rf, mkfs, reboot) require explicit confirmation before execution. * Persistent Shell Sessions: Start, send input to, read output from, and close persistent PTY shell sessions (up to 5 concurrent). * File Operations (SFTP): Upload, download, list directories, read (with optional offset/line-limit), and write remote files. * Operation History & Undo: View a history of all operations during a session and undo reversible file operations (write, upload, download) by record ID. * Security: SSH key-only authentication, host fingerprint verification, local sandbox directory restrictions for file transfers, destructive command detection, and full audit logging with secret redaction.

Which integrations are available for this server?

Provides tools for remote administration of Linux servers via SSH, including command execution, persistent shell sessions, SFTP file transfers, and a safety layer for detecting destructive commands.

How do I use SSH MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SSH MCP Server List the files in /var/www/html on the staging profile" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

SSH MCP Server

by d3v1an

Overview Schema Related Servers Score Discussions

JavaScript

Remote

SSH MCP Server

Node.js TypeScript MCP SDK SSH2 License npm Version

Leer en Español

MCP (Model Context Protocol) server for remote server administration via SSH. Supports multiple profiles, remote command execution, interactive commands (PTY), persistent shell sessions, file transfer (SFTP), destructive command detection with audit logging, and operation history with undo capabilities.

Architecture

General Overview

graph TB
    Client["Claude Desktop<br/>(or any MCP client)"]
    Server["SSH MCP Server"]
    MCP["MCP SDK<br/>(stdio)"]
    Router["Tool Router<br/>(index.ts)"]
    Security["Security Module<br/>- Dangerous cmd detection<br/>- Audit logging"]
    SSH["SSH Client (ssh2)"]
    Exec["exec()<br/>- Commands<br/>- cat (read)"]
    Interactive["exec() + PTY<br/>- Interactive commands<br/>- Auto prompt response"]
    Shell["shell() + PTY<br/>- Persistent sessions<br/>- REPLs / multi-step"]
    SFTP["SFTP (lazy init)<br/>- upload / download<br/>- ls / write / readdir"]
    Remote["Remote Server<br/>(Linux/Unix)"]

    Client -->|"stdio (JSON-RPC)"| Server
    Server --- MCP
    MCP --> Router
    Router --> Security
    Router --> SSH
    SSH --- Exec
    SSH --- Interactive
    SSH --- Shell
    SSH --- SFTP
    SSH -->|"SSH (TCP :22)"| Remote

Connection and Execution Flow

flowchart TD
    Start([Start]) --> ListProfiles["ssh_list_profiles<br/>View available profiles"]
    ListProfiles --> Connect["ssh_connect<br/>(profile name)"]
    Connect -->|Invalid or missing key| Error["Error: privateKeyPath missing<br/>or wrong passphrase"]
    Connect -->|OK| Active["Active Connection<br/>(1 profile at a time)"]

    Active --> ExecBranch["ssh_exec<br/>(command)"]
    Active --> InteractiveBranch["ssh_exec_interactive<br/>(command + auto-responses)"]
    Active --> ShellBranch["Shell Sessions<br/>start / send / read / close"]
    Active --> SFTPBranch["SFTP operations<br/>upload / download<br/>ls / read / write"]
    Active --> StatusBranch["ssh_status<br/>ssh_disconnect"]

    ExecBranch --> DangerCheck{"Dangerous<br/>command?<br/>(regex)"}
    InteractiveBranch --> DangerCheck
    DangerCheck -->|No| Execute["Execute command"]
    DangerCheck -->|Yes| ConfirmCheck{"confirm:<br/>true?"}
    ConfirmCheck -->|Yes| Execute
    ConfirmCheck -->|No| Warning["WARNING<br/>(not executed)"]

    ShellBranch -->|"send (raw:false)"| DangerCheck
    ShellBranch -->|"send (raw:true)"| Execute

    Execute --> Audit["audit.log"]
    SFTPBranch --> Audit
    Warning --> Audit

Security Flow (Dangerous Commands)

flowchart LR
    Input["Command received"] --> Check["isDangerousCommand()<br/>(16 regex patterns)"]
    Check -->|Safe| Exec["Execute command"]
    Check -->|Dangerous| Confirm{"confirm: true?"}
    Confirm -->|Yes| Exec
    Confirm -->|No| Warn["WARNING returned<br/>(command NOT executed)"]
    Exec --> Log["audit.log"]
    Warn --> Log

    subgraph Detected Patterns
        P1["rm -rf /"]
        P2["mkfs.*"]
        P3["dd if="]
        P4["reboot / shutdown / halt"]
        P5["chmod 777 / chown -R"]
        P6["fork bomb"]
        P7["systemctl stop/disable"]
        P8["killall / iptables -F"]
    end

Project Structure

s01_ssh_mcp/
├── src/
│   ├── index.ts        # SSHMCPServer class — tool router, SSH logic, interactive/shell handlers
│   ├── tools.ts        # MCP tool definitions (17 tools, JSON schemas)
│   ├── profiles.ts     # Profile loading + private key file read and passphrase injection from env
│   ├── security.ts     # Dangerous command detection + AuditLogger (secret redaction, 0o600 perms)
│   ├── types.ts        # Interfaces: SSHProfile, AuditEntry, PromptResponse, ShellSession, CommandRecord, ReverseInfo
│   ├── utils.ts        # Pure utilities: formatUptime, padRight, escapeShellArg, stripAnsi
│   └── validation.ts   # Input validation: requireString, optionalString/Boolean/Number, clampTimeout
├── dist/               # Compiled output (generated by tsc)
├── profiles.json       # SSH server configuration (not versioned)
├── profiles.json.example  # Profile template (included in npm package)
├── .env                # Optional key passphrases (not versioned)
├── audit.log           # Audit log (generated at runtime)
├── package.json
└── tsconfig.json

Related MCP server: Windows CLI MCP Server

Setup

1. Server Profiles

Copy profiles.json.example → profiles.json and fill in your values. The file must not be versioned (it is in .gitignore).

Required fields:

Field	Description
`host`	Server IP or hostname
`port`	SSH port (usually `22`)
`username`	SSH username
`privateKeyPath`	Path to the private key file. Supports `~`
`hostFingerprint`	SHA-256 host fingerprint (see below)

Optional fields:

Field	Description	Default
`localSandboxDir`	Local directory where downloads/uploads are allowed. Supports `~`	Process working directory

{
  "production": {
    "host": "192.168.1.100",
    "port": 22,
    "username": "deploy",
    "privateKeyPath": "~/.ssh/id_ed25519_production",
    "hostFingerprint": "SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789abcd",
    "localSandboxDir": "~/mcp-downloads"
  }
}

Get the host fingerprint:

ssh-keyscan -t ed25519 HOST 2>/dev/null | ssh-keygen -lf -
# Output: 256 SHA256:AbCd... host (ED25519)
# Copy the "SHA256:..." part into hostFingerprint

Note: hostFingerprint is the identity of the remote server, not your local key. The command above asks the server for its public key — it does not involve any of your private keys. If you have multiple profiles pointing to the same server with different keys, hostFingerprint will be identical across all of them. Your local key is specified in privateKeyPath.

Important: Password authentication has been removed. Only SSH key authentication is supported. Make sure the remote server has the matching public key in ~/.ssh/authorized_keys and enforce PasswordAuthentication no in sshd_config.

2. Passphrases (optional)

If your private keys are protected with a passphrase, define them in .env:

SSH_PASSPHRASE_PRODUCTION=your_passphrase
SSH_PASSPHRASE_STAGING=your_passphrase

Format: SSH_PASSPHRASE_<PROFILE_NAME_UPPERCASE>. Omit the variable if the key has no passphrase.

3. Build and Run

npm install
npm run build
npm start

4. MCP Configuration (Claude Desktop)

Option A: Using npx (recommended)

No local installation required — just add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "ssh": {
      "command": "npx",
      "args": ["-y", "s01-ssh-mcp"],
      "env": {
        "SSH_PASSPHRASE_PRODUCTION": "your_passphrase_if_any",
        "SSH_PASSPHRASE_STAGING": "your_passphrase_if_any"
      }
    }
  }
}

Option B: Local installation

{
  "mcpServers": {
    "ssh": {
      "command": "node",
      "args": ["/path/to/s01_ssh_mcp/dist/index.js"],
      "env": {
        "SSH_PASSPHRASE_PRODUCTION": "your_passphrase_if_any",
        "SSH_PASSPHRASE_STAGING": "your_passphrase_if_any"
      }
    }
  }
}

Note: You can optionally set SSH_PROFILES_PATH in env to point to a profiles.json in a different location.

Available Tools

Tool	Description	Requires Connection
`ssh_list_profiles`	List configured profiles (includes `privateKeyPath` and `hostFingerprint`; never exposes the key or passphrase)	No
`ssh_connect`	Connect to an SSH profile	No
`ssh_disconnect`	Close the active SSH connection (closes all shell sessions)	Yes
`ssh_status`	Connection status (profile, host, uptime)	Yes
`ssh_exec`	Execute a remote command	Yes
`ssh_exec_interactive`	Execute interactive command with PTY and auto-response to prompts	Yes
`ssh_shell_start`	Start a persistent interactive shell session with PTY	Yes
`ssh_shell_send`	Send input to an active shell session	Yes
`ssh_shell_read`	Read accumulated output from a shell session buffer	Yes
`ssh_shell_close`	Close a shell session and release resources	Yes
`ssh_upload`	Upload a local file to the server (SFTP)	Yes
`ssh_download`	Download a file from the server (SFTP)	Yes
`ssh_ls`	List a remote directory (SFTP)	Yes
`ssh_read_file`	Read remote file contents (supports partial reading with offset/limit)	Yes
`ssh_write_file`	Write content to a remote file (SFTP)	Yes
`ssh_history`	View operation history for the active connection	Yes
`ssh_undo`	Revert a specific operation by record ID	Yes

Tool Parameters

Tool	Parameters	Required
`ssh_connect`	`profile` (string)	Yes
`ssh_exec`	`command` (string), `confirm` (boolean)	`command`
`ssh_exec_interactive`	`command` (string), `responses[]` ({prompt, answer, sensitive}), `timeout` (number), `confirm` (boolean)	`command`
`ssh_shell_start`	`cols` (number, default: 80), `rows` (number, default: 24)	No
`ssh_shell_send`	`sessionId` (string), `input` (string), `raw` (boolean), `timeout` (number), `confirm` (boolean), `sensitive` (boolean)	`sessionId`, `input`
`ssh_shell_read`	`sessionId` (string), `timeout` (number)	`sessionId`
`ssh_shell_close`	`sessionId` (string)	`sessionId`
`ssh_upload`	`localPath` (string), `remotePath` (string)	Both
`ssh_download`	`remotePath` (string), `localPath` (string)	Both
`ssh_ls`	`path` (string, default: home)	No
`ssh_read_file`	`path` (string), `offset` (number, start line 1-based), `limit` (number, max lines)	`path`
`ssh_write_file`	`path` (string), `content` (string)	Both
`ssh_history`	`filter` ("all" \| "reversible" \| "reversed"), `limit` (number)	No
`ssh_undo`	`recordId` (number), `confirm` (boolean)	`recordId`

Operation History & Undo

Every operation executed during an active connection is recorded in memory. This allows reviewing what was done and reverting specific operations.

Reversibility by Operation

Operation	Reversible	Undo Strategy
`ssh_write_file`	Yes	Restores previous content. If file didn't exist, deletes it
`ssh_upload`	Yes	Restores previous remote content. If file didn't exist, deletes it
`ssh_download`	Yes	Restores previous local content. If file didn't exist locally, deletes it
`ssh_exec`	No	Recorded but not auto-reversible
`ssh_exec_interactive`	No	Recorded but not auto-reversible
`ssh_read_file`	N/A	Read-only, nothing to revert
`ssh_ls`	N/A	Read-only, nothing to revert
`ssh_shell_send`	N/A	Cannot revert input sent to an interactive shell

The history is cleared on ssh_connect and ssh_disconnect.

Security

Security Model

This server implements layered security. Each layer has defined boundaries:

Layer	Protects Against	Limitations
SSH key auth	Password brute-force	Does not protect if the key is stolen
Host verification (MITM)	Connecting to impersonated servers	Requires correct `hostFingerprint` setup
Local sandbox	Arbitrary local file read/write/delete via `ssh_download`/`ssh_upload`/`ssh_undo`	Does not apply to remote operations
Dangerous command detection	Accidental destructive commands	Advisory layer, NOT a security barrier. Bypassable via obfuscation, variables, `eval`, or `raw: true` in shell
Audit log redaction	Common secret patterns (password=, token=, Bearer) in logs	Does not detect all possible secret formats

Defense in depth recommendation: The server is only as secure as the remote SSH user. Configure the user with minimal necessary permissions, use restrictive sudoers, and keep PasswordAuthentication no in sshd_config.

Note on raw: true in ssh_shell_send: This mode sends input directly to the shell without any dangerous command validation. This is intentional for advanced use cases (control sequences, internal REPLs). Use with caution.

History & Undo Limitations

History and undo capability are lost when the MCP server restarts (history lives in memory).
Binary files (detected via null byte check) are excluded from undo backup entirely — undo is UTF-8 only.
Undo is not atomic: if the process dies mid-write during restore, the file may be truncated.
Previous content of files larger than 512 KB is not stored — undo will return an error in that case.
History keeps a maximum of 100 entries. Oldest entries are automatically evicted.

Profile Cache

profiles.json is read and validated at server startup. Changes to the file require restarting the MCP server to take effect.

Destructive Command Detection

The following patterns are intercepted and require confirm: true to execute. This applies to ssh_exec, ssh_exec_interactive, and ssh_shell_send (when raw: false):

Note: This detection is an advisory layer, not a security barrier. Do not rely on it as the sole protection against destructive actions.

Pattern	Reason
`rm -rf /`	Recursive rm on system root
`rm -r`, `rm -rf`	Mass file deletion
`mkfs.*`	Filesystem formatting
`dd if=`	Direct disk write
`reboot`, `shutdown`, `halt`, `poweroff`	Server state control
`init 0`, `init 6`	Runlevel change
`chmod 777 /`	Insecure permissions on root
`chown -R`	Mass ownership change
`> /dev/*`	Direct device write
`:(){ :\|:& };:`	Fork bomb
`systemctl stop\|disable\|mask`	System service shutdown
`killall`	Mass process termination
`iptables -F`	Firewall rules flush

Audit Log

All operations are logged to audit.log with the format:

[timestamp] [profile] [tool] [parameters] [RESULT: ok|error]

Example:

[2026-03-04T10:30:00.000Z] [production] [ssh_exec] [ls -la /var/log] [RESULT: ok]
[2026-03-04T10:31:00.000Z] [production] [ssh_upload] [./app.tar.gz -> /tmp/app.tar.gz] [RESULT: ok]

Technical Details

MCP Transport: stdio (JSON-RPC over stdin/stdout)
SSH Connection: One active connection at a time. Attempting to connect to another profile without disconnecting raises an error. Keepalive: 30s interval, max 3 retries, 20s ready timeout.
Host Verification: Every ssh_connect verifies the remote fingerprint via hostHash: "sha256" + hostVerifier. Converts the hex fingerprint from ssh2 to base64 and compares to the SHA256:<base64> value stored in the profile. Connection is rejected if they don't match.
Connection Cleanup: SSH close and end events trigger cleanupState() on unexpected disconnects, clearing all sessions and SFTP state. Intentional disconnects are guarded against double-cleanup.
SFTP: Lazy initialization — created on first file operation use and reused thereafter. Auto-invalidated if the SFTP subsystem closes or errors (sftp.on('close'/'error')).
Interactive Exec: Uses exec() with pty: true for commands requiring interactive input. Supports auto-response to prompts via regex matching. User-provided regex patterns are validated with safe-regex2 before compilation to prevent ReDoS. Settle timeout (2s) detects command completion; global timeout (default 30s) prevents hangs.
Shell Sessions: Uses shell() with PTY for persistent interactive terminals. Up to 5 concurrent sessions stored in a Map<string, ShellSession>. Auto-close after 5 minutes of inactivity. Buffer capped at 1MB. All sessions are closed on ssh_disconnect. ANSI escape codes are stripped from output.
Exec Command Timeout: All internal ssh exec calls (including cat for file reads) race against a 30s timeout. stdout and stderr are capped at 1MB with per-chunk truncation during accumulation. Non-zero exit codes without stderr resolve with an [exit code: N] annotation instead of rejecting (preserves grep/diff behavior). Uses cat -- path and rm -f -- path to protect against filenames starting with -.
Timeout Clamping: User-provided timeouts for ssh_exec_interactive, ssh_shell_send, and ssh_shell_read are clamped to a minimum of 1s and a maximum of 5 minutes.
Input Validation: Centralized in validation.ts. All tool arguments go through typed helpers (requireString, optionalBoolean, etc.) instead of unchecked any casts.
File Reading: Uses ssh exec cat (not SFTP) for text files. Supports partial reading via offset (start line, 1-based) and limit (max lines) using sed -n.
File Writing: Uses SFTP createWriteStream for large file support.
Argument Escaping: Shell escaping with single quotes to prevent command injection.
Audit Logging: Non-blocking — log write failures are silently ignored to avoid disrupting operations. Common secret patterns (password=, token=, Bearer, etc.) are redacted before writing. Log file created with 0o600 permissions (owner read/write only). Responses marked sensitive: true are logged as [REDACTED]. All tool operations are audited, including ssh_ls. Graceful shutdown via beforeExit handler flushes pending writes.
Profile Cache: profiles.json is read and fully validated once at startup (all required fields + key file readable). Changes require restarting the MCP server.
Operation History: All operations are recorded in memory during the active connection. File operations (ssh_write_file, ssh_upload) capture previous content before modifying, enabling undo. ssh_download preserves pre-existing local files via local_file_restore undo type. Binary files (null byte detection) are excluded from undo backup. History capped at 100 entries. previousContent not stored if > 512KB. History is cleared on connect/disconnect.

License

This project is licensed under the MIT License.

Available Tools

17 tools

ssh_connectC

Conecta a un servidor SSH usando un perfil configurado

ParametersJSON Schema

Name	Required	Description	Default
`profile`	Yes	Nombre del perfil del servidor (ej: produccion, staging)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the connection is persistent, if a session is started, or any side effects. The description is too minimal to inform the agent about important aspects like authentication or connection state.

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 a single, efficient sentence that conveys the core purpose with zero waste. It is appropriately sized for a simple tool with one parameter.

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

Completeness2/5

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

Given the tool complexity (one parameter, no output schema), the description is too sparse. It lacks context about the result of the connection, session management, or relation to sibling tools like ssh_shell_start or ssh_exec_interactive. The tool seems to initiate a connection, but the description does not clarify what the agent can expect afterwards.

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?

The input schema has 100% coverage with a description for the 'profile' parameter. The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.

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 action ('Conecta' = connects) and the target resource ('servidor SSH' = SSH server) using a configured profile. It effectively distinguishes from sibling tools like ssh_disconnect, ssh_exec, etc., which have different purposes.

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?

No guidance is provided on when to use this tool versus alternatives. Sibling tools include ssh_exec, ssh_shell_start, and others that might overlap, but the description does not clarify the preferred use case or provide any exclusions.

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

ssh_disconnectA

Cierra la conexión SSH activa

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the action of closing an SSH connection but does not detail side effects (e.g., what happens to processes, or error behavior if no connection exists).

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 a single sentence that is concise and immediately clear. It is front-loaded with the essential 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?

Given zero parameters and no output schema, the description covers the core functionality. It could mention error handling or state requirements, but is mostly complete for a simple disconnect action.

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?

The tool has zero parameters, so the schema already covers 100%. The description does not add additional meaning beyond the name and action, but no param info is needed.

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 description clearly states 'Cierra la conexión SSH activa' (closes the active SSH connection), which is a specific verb-resource pair. It distinguishes from siblings like ssh_connect (opposite action) and ssh_shell_close (closes a shell, not the entire connection).

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

Usage Guidelines3/5

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

The description implies usage through the tool name and action, but does not explicitly state when to use it versus alternatives (e.g., ssh_shell_close) or any prerequisites like needing an active connection.

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

ssh_downloadB

Descarga un archivo del servidor remoto al sistema local via SFTP

ParametersJSON Schema

Name	Required	Description	Default
`remotePath`	Yes	Ruta del archivo en el servidor remoto
`localPath`	Yes	Ruta destino en el sistema local

TDQS

B3.3/5.0

Behavior2/5

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

Without annotations, the description carries full burden but only mentions SFTP protocol. It does not disclose file overwrite behavior, directory creation, error handling, or authentication needs.

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?

Single sentence that efficiently conveys the core action and protocol, with no wasted words.

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?

Adequate for a simple two-parameter tool, but lacks details on error handling, connection requirements, or local file overwrite behavior that would be useful given the sibling context.

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% so baseline is 3. The description adds no extra meaning beyond the purpose; parameter descriptions in schema already cover paths.

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 description clearly states the action (download), the resource (file), and the direction (remote to local) via SFTP, distinguishing it from siblings like ssh_upload and ssh_read_file.

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?

No guidance on when to use this tool versus alternatives like ssh_read_file or ssh_upload, nor any prerequisites (e.g., active connection) or conditions.

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

ssh_execA

Ejecuta un comando en el servidor remoto. Si el comando es destructivo (rm -rf, reboot, etc.) requiere confirm: true para ejecutarse

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	Comando a ejecutar en el servidor remoto
`confirm`	No	Confirmar ejecución de comandos peligrosos. Requerido cuando el comando es detectado como destructivo

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, but the description discloses the destructive behavior and the safeguard (confirm: true). For a command execution tool, this is a key behavioral trait. It does not detail other behaviors like output handling or timeouts, but the description adds value beyond the schema.

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?

The description is a single sentence, efficient and front-loaded. It could be split into two sentences for clarity (purpose, then safety condition), but it contains no unnecessary words.

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?

Given the tool's simplicity (2 parameters, no output schema), the description covers the essential usage and safety. It is complete enough for an agent to understand the tool's purpose and when to use the confirm flag. Minor omissions (output description) are acceptable for such a tool.

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

Parameters4/5

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

Schema description coverage is 100%, so both parameters have individual descriptions. The description adds meaning by explicitly linking 'confirm' to destructive commands, clarifying when it is required. This goes beyond the schema's static description.

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 description clearly states it executes a command on a remote server. The verb 'Ejecuta' (execute) and resource 'servidor remoto' are specific. This tool is distinct from siblings like ssh_exec_interactive or ssh_shell_send, which handle interactive or streaming 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 guidance on using the 'confirm' parameter for destructive commands (rm -rf, reboot). It does not explicitly mention when to prefer this tool over alternatives like ssh_exec_interactive or ssh_shell_send, but the context of command execution versus interactive shell is implied.

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

ssh_exec_interactiveA

Ejecuta un comando interactivo en el servidor remoto con PTY. Permite responder automáticamente a prompts (ej: sudo password, confirmaciones yes/no). Si el comando es destructivo requiere confirm: true

ParametersJSON Schema

Name	Required	Description
`command`	Yes	Comando a ejecutar en el servidor remoto
`responses`	No	Lista de respuestas automáticas a prompts. Cada entrada tiene un regex que detecta el prompt y la respuesta a enviar
`timeout`	No	Timeout global en milisegundos (default: 30000)
`confirm`	No	Confirmar ejecución de comandos peligrosos. Requerido cuando el comando es detectado como destructivo

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description discloses key behaviors: PTY allocation, automatic response mechanism, and the need for confirmation on destructive commands. It does not cover connection prerequisites or error handling, but the core behavioral traits are sufficiently explained.

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 two sentences, front-loading the main purpose and key features. Every sentence provides essential information without redundancy.

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

Completeness2/5

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

The description is missing important context about output behavior (e.g., what is returned after execution), prerequisites (e.g., must be connected to a session), and possible side effects. Given the tool's complexity and lack of output schema or annotations, this is a significant gap.

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

Parameters4/5

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

Schema description coverage is 100%, so parameters are well-documented. The description adds value by explaining the automatic response functionality and the requirement for confirm on destructive commands, which goes beyond the schema's 'Confirmar ejecución de comandos peligrosos'.

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 description clearly states it executes interactive commands with PTY and supports automatic responses to prompts. This differentiates it from sibling tools like ssh_exec (likely non-interactive) and ssh_shell_* (shell sessions). The verb 'Ejecuta' and resource 'comando interactivo' are specific.

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 guidance on when to use this tool (for interactive commands needing responses) and a critical constraint (destructive commands require confirm: true). It does not explicitly list alternatives or when to avoid, but the context implies usage for interactive scenarios.

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

ssh_historyA

Muestra el historial de operaciones ejecutadas durante la conexión activa. Permite filtrar por tipo de operación y limitar resultados

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No	Filtro del historial: 'all' (todas), 'reversible' (solo reversibles), 'reversed' (solo revertidas). Default: 'all'
`limit`	No	Número máximo de registros a retornar (default: 20)

TDQS

A3.9/5.0

Behavior4/5

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

The description indicates a read-only operation ('muestra el historial'), implying no destructive side effects. With no annotations provided, the description adequately conveys the non-destructive nature, though it does not detail return format or session scope beyond 'durante la conexión activa'.

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 (two sentences), front-loaded with the main purpose, and contains no extraneous information.

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?

For a simple list tool with no output schema, the description covers the basic functionality. However, it does not specify what fields are returned in the history entries, which could be important for integration with tools like ssh_undo.

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 parameters are well-described in the schema. The description merely echoes the filtering and limiting capabilities without adding new semantic detail. Baseline 3 applies.

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 description clearly states it shows the history of operations executed during the active connection, with filtering by type and limiting results. This distinguishes it from sibling tools like ssh_exec, ssh_undo, etc.

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

Usage Guidelines3/5

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

The description implicitly conveys usage (viewing history) but does not explicitly state when to use this tool versus alternatives like ssh_undo for reverting operations. No when-not-to-use guidance.

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

ssh_list_profilesA

Lista los perfiles de servidores SSH disponibles (incluye host, port, username y privateKeyPath; nunca expone la llave privada ni la passphrase)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/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. It discloses that profiles include host, port, username, and privateKeyPath, and explicitly asserts security by never exposing the private key or passphrase. This is sufficient for a non-destructive list operation.

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?

A single sentence that is front-loaded with the action and immediately provides key details about the contents and security. No unnecessary words.

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?

Without an output schema, the description explains the return data (host, port, username, privateKeyPath) and security exclusions. It could specify the structure (e.g., array of objects) but is complete enough for an agent to understand what to expect.

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?

There are zero parameters, so the baseline is 4. The description adds value by detailing what information the output contains and what it does not expose, which goes beyond the empty schema.

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 description clearly states the tool lists available SSH profiles and specifies the included fields (host, port, username, privateKeyPath) and what is never exposed (private key or passphrase). This distinguishes it from all sibling tools which perform actions like connect, execute, or file operations.

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 implicitly guides usage as a utility to view available profiles before connecting. While it does not explicitly state when not to use it or mention alternatives, the simple listing nature is self-explanatory and there is no competing tool.

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

ssh_lsB

Lista el contenido de un directorio en el servidor remoto

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Ruta del directorio a listar (default: directorio home)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description should detail behavioral traits. It only says 'lists contents' but does not disclose that it requires an active connection, how output is formatted, or if it has side effects. This is insufficient for a tool with no annotation support.

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 a single, concise sentence with no unnecessary words. It is front-loaded and efficiently communicates the core action.

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?

Given the simple interface (1 optional param, no output schema), the description is minimally adequate. However, it lacks context on required connections and output format, which could be improved for a 1-param tool without annotations.

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%, providing the parameter meaning (path, default home). The description adds no new semantics beyond what the schema already offers, so baseline 3 is appropriate.

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 lists directory contents on a remote server, using a specific verb and resource. However, it does not explicitly differentiate from siblings like ssh_read_file or ssh_exec, though the purpose is implicitly distinct.

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?

No guidance on when to use this tool versus alternatives (e.g., ssh_exec with 'ls' command). Prerequisites like an active SSH connection via ssh_connect are not mentioned.

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

ssh_read_fileA

Lee el contenido de un archivo en el servidor remoto. Soporta lectura parcial con offset/limit

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Ruta del archivo a leer en el servidor remoto
`offset`	No	Línea inicial a leer (base 1, default: desde el inicio del archivo)
`limit`	No	Número máximo de líneas a leer (default: todo el archivo)

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries full burden but only states the tool reads a file and supports partial reading. It does not clarify if the file is modified, authentication requirements, or error behavior. However, the read-only nature is implied, and the offset/limit feature adds some transparency.

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 a single sentence with 13 words, immediately stating the core purpose. It is efficiently written with no filler, earning maximum points for conciseness.

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?

Given three parameters and no output schema, the description covers basic functionality but omits return value details (e.g., format of file content) and potential pitfalls like large file handling. It is adequate but not fully comprehensive.

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%, so parameters are already well-documented via descriptions. The tool description only reiterates the offset/limit feature without adding new meaning beyond the schema, meriting the baseline score.

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 description clearly states the tool reads a file on a remote server and highlights support for partial reading with offset and limit. This specific verb ('lee') and resource ('archivo') distinguishes it clearly from sibling tools like ssh_write_file or ssh_download.

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?

The description provides no guidance on when to use this tool over alternatives, such as comparing it to ssh_download for larger transfers or ssh_exec for processing file content. It fails to mention when partial reading is beneficial or when to avoid this tool.

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

ssh_shell_closeA

Cierra una sesión de shell interactiva y libera recursos

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	ID de la sesión de shell a cerrar

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided. The description only mentions 'libera recursos' (frees resources) but lacks details on destructiveness, side effects, or required permissions.

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 a single, concise sentence with no redundant information, perfectly front-loaded.

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?

For a simple tool with one required parameter and no output schema, the description is adequate but missing context about prerequisites (e.g., an active shell session) and post-conditions.

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 the description adds no extra meaning beyond the schema's parameter description. The schema already describes the 'sessionId' parameter sufficiently.

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 description clearly states the action ('Cierra') and the resource ('sesión de shell interactiva'), explicitly distinguishing it from sibling tools like ssh_shell_start or ssh_disconnect.

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

Usage Guidelines3/5

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

The description implies using this tool after starting a shell session but does not explicitly state when to use it over alternatives or when not to use it.

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

ssh_shell_readA

Lee el output acumulado en el buffer de una sesión de shell. Espera brevemente por output adicional antes de retornar

ParametersJSON Schema

Name	Required	Description	Default
`sessionId`	Yes	ID de la sesión de shell
`timeout`	No	Tiempo en ms para esperar output adicional (default: 2000)

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the core behavior: reading and waiting for additional output (with a default timeout). However, it omits details like the need for an active session, non-destructiveness, or return format, leaving gaps.

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 two concise sentences (20 words) that front-load the primary action and add a secondary behavioral note. Every word is useful, with no redundancy or irrelevant information.

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?

Given no output schema, the description should clarify what is returned. It implies returning the accumulated output but does not specify format or buffer behavior (e.g., clearing). Also lacks mention of prerequisites like an active shell session, making it minimally adequate.

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%, so baseline is 3. The description adds minimal value beyond the schema—it mentions waiting briefly but does not elaborate on parameter usage or constraints that are not already in the parameter descriptions.

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 description explicitly states the tool reads accumulated output from a shell session buffer, using a specific verb and resource. This clearly distinguishes it from sibling tools like ssh_exec, ssh_shell_send, and ssh_shell_close, which have different purposes.

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives. While the context implies it is for reading output after sending commands via ssh_shell_send, no direct guidance or exclusion criteria are provided, making it adequate but not thorough.

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

ssh_shell_sendA

Envía input a una sesión de shell activa. Si raw es false (default), aplica detección de comandos peligrosos. Retorna el output generado tras enviar el input

ParametersJSON Schema

Name	Required	Description
`sessionId`	Yes	ID de la sesión de shell
`input`	Yes	Texto a enviar a la shell (se agrega \n automáticamente si raw es false)
`raw`	No	Si es true, envía el input tal cual sin agregar \n ni aplicar detección de comandos peligrosos (default: false)
`timeout`	No	Tiempo en ms para esperar output después de enviar (default: 2000)
`confirm`	No	Confirmar ejecución de comandos peligrosos. Solo aplica cuando raw es false
`sensitive`	No	Si es true, el input se registra como [REDACTED] en el audit log. Usar cuando se envíen contraseñas u otros secretos

TDQS

A3.6/5.0

Behavior3/5

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

The description discloses key behaviors: raw mode, dangerous command detection, and auto-adding newline. However, it omits details on what happens when dangerous commands are detected (e.g., blocked or requires confirmation), and there are no annotations to supplement. The tool could be destructive, but the description does not fully convey the safety profile.

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 two sentences, front-loaded with the core action, and every sentence provides necessary information. No redundancy or filler.

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?

Given the absence of output schema, the description adequately states that the tool returns output. It covers the essential behavior for a send-input tool with 6 parameters, though error handling and edge cases (e.g., session timeout) are not addressed.

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 describes all parameters. The description adds minimal new meaning, primarily stating the default raw=false and that dangerous detection applies. This aligns with the baseline of 3 for high coverage.

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 sends input to an active shell session, specifying the raw mode and dangerous command detection. However, it does not explicitly differentiate from sibling tools like ssh_exec or ssh_exec_interactive, which could lead to confusion.

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

Usage Guidelines3/5

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

The description implies usage when an active shell session exists, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., ssh_exec for single commands) or when not to use it. No exclusions or prerequisites are mentioned.

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

ssh_shell_startA

Inicia una sesión de shell interactiva persistente con PTY. Útil para REPLs, workflows multi-paso, o login a servicios. Máximo 5 sesiones concurrentes. Auto-cierre tras 5 min de inactividad

ParametersJSON Schema

Name	Required	Description	Default
`cols`	No	Ancho del terminal en columnas (default: 80)
`rows`	No	Alto del terminal en filas (default: 24)

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description discloses important behaviors: persistent PTY, concurrency limit, and auto-close. It does not mention how to obtain the session identifier or error handling, but covers the core lifecycle traits adequately.

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 only two sentences, each serving a clear purpose: one to state what the tool does, another to provide usage context and constraints. No redundant or extraneous information.

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 purpose, limits, and auto-close, but does not mention the return value (e.g., session ID) or how to subsequently interact with the session. Given the absence of an output schema, this omission leaves agents uncertain about what to expect after invocation. For a start tool, more contextual glue to sibling tools (ssh_shell_send, ssh_shell_read) would improve completeness.

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?

Both parameters (cols, rows) are fully documented in the input schema with descriptions and defaults. The tool description adds no additional semantic context beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 description clearly states it initiates a persistent interactive shell session with PTY, and lists specific use cases like REPLs and multi-step workflows. It effectively distinguishes itself from sibling tools that execute single commands (ssh_exec, ssh_exec_interactive).

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 usage context (REPLs, multi-step workflows, login) and constraints (max 5 concurrent sessions, 5-min inactivity auto-close). However, it does not explicitly contrast with alternative tools like ssh_connect or ssh_exec, leaving some ambiguity about when to choose this over others.

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

ssh_statusA

Muestra el estado de la conexión SSH actual (perfil, host, tiempo conectado)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Since no annotations are provided, the description bears the full burden. It discloses what information is shown (profile, host, connection time) and implies a read-only, non-destructive operation. Could mention it has no side effects.

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 a single, front-loaded sentence in Spanish that conveys all essential information without wasted words. It is appropriately sized for a simple status tool.

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?

For a tool with no parameters and no output schema, the description adequately explains what the tool shows. It lists the key fields (profile, host, connection time), making it complete for its simplicity.

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

Parameters4/5

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

The input schema has zero parameters with 100% coverage. The description doesn't need to add parameter meaning. Baseline for 0 params is 4, and it meets that.

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 description clearly states that the tool shows the current SSH connection status, including profile, host, and connection time. It uses a specific verb and resource, distinguishing it from sibling tools like ssh_connect or ssh_exec.

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

Usage Guidelines3/5

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

The description implies usage for checking the SSH connection status but does not explicitly state when to use it or provide alternatives. Context from sibling tools makes the purpose clear, but no direct guidance on when not to use it.

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

ssh_undoA

Revierte una operación específica del historial usando su ID. Solo funciona con operaciones marcadas como reversibles (ssh_write_file, ssh_upload, ssh_download). Requiere confirm: true para ejecutar la reversión

ParametersJSON Schema

Name	Required	Description	Default
`recordId`	Yes	ID del registro de operación a revertir (obtenido de ssh_history)
`confirm`	No	Confirmar la reversión de la operación

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the confirmation requirement and the reversible operation constraint. However, it does not describe the result of reverting (e.g., success/failure response) or what happens if the operation is not reversible. The destructive nature is implied but not stated.

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?

Two sentences that are direct and clear. No extraneous information. Each sentence serves a purpose: first explains what and constraints, second adds requirement.

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 undo tool with 2 parameters, the description covers the essential usage and constraints. The lack of output schema is mitigated by the straightforward nature of undo. Minor gap: does not describe whether the tool returns confirmation or error messages.

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

Parameters4/5

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

Schema coverage is 100% and both parameters have descriptions. The description adds value by stating that confirm must be true for execution, which is not in the schema. It also clarifies that recordId comes from ssh_history, adding context beyond the schema.

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 description clearly states the verb 'revertir' (undo) and the resource 'operación específica del historial' (specific history operation). It distinguishes from sibling tools by specifying the constraint of only working with reversible operations like ssh_write_file, ssh_upload, ssh_download.

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 explicit context: it only works with reversible operations and requires confirm: true to execute. It lists which operations are reversible, giving clear guidance on when to use. It does not explicitly mention when not to use, but the constraints are sufficient.

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

ssh_uploadB

Sube un archivo local al servidor remoto via SFTP

ParametersJSON Schema

Name	Required	Description	Default
`localPath`	Yes	Ruta del archivo local a subir
`remotePath`	Yes	Ruta destino en el servidor remoto

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description only mentions the protocol (SFTP). It does not disclose behaviors like file overwrite rules, error handling, or permission requirements, leaving the agent underinformed.

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?

The description is a single, concise sentence with no superfluous words. It is front-loaded with the core action. However, it is in Spanish while the tool name is in English, which might cause minor confusion.

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

Completeness2/5

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

Given no output schema and no annotations, the description is too minimal. It does not mention prerequisites (e.g., connecting first), success/failure indicators, or limitations, which reduces completeness for a file upload tool.

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%, with clear descriptions for both localPath and remotePath. The description adds no additional semantic value beyond the schema, so baseline score of 3 is appropriate.

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 description clearly states the action (upload), the object (local file), the destination (remote server), and the protocol (SFTP). It effectively distinguishes from the sibling tool ssh_download which performs the opposite operation.

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?

No guidance on when to use this tool versus alternatives like ssh_write_file, or prerequisites such as an active SSH connection. The description lacks context about usage scenarios.

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

ssh_write_fileC

Escribe contenido a un archivo en el servidor remoto

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Ruta del archivo en el servidor remoto
`content`	Yes	Contenido a escribir en el archivo

TDQS

C2.9/5.0

Behavior1/5

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

With no annotations provided, the description carries full responsibility for behavioral transparency. It fails to disclose whether the tool overwrites existing files, creates directories, requires prior connection, or how it handles errors. The minimal description 'writes content to a file' provides no behavioral context.

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?

A single, concise sentence in Spanish. It is front-loaded and to the point. However, it could benefit from slightly more detail without becoming verbose. Still, it avoids unnecessary words.

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

Completeness2/5

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

Given the tool's complexity (2 params, no output schema, no annotations), the description is insufficient for an agent to understand the full context, such as prerequisites (SSH connection), return values, or side effects. Sibling tools like ssh_connect suggest dependencies that are not mentioned.

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 both parameters (path, content) have descriptions. The description adds no extra meaning beyond the schema. Baseline 3 is appropriate as no additional semantic value is provided, but the schema itself is clear.

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 description 'Escribe contenido a un archivo en el servidor remoto' clearly states the action (write) and resource (file on remote server), distinguishing it from sibling tools like ssh_read_file (read), ssh_upload (transfer), and ssh_exec (execute commands).

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?

No guidance on when to use this tool versus alternatives such as ssh_upload or ssh_exec. Does not specify prerequisites like an established SSH connection or scenarios like file overwrite behavior.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

17 tool updatesv0.5.0May 28, 2026
- Addedssh_connect
- Addedssh_disconnect
- Addedssh_download
- Addedssh_exec
- Addedssh_exec_interactive
- Addedssh_history
- Addedssh_list_profiles
- Addedssh_ls
- Addedssh_read_file
- Addedssh_shell_close
- Addedssh_shell_read
- Addedssh_shell_send
- Addedssh_shell_start
- Addedssh_status
- Addedssh_undo
- Addedssh_upload
- Addedssh_write_file
17 tool updatesv0.3.0Apr 30, 2026
- Removedssh_connect
- Removedssh_disconnect
- Removedssh_download
- Removedssh_exec
- Removedssh_exec_interactive
- Removedssh_history
- Removedssh_list_profiles
- Removedssh_ls
- Removedssh_read_file
- Removedssh_shell_close
- Removedssh_shell_read
- Removedssh_shell_send
- Removedssh_shell_start
- Removedssh_status
- Removedssh_undo
- Removedssh_upload
- Removedssh_write_file
17 tool updatesv0.3.1Apr 2, 2026
- First observedssh_connect
- First observedssh_disconnect
- First observedssh_download
- First observedssh_exec
- First observedssh_exec_interactive
- First observedssh_history
- First observedssh_list_profiles
- First observedssh_ls
- First observedssh_read_file
- First observedssh_shell_close
- First observedssh_shell_read
- First observedssh_shell_send
- First observedssh_shell_start
- First observedssh_status
- First observedssh_undo
- First observedssh_upload
- First observedssh_write_file

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Tools are generally distinct, but ssh_exec and ssh_exec_interactive have overlapping purposes, and ssh_shell_send might be confused with ssh_exec for non-interactive commands. Descriptions mitigate this, but some ambiguity remains.

Naming Consistency5/5

All tool names follow 'ssh_' prefix with consistent snake_case and verb_noun pattern. Even compound names like ssh_exec_interactive maintain the convention.

Tool Count5/5

17 tools cover a broad SSH domain (connection, execution, shells, file operations, history) without being excessive. Each tool serves a clear purpose.

Completeness4/5

Covers core SSH operations well, including interactive shells and undo. Missing port forwarding and key management, but these are advanced features not essential for basic SSH control.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

browser-ssh
com.browserssh
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Shell Access File Systems
2
emisarOAuth
dev.emisar
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Cloud Platforms Security Networking & Infrastructure
2354
SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
26
termalin-web A
in.termal
Run commands and read/write files on your servers over Termalin's keyless tunnels (hosted MCP).
Shell Access File Systems
81

Related MCP Servers

SSH MCP Server
Shell Access Command Line File Systems
liang04
A
license
A
quality
D
maintenance
Enables secure SSH connections to multiple remote servers with support for command execution, file transfers (SFTP), directory listing, and both password and key-based authentication.
Updated 7 months ago (2026-02-07 03:59 UTC)
7
MIT
Windows CLI MCP Server
Shell Access Command Line OS Automation
quanticsoul4772
A
license
B
quality
D
maintenance
Enables secure command-line interactions on Windows systems through PowerShell, CMD, and Git Bash, with support for SSH remote connections, SFTP file transfers, system monitoring, and configurable security controls including command blocking and path restrictions.
Updated 3 months ago (2026-06-09 23:58 UTC)
34
2
MIT
SSH MCP Server
Shell Access Command Line OS Automation
kpanuragh
A
license
A
quality
C
maintenance
Enables remote server management through SSH and SFTP, supporting command execution, file transfers, and interactive shell sessions. It allows for multiple concurrent connections using either password or SSH key authentication.
Updated 9 months ago (2025-12-09 14:41 UTC)
11
19
4
MIT
mcp-ssh
Shell Access Command Line OS Automation
atlcomgit
A
license
B
quality
D
maintenance
Enables secure SSH connections to remote servers for executing shell commands and managing active sessions. It supports authentication via passwords or private keys and provides optional host-based access control.
Updated 7 months ago (2026-02-11 02:36 UTC)
4
210
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/d3v1an/ssh-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server