What can you do with this server?

This server enables AI assistants to manage remote Linux machines over SSH, offering 65+ tools across 12 categories with flexible authentication and session management: * Session & Authentication: Connect/disconnect sessions, manage multiple named sessions, save credentials, support password/SSH key auth, credential caching. * Command Execution: Execute shell commands, multi-line bash scripts, and background processes via nohup. * File & Directory Operations: List, create, read, write, delete, move, copy, inspect, change permissions/ownership, find files, check disk usage. * Log & Search: Search files with grep, view head/tail, search system logs (journalctl/log files), find-and-replace with sed. * System Monitoring: Get system info, disk/memory/CPU usage, load averages, list/filter/sort processes, top processes, kill with configurable signals. * Network: Show network info, open ports, test port connectivity, ping, DNS lookup. * Docker Operations: List containers/images, view logs, exec commands inside containers, stats, manage Compose projects, inspect containers. * Package Management: Install/remove/list packages with auto-detection of apt/yum/dnf/pacman, check for updates. * User Management: List users, get user details, current user, login history. * Cron Jobs: List, add, remove cron jobs. * Archive & Compression: Create and extract tar.gz, tar.bz2, zip archives. * Security & Audit: Manage systemd services, view failed login attempts.

Which integrations are available for this server?

Provides tools for managing Docker containers and images on remote Linux servers, including operations like listing containers, starting/stopping containers, pulling images, and more.

How do I use linux-ssh-mcp?

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., "@linux-ssh-mcp check disk usage on web01" 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.

linux-ssh-mcp

by Pawangunjkar

Overview Schema Related Servers Score Discussions

Python

Local

🐧 Linux SSH MCP Server

A powerful Python-based Model Context Protocol (MCP) server that enables AI assistants to manage remote Linux machines over SSH — directly from your chat interface.

Python 3.10+ MCP Protocol License: MIT

📋 Table of Contents

Related MCP server: SSH MCP Server

🌐 Overview

Linux SSH MCP Server is a Python application built with FastMCP and Paramiko that exposes 50+ tools across 12 categories to any MCP-compatible AI assistant. Once connected, your AI can execute commands, manage files, monitor systems, control Docker containers, and much more — all on remote Linux servers, all through natural language in your chat.

How is this different from just "running commands"?

Traditional AI code assistants can run commands on your local machine. This MCP server lets them operate on remote Linux servers — your production boxes, staging environments, cloud VMs, Raspberry Pis, or any machine reachable via SSH. The AI gets structured, typed tools (not raw shell access), meaning it can reason about parameters, handle errors gracefully, and chain operations intelligently.

✨ Key Features

Feature	Description
50+ Specialized Tools	Purpose-built tools across 12 categories — not just raw command execution
Multi-Session Support	Connect to multiple Linux hosts simultaneously with named sessions
Interactive Credentials	If environment variables aren't set, the server prompts for credentials directly in the chat
Credential Caching	Saves credentials in memory and optionally to `~/.ssh-mcp-cache/credentials.json` for reuse
SSH Key Authentication	Supports password auth, key-based auth, or both
Auto-Detection	Automatically detects package managers (apt/yum/dnf/pacman) and adjusts commands
stdio Transport	Runs via stdio using `uv`, the standard transport for MCP servers in AI IDEs
Zero Config Start	Works with environment variables, saved credentials, or interactive prompting — your choice

📥 Quick Install

Option 1: PyPI / uvx (Recommended)

uvx pawangunjkar-linux-ssh-mcp

Cursor / Claude Desktop — add to .cursor/mcp.json:

{
  "mcpServers": {
    "linux-ssh": {
      "command": "uvx",
      "args": ["pawangunjkar-linux-ssh-mcp"],
      "env": {
        "SSH_HOST": "your-host",
        "SSH_PORT": "22",
        "SSH_USERNAME": "ubuntu",
        "SSH_KEY_PATH": "/home/user/.ssh/id_rsa"
      }
    }
  }
}

Option 2: Smithery

npx -y @smithery/cli install linux-ssh-mcp --client cursor

Option 3: Clone from GitHub

git clone https://github.com/Pawangunjkar/linux-ssh-mcp.git
cd linux-ssh-mcp
uv sync
uv run server.py

See PUBLISHING.md for PyPI, Smithery, and directory submission steps.

🏗 Architecture

┌─────────────────────────────────────────────────────────┐
│                     AI IDE (Client)                     │
│          Cursor / Claude Desktop / Antigravity          │
│                  VS Code / Windsurf                     │
└──────────────────────┬──────────────────────────────────┘
                       │  stdio (stdin/stdout)
                       │
┌──────────────────────▼──────────────────────────────────┐
│                  MCP Server (server.py)                 │
│               Built with FastMCP + Python               │
│                                                         │
│  ┌─────────────┐  ┌──────────────┐  ┌───────────────┐  │
│  │  Session     │  │  Credential  │  │  Tool         │  │
│  │  Manager     │  │  Cache       │  │  Registry     │  │
│  │  (multi-host)│  │  (mem+disk)  │  │  (50+ tools)  │  │
│  └──────┬──────┘  └──────────────┘  └───────────────┘  │
└─────────┼───────────────────────────────────────────────┘
          │  SSH (Paramiko)
          │
┌─────────▼───────────────────────────────────────────────┐
│              Remote Linux Server(s)                     │
│         Ubuntu / Debian / CentOS / Arch / etc.          │
└─────────────────────────────────────────────────────────┘

📦 Prerequisites

Before you begin, make sure you have the following installed on your local machine (the machine running the AI IDE):

1. Python 3.10 or higher

Verify your Python version:

python --version
# Should output: Python 3.10.x or higher

If you don't have Python 3.10+, download it from python.org.

2. uv (Python Package Manager by Astral)

uv is a blazing-fast Python package manager that replaces pip, venv, and more. Install it:

# Using pip
pip install uv

# Or using the standalone installer (recommended)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Verify the installation:

uv --version

Why uv? MCP servers launched by AI IDEs use uv run to automatically create virtual environments, install dependencies, and start the server — all in one command. It's the de facto standard for MCP server management.

3. A Remote Linux Server with SSH Access

You need at least one Linux machine you can SSH into. This can be:

A cloud VM (AWS EC2, GCP, Azure, DigitalOcean, etc.)
A local VM (VirtualBox, VMware, WSL2, etc.)
A Raspberry Pi or any other Linux device
A container with SSH enabled

Make sure you have:

The server's hostname or IP address
A valid username and password (or SSH private key)
SSH port (default: 22) is open and accessible from your machine

🚀 Installation & Setup

Step 1: Navigate to the project directory

cd C:\AI_Workspaces\Anti_Workspace\linux-ssh-mcp

Step 2: Install dependencies

You can set up the project using either uv (recommended) or the standard Python tools.

Option A: Using `uv` (Recommended)

uv sync

This single command will:

Create a virtual environment (.venv/) if one doesn't exist
Read pyproject.toml for dependency declarations
Install all required packages (FastMCP, Paramiko, etc.)
Lock dependency versions in uv.lock

Option B: Using Standard Python `venv` & `pip`

# 1. Create a virtual environment
python -m venv .venv

# 2. Activate the virtual environment
# On Windows (PowerShell):
.venv\Scripts\Activate.ps1
# On Windows (CMD):
.venv\Scripts\activate.bat
# On macOS/Linux:
source .venv/bin/activate

# 3. Install the package in editable mode (reads pyproject.toml)
pip install -e .

Step 3: Verify the installation

If using `uv`:

uv run python -c "import mcp; import paramiko; print('All dependencies installed successfully!')"

If using standard `venv` (make sure the virtual environment is activated):

python -c "import mcp; import paramiko; print('All dependencies installed successfully!')"

Step 4 (Optional): Test with MCP Inspector

The MCP Inspector is a browser-based debugging tool that lets you test your server's tools interactively:

uv run mcp dev server.py

This opens a web UI where you can invoke any tool, inspect inputs/outputs, and debug issues before connecting to your AI IDE.

🔌 Configuring Your AI IDE

Each AI IDE reads MCP server configurations from a JSON file. The server is launched automatically when the IDE starts — you do not need to start it manually.

Understanding the Configuration

Every IDE uses the same core JSON structure:

Recommended (PyPI / uvx — no clone required):

{
  "mcpServers": {
    "linux-ssh": {
      "command": "uvx",
      "args": ["pawangunjkar-linux-ssh-mcp"],
      "env": {
        "SSH_HOST": "your-host",
        "SSH_PORT": "22",
        "SSH_USERNAME": "your-username",
        "SSH_KEY_PATH": "/path/to/private/key"
      }
    }
  }
}

Alternative (from source):

{
  "mcpServers": {
    "linux-ssh": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/linux-ssh-mcp", "server.py"],
      "env": {
        "SSH_HOST": "your-host",
        "SSH_PORT": "22",
        "SSH_USERNAME": "your-username",
        "SSH_PASSWORD": "your-password"
      }
    }
  }
}

Field	Purpose
`"linux-ssh"`	A unique name for this MCP server (you can change it)
`"command"`	`uvx` (PyPI) or `uv` (from source)
`"args"`	Package name (`pawangunjkar-linux-ssh-mcp`) or source path + `server.py`
`"env"`	OPTIONAL — Environment variables for default SSH credentials

💡 The env section is entirely optional. If you omit it, the server will interactively ask for credentials in the chat when you first try to connect. This is the recommended approach for security-sensitive environments.

1. 🖱 Cursor

Cursor supports both project-level and global MCP configurations.

Project-Level Configuration (Recommended)

Create the file .cursor/mcp.json in your project root:

your-project/
├── .cursor/
│   └── mcp.json        ← Create this file
├── src/
└── ...

{
  "mcpServers": {
    "linux-ssh": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "C:\\AI_Workspaces\\Anti_Workspace\\linux-ssh-mcp",
        "server.py"
      ],
      "env": {
        "SSH_HOST": "your-host",
        "SSH_PORT": "22",
        "SSH_USERNAME": "your-username",
        "SSH_PASSWORD": "your-password"
      }
    }
  }
}

Global Configuration

To make the MCP server available across all Cursor projects, add it to your global configuration:

~/.cursor/mcp.json

The JSON format is identical to the project-level config above.

Without Environment Variables (Interactive Mode)

If you prefer the server to ask for credentials in the chat:

{
  "mcpServers": {
    "linux-ssh": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "C:\\AI_Workspaces\\Anti_Workspace\\linux-ssh-mcp",
        "server.py"
      ]
    }
  }
}

Verifying in Cursor

Open Cursor
Go to Settings → MCP (or press Ctrl+Shift+P → "MCP")
You should see linux-ssh listed with a green status indicator
If red, check the logs for error details

2. 🤖 Claude Desktop

Configuration File Location

OS	Path
Windows	`%APPDATA%\Claude\claude_desktop_config.json`
macOS	`~/Library/Application Support/Claude/claude_desktop_config.json`

Configuration

Open (or create) the config file and add the MCP server:

{
  "mcpServers": {
    "linux-ssh": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "C:\\AI_Workspaces\\Anti_Workspace\\linux-ssh-mcp",
        "server.py"
      ]
    }
  }
}

Note for macOS users: Replace the Windows path in --directory with the equivalent macOS path where the project is located.

Verifying in Claude Desktop

Restart Claude Desktop after saving the config
Look for the 🔧 (tools) icon in the chat input area
Click it to see the list of available tools from linux-ssh

3. 🌀 Antigravity (Google DeepMind)

Antigravity can be configured via the MCP settings panel within the application.

Configuration

Use the same JSON format as Cursor:

{
  "mcpServers": {
    "linux-ssh": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "C:\\AI_Workspaces\\Anti_Workspace\\linux-ssh-mcp",
        "server.py"
      ],
      "env": {
        "SSH_HOST": "your-host",
        "SSH_USERNAME": "your-username",
        "SSH_PASSWORD": "your-password"
      }
    }
  }
}

Steps

Open Antigravity
Navigate to the MCP settings panel
Add a new MCP server configuration
Paste the JSON above (adjust credentials as needed)
Save and restart if prompted

4. 💻 VS Code with Continue / Cline

Continue Extension

Add the MCP server to .continue/config.json in your project or home directory:

{
  "mcpServers": {
    "linux-ssh": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "C:\\AI_Workspaces\\Anti_Workspace\\linux-ssh-mcp",
        "server.py"
      ]
    }
  }
}

Cline Extension

Open VS Code
Open Cline's settings (click the gear icon in the Cline sidebar)
Navigate to the MCP Servers section
Add a new server with the same command and args format

5. 🏄 Windsurf

Configuration File Location

~/.codeium/windsurf/mcp_config.json

Configuration

{
  "mcpServers": {
    "linux-ssh": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "C:\\AI_Workspaces\\Anti_Workspace\\linux-ssh-mcp",
        "server.py"
      ],
      "env": {
        "SSH_HOST": "your-host",
        "SSH_USERNAME": "your-username",
        "SSH_PASSWORD": "your-password"
      }
    }
  }
}

Steps

Open (or create) the file at ~/.codeium/windsurf/mcp_config.json
Add the configuration above
Restart Windsurf to pick up the changes

⚡ How It Works

Startup Flow

1. AI IDE starts
        │
2. Reads mcp.json / config file
        │
3. Runs: uv run --directory <path> server.py
        │
4. uv automatically:
   ├── Creates .venv if needed
   ├── Installs dependencies from pyproject.toml
   └── Launches server.py
        │
5. server.py initializes FastMCP
   ├── Registers all 50+ tools
   ├── Reads SSH_* environment variables (if set)
   └── Loads cached credentials (if available)
        │
6. Server communicates via stdio (stdin/stdout)
        │
7. AI IDE discovers tools and makes them available in chat

Connection Flow

User: "Connect to my production server at 10.0.1.50"
        │
AI calls: ssh_connect(host='10.0.1.50')
        │
        ├── ENV vars set? → Uses SSH_USERNAME / SSH_PASSWORD
        ├── Cached creds? → Uses saved credentials
        └── Neither?      → Prompts user in chat for username/password
                │
        SSH connection established → Session "default" created
        │
User: "Show me disk usage"
        │
AI calls: ssh_disk_usage(session_name='default')
        │
Returns: Formatted df -h output

For Manual Testing / Debugging

# Open the MCP Inspector (browser-based tool debugger)
uv run mcp dev server.py

The Inspector lets you:

See all registered tools and their schemas
Invoke tools with custom parameters
Inspect raw JSON responses
Debug connection issues

🔐 Environment Variables

All environment variables are optional. If not set, the server will either use defaults or prompt interactively.

Variable	Required	Default	Description
`SSH_HOST`	No	—	Hostname or IP address of the remote Linux server. If not set, you must provide it when calling `ssh_connect`.
`SSH_PORT`	No	`22`	SSH port number. Only change this if your server uses a non-standard SSH port.
`SSH_USERNAME`	No	`root`	SSH username for authentication.
`SSH_PASSWORD`	No	—	SSH password for password-based authentication. Mutually optional with `SSH_KEY_PATH`.
`SSH_KEY_PATH`	No	—	Absolute path to an SSH private key file (e.g., `C:\Users\pawan\.ssh\id_rsa`). Used for key-based authentication.
`SSH_MCP_CACHE_DIR`	No	`~/.ssh-mcp-cache`	Directory where credential cache files are stored. The server creates this directory automatically if it doesn't exist.

Authentication Priority

When connecting, the server checks for credentials in this order:

Explicit parameters passed to ssh_connect (highest priority)
Environment variables (SSH_HOST, SSH_USERNAME, etc.)
Cached credentials from ~/.ssh-mcp-cache/credentials.json
Interactive prompt — asks the user in chat (lowest priority / fallback)

📖 Complete Tool Reference

This section documents every tool exposed by the MCP server. All tools return structured responses with clear success/error indicators.

Category 1: Session & Authentication (6 tools)

These tools manage SSH connections, sessions, and credential storage.

🔧 `ssh_connect`

Connect to a remote Linux host and create a named session.

Establishes an SSH connection to the specified host. Multiple simultaneous connections are supported via named sessions. If credentials are not provided as parameters, the server falls back to environment variables, then cached credentials, then interactive prompting.

Parameter	Type	Required	Default	Description
`host`	`str`	Yes*	—	Hostname or IP address of the remote server. *Optional if `SSH_HOST` env var is set.
`username`	`str`	No	`'root'`	SSH username.
`password`	`str`	No	—	SSH password. Either `password` or `key_path` should be provided.
`key_path`	`str`	No	—	Path to SSH private key file.
`port`	`int`	No	`22`	SSH port number.
`session_name`	`str`	No	`'default'`	A unique name for this session. Use different names to manage multiple connections.

Examples:

# Basic connection with password
ssh_connect(host='192.168.1.100', username='admin', password='s3cret')

# Connection with SSH key
ssh_connect(host='10.0.1.50', username='deploy', key_path='/home/user/.ssh/id_rsa')

# Named session for production server
ssh_connect(host='prod.example.com', username='admin', password='s3cret', session_name='prod')

# Named session for staging server (simultaneously)
ssh_connect(host='staging.example.com', username='admin', password='s3cret', session_name='staging')

# Using non-standard port
ssh_connect(host='bastion.example.com', port=2222, username='jump', key_path='/keys/bastion.pem')

Returns: Confirmation message with session name, connected host, and server OS info.

🔧 `ssh_disconnect`

Disconnect a specific SSH session.

Gracefully closes the SSH connection for the named session and frees associated resources.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Name of the session to disconnect.

Examples:

# Disconnect the default session
ssh_disconnect()

# Disconnect a named session
ssh_disconnect(session_name='prod')

Returns: Confirmation that the session was disconnected.

🔧 `ssh_disconnect_all`

Disconnect all active SSH sessions.

Iterates through all active sessions and disconnects each one. Useful for cleanup.

Parameter	Type	Required	Default	Description
(none)	—	—	—	This tool takes no parameters.

Example:

ssh_disconnect_all()

Returns: Summary of how many sessions were disconnected and their names.

🔧 `ssh_list_sessions`

List all active SSH sessions with connection details.

Provides a comprehensive overview of all currently active sessions including connection status, hostname, uptime, and the number of commands executed in each session.

Parameter	Type	Required	Default	Description
(none)	—	—	—	This tool takes no parameters.

Example:

ssh_list_sessions()

Returns: A formatted table/list with:

Session name
Connected host and port
Username
Connection status (active/disconnected)
Uptime (how long the session has been active)
Number of commands executed

🔧 `ssh_save_credentials`

Save SSH credentials for future reuse.

Persists credentials to disk at ~/.ssh-mcp-cache/credentials.json. Saved credentials are automatically loaded on server startup and can be used when connecting to a host without explicitly providing credentials. The credential file is created with restricted permissions (600) for security.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Name to identify these saved credentials.
`host`	`str`	Yes	—	Hostname or IP address.
`username`	`str`	No	`'root'`	SSH username.
`password`	`str`	No	—	SSH password.
`key_path`	`str`	No	—	Path to SSH private key.
`port`	`int`	No	`22`	SSH port number.

Example:

ssh_save_credentials(
    session_name='prod',
    host='prod.example.com',
    username='deploy',
    key_path='/home/user/.ssh/prod_key',
    port=22
)

Returns: Confirmation that credentials were saved and the file path.

🔧 `ssh_list_saved_credentials`

List all saved credentials.

Displays all credentials stored in the cache file. Passwords are masked for security (only the first and last characters are shown).

Parameter	Type	Required	Default	Description
(none)	—	—	—	This tool takes no parameters.

Example:

ssh_list_saved_credentials()

Returns: A formatted list of saved credentials with:

Session/credential name
Host and port
Username
Password (masked, e.g., s****t)
Key path (if set)

Category 2: Command Execution (3 tools)

General-purpose command execution tools for running anything on the remote host.

🔧 `ssh_execute`

Execute any shell command on the remote host.

The most versatile tool — runs a single shell command and returns stdout, stderr, and the exit code. Use this for any command not covered by a specialized tool.

Parameter	Type	Required	Default	Description
`command`	`str`	Yes	—	The shell command to execute.
`session_name`	`str`	No	`'default'`	Session to execute on.
`timeout`	`int`	No	`30`	Maximum execution time in seconds.

Examples:

# Simple command
ssh_execute(command='whoami')

# Command with timeout
ssh_execute(command='find / -name "*.log" -size +100M', timeout=120)

# Execute on a specific session
ssh_execute(command='uptime', session_name='prod')

# Piped commands
ssh_execute(command='cat /var/log/syslog | grep ERROR | tail -20')

Returns: An object containing:

stdout — Standard output of the command
stderr — Standard error output (if any)
exit_code — Exit code (0 = success)

🔧 `ssh_execute_script`

Execute a multi-line bash script on the remote host.

Uploads and runs a complete bash script. Useful for complex operations that span multiple commands with control flow (if/else, loops, etc.).

Parameter	Type	Required	Default	Description
`script`	`str`	Yes	—	Multi-line bash script content.
`session_name`	`str`	No	`'default'`	Session to execute on.
`timeout`	`int`	No	`30`	Maximum execution time in seconds.

Example:

ssh_execute_script(script="""
#!/bin/bash
set -e

echo "=== System Health Check ==="
echo ""
echo "Hostname: $(hostname)"
echo "Uptime: $(uptime -p)"
echo "Kernel: $(uname -r)"
echo ""
echo "=== Disk Usage ==="
df -h | grep -E '^/dev'
echo ""
echo "=== Memory ==="
free -h
echo ""
echo "=== Top 5 CPU Processes ==="
ps aux --sort=-%cpu | head -6
""", timeout=60)

Returns: Combined output from the script execution with exit code.

🔧 `ssh_execute_background`

Run a command in the background using nohup.

Launches a long-running command that persists even after the SSH session ends. Output is redirected to a log file.

Parameter	Type	Required	Default	Description
`command`	`str`	Yes	—	The command to run in the background.
`log_file`	`str`	No	`/tmp/bg_<timestamp>.log`	Path to redirect stdout/stderr.
`session_name`	`str`	No	`'default'`	Session to execute on.

Examples:

# Run a backup in the background
ssh_execute_background(
    command='tar czf /backups/full-backup-$(date +%Y%m%d).tar.gz /var/www',
    log_file='/var/log/backup.log'
)

# Start a long-running data processing job
ssh_execute_background(command='python3 /scripts/process_data.py --all')

Returns: Confirmation with the PID of the background process and the log file path.

Category 3: File & Directory Operations (12 tools)

Comprehensive file management capabilities — browse, read, write, copy, move, delete, search, and manage permissions.

🔧 `ssh_list_directory`

List the contents of a directory (equivalent to ls -la).

Parameter	Type	Required	Default	Description
`path`	`str`	No	`'/'`	Directory path to list.
`session_name`	`str`	No	`'default'`	Session to use.
`show_hidden`	`bool`	No	`True`	Whether to include hidden files (dotfiles).

Examples:

# List root directory
ssh_list_directory(path='/')

# List home directory without hidden files
ssh_list_directory(path='/home/admin', show_hidden=False)

# List on a specific session
ssh_list_directory(path='/var/www', session_name='prod')

Returns: Formatted directory listing with permissions, owner, group, size, modification date, and filename.

🔧 `ssh_create_directory`

Create a directory, including any necessary parent directories (equivalent to mkdir -p).

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	Directory path to create.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

# Creates /var/www/myapp/static/images and all parents
ssh_create_directory(path='/var/www/myapp/static/images')

🔧 `ssh_read_file`

Read the contents of a file on the remote server.

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	File path to read.
`session_name`	`str`	No	`'default'`	Session to use.
`max_lines`	`int`	No	—	Maximum number of lines to read. If omitted, reads the entire file.

Examples:

# Read entire file
ssh_read_file(path='/etc/nginx/nginx.conf')

# Read first 50 lines of a large file
ssh_read_file(path='/var/log/syslog', max_lines=50)

🔧 `ssh_write_file`

Write content to a file. Creates the file if it doesn't exist, or overwrites/appends to it.

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	File path to write to.
`content`	`str`	Yes	—	Content to write.
`session_name`	`str`	No	`'default'`	Session to use.
`append`	`bool`	No	`False`	If `True`, appends to the file instead of overwriting.

Examples:

# Write a new config file
ssh_write_file(path='/etc/myapp/config.yml', content="""
database:
  host: localhost
  port: 5432
  name: myapp_prod
""")

# Append a line to a file
ssh_write_file(path='/etc/hosts', content='10.0.1.50 api.internal\n', append=True)

🔧 `ssh_delete`

Delete a file or directory.

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	Path to delete.
`session_name`	`str`	No	`'default'`	Session to use.
`recursive`	`bool`	No	`False`	If `True`, deletes directories recursively (`rm -rf`). Required for non-empty directories.

Examples:

# Delete a single file
ssh_delete(path='/tmp/old-backup.tar.gz')

# Delete a directory and all its contents
ssh_delete(path='/var/www/old-site', recursive=True)

⚠️ Warning: Recursive delete is permanent. There is no recycle bin on Linux.

🔧 `ssh_move`

Move or rename a file or directory.

Parameter	Type	Required	Default	Description
`source`	`str`	Yes	—	Source path.
`destination`	`str`	Yes	—	Destination path.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

# Rename a file
ssh_move(source='/var/www/index.html', destination='/var/www/index.html.bak')

# Move a directory
ssh_move(source='/tmp/release-v2', destination='/var/www/app')

🔧 `ssh_copy`

Copy a file or directory.

Parameter	Type	Required	Default	Description
`source`	`str`	Yes	—	Source path.
`destination`	`str`	Yes	—	Destination path.
`session_name`	`str`	No	`'default'`	Session to use.
`recursive`	`bool`	No	`False`	If `True`, copies directories recursively (`cp -r`).

Example:

# Copy a file
ssh_copy(source='/etc/nginx/nginx.conf', destination='/etc/nginx/nginx.conf.bak')

# Copy a directory
ssh_copy(source='/var/www/app', destination='/var/www/app-backup', recursive=True)

🔧 `ssh_file_info`

Get detailed information about a file or directory (equivalent to stat).

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	Path to inspect.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_file_info(path='/var/log/syslog')

Returns: File type, size, permissions, owner, group, creation time, modification time, access time, inode, and link count.

🔧 `ssh_file_permissions`

Change file or directory permissions (equivalent to chmod).

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	Path to modify.
`permissions`	`str`	Yes	—	Permission string in octal format (e.g., `'755'`, `'644'`, `'600'`).
`session_name`	`str`	No	`'default'`	Session to use.
`recursive`	`bool`	No	`False`	If `True`, applies permissions recursively.

Examples:

# Make a script executable
ssh_file_permissions(path='/opt/scripts/deploy.sh', permissions='755')

# Secure a private key file
ssh_file_permissions(path='/home/admin/.ssh/id_rsa', permissions='600')

# Recursively set directory permissions
ssh_file_permissions(path='/var/www/html', permissions='755', recursive=True)

🔧 `ssh_change_owner`

Change file or directory ownership (equivalent to chown).

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	Path to modify.
`owner`	`str`	Yes	—	New owner username.
`group`	`str`	No	—	New group name. If omitted, only the owner is changed.
`session_name`	`str`	No	`'default'`	Session to use.
`recursive`	`bool`	No	`False`	If `True`, applies ownership change recursively.

Examples:

# Change owner
ssh_change_owner(path='/var/www/html', owner='www-data')

# Change owner and group
ssh_change_owner(path='/var/www/html', owner='www-data', group='www-data', recursive=True)

🔧 `ssh_find_files`

Search for files and directories with flexible filters (equivalent to find).

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	Starting directory for the search.
`name`	`str`	No	—	Filename pattern (supports wildcards, e.g., `'.log'`, `'config'`).
`type`	`str`	No	—	Filter by type: `'f'` for files only, `'d'` for directories only.
`size`	`str`	No	—	Filter by size (e.g., `'+100M'` for files over 100MB, `'-1k'` for files under 1KB).
`modified_within`	`str`	No	—	Find files modified within a timeframe (e.g., `'7'` for 7 days, `'1'` for 1 day).
`session_name`	`str`	No	`'default'`	Session to use.

Examples:

# Find all .log files in /var/log
ssh_find_files(path='/var/log', name='*.log', type='f')

# Find large files over 500MB
ssh_find_files(path='/', size='+500M', type='f')

# Find recently modified config files
ssh_find_files(path='/etc', name='*.conf', modified_within='7')

# Find empty directories
ssh_find_files(path='/tmp', type='d')

🔧 `ssh_disk_file_usage`

Show disk usage for a specific file or directory (equivalent to du -sh).

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	Path to check.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_disk_file_usage(path='/var/log')
# Returns: "2.3G    /var/log"

Category 4: Log & Search (5 tools)

Tools for searching through files, viewing logs, and performing text replacements.

🔧 `ssh_search_in_files`

Search for text patterns within files (equivalent to grep).

Parameter	Type	Required	Default	Description
`pattern`	`str`	Yes	—	Text or regex pattern to search for.
`path`	`str`	Yes	—	File or directory path to search in.
`session_name`	`str`	No	`'default'`	Session to use.
`case_insensitive`	`bool`	No	`False`	If `True`, performs case-insensitive matching.
`regex`	`bool`	No	`False`	If `True`, treats the pattern as a regular expression.

Examples:

# Search for errors in a log file
ssh_search_in_files(pattern='ERROR', path='/var/log/app.log')

# Case-insensitive search across a directory
ssh_search_in_files(pattern='database', path='/etc/myapp/', case_insensitive=True)

# Regex search for IP addresses
ssh_search_in_files(pattern=r'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}', path='/var/log/auth.log', regex=True)

🔧 `ssh_tail_file`

View the last N lines of a file (equivalent to tail -n).

Ideal for checking recent log entries.

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	File path to tail.
`lines`	`int`	No	`50`	Number of lines to show from the end.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

# View last 100 lines of syslog
ssh_tail_file(path='/var/log/syslog', lines=100)

🔧 `ssh_head_file`

View the first N lines of a file (equivalent to head -n).

Useful for inspecting file headers, CSV column names, or configuration file structures.

Parameter	Type	Required	Default	Description
`path`	`str`	Yes	—	File path to read from.
`lines`	`int`	No	`50`	Number of lines to show from the beginning.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

# View first 20 lines of a CSV file
ssh_head_file(path='/data/export.csv', lines=20)

🔧 `ssh_search_logs`

Search through system logs using journalctl or grep.

Provides a higher-level interface for log searching that works with both systemd journal and traditional log files.

Parameter	Type	Required	Default	Description
`pattern`	`str`	Yes	—	Text pattern to search for in logs.
`log_path`	`str`	No	—	Specific log file to search. If omitted, searches the systemd journal.
`session_name`	`str`	No	`'default'`	Session to use.
`since`	`str`	No	—	Time filter (e.g., `'1 hour ago'`, `'today'`, `'2024-01-15'`). Only works with `journalctl`.

Examples:

# Search systemd journal for SSH errors
ssh_search_logs(pattern='sshd', since='1 hour ago')

# Search a specific log file
ssh_search_logs(pattern='OutOfMemory', log_path='/var/log/app/error.log')

# Search for recent kernel errors
ssh_search_logs(pattern='error', since='today')

🔧 `ssh_sed_replace`

Find and replace text in a file using sed.

Parameter	Type	Required	Default	Description
`file_path`	`str`	Yes	—	Path to the file to modify.
`find`	`str`	Yes	—	Text or pattern to find.
`replace`	`str`	Yes	—	Replacement text.
`session_name`	`str`	No	`'default'`	Session to use.
`backup`	`bool`	No	`True`	If `True`, creates a backup of the original file (`.bak` extension).

Examples:

# Update a port in a config file
ssh_sed_replace(
    file_path='/etc/myapp/config.yml',
    find='port: 3000',
    replace='port: 8080'
)

# Replace without backup
ssh_sed_replace(
    file_path='/tmp/test.txt',
    find='old_value',
    replace='new_value',
    backup=False
)

Category 5: System Monitoring (8 tools)

Monitor system resources, processes, and performance metrics.

🔧 `ssh_system_info`

Get a comprehensive system summary.

Returns a consolidated overview of the entire system in one call.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_system_info()

Returns: Hostname, OS/distro, kernel version, architecture, CPU info, total/used memory, disk usage, uptime, load averages, and network interfaces.

🔧 `ssh_disk_usage`

Show disk space usage for all mounted filesystems (equivalent to df -h).

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_disk_usage()

Returns: Formatted table with filesystem, size, used, available, use%, and mount point for each partition.

🔧 `ssh_memory_usage`

Show memory and swap usage (equivalent to free -h).

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_memory_usage()

Returns: Total, used, free, shared, buff/cache, and available memory along with swap usage.

🔧 `ssh_cpu_info`

Get CPU details and current load.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_cpu_info()

Returns: CPU model, number of cores/threads, clock speed, architecture, and current load averages (1/5/15 minutes).

🔧 `ssh_process_list`

List running processes (equivalent to ps aux) with optional filtering and sorting.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.
`filter_pattern`	`str`	No	—	Filter processes by name pattern (e.g., `'nginx'`, `'python'`).
`sort_by`	`str`	No	—	Sort by `'cpu'` or `'mem'`.

Examples:

# List all processes
ssh_process_list()

# Find all Python processes
ssh_process_list(filter_pattern='python')

# List processes sorted by memory usage
ssh_process_list(sort_by='mem')

🔧 `ssh_top_processes`

Show the top N processes by CPU or memory consumption.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.
`count`	`int`	No	`10`	Number of top processes to show.
`sort_by`	`str`	No	`'cpu'`	Sort by `'cpu'` or `'mem'`.

Example:

# Top 5 memory-hungry processes
ssh_top_processes(count=5, sort_by='mem')

🔧 `ssh_kill_process`

Kill a process by its PID.

Parameter	Type	Required	Default	Description
`pid`	`int`	Yes	—	Process ID to kill.
`session_name`	`str`	No	`'default'`	Session to use.
`signal`	`str`	No	`'TERM'`	Signal to send. Common values: `'TERM'` (graceful), `'KILL'` (force), `'HUP'` (reload).

Examples:

# Gracefully terminate a process
ssh_kill_process(pid=12345)

# Force kill a stuck process
ssh_kill_process(pid=12345, signal='KILL')

# Send HUP to reload config (e.g., nginx)
ssh_kill_process(pid=9876, signal='HUP')

🔧 `ssh_system_load`

Get current system load averages.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_system_load()

Returns: 1-minute, 5-minute, and 15-minute load averages along with the number of CPU cores for context.

Category 6: Network (5 tools)

Network diagnostics and information tools.

🔧 `ssh_network_info`

Show all network interfaces and their IP addresses.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_network_info()

Returns: Interface names, IPv4/IPv6 addresses, MAC addresses, and status (UP/DOWN).

🔧 `ssh_open_ports`

List all open/listening ports (equivalent to ss -tlnp).

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_open_ports()

Returns: Protocol, local address, port, and the process/PID listening on each port.

🔧 `ssh_check_port`

Test if a specific port is reachable from the remote server.

Useful for verifying firewall rules, checking if a service is accessible, or testing connectivity between servers.

Parameter	Type	Required	Default	Description
`host`	`str`	Yes	—	Target hostname or IP to test.
`port`	`int`	Yes	—	Port number to test.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

# Check if database port is reachable
ssh_check_port(host='db.internal', port=5432)

# Check if external API is accessible
ssh_check_port(host='api.example.com', port=443)

🔧 `ssh_ping`

Ping a host from the remote server.

Parameter	Type	Required	Default	Description
`target`	`str`	Yes	—	Hostname or IP to ping.
`count`	`int`	No	`4`	Number of ping packets to send.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_ping(target='8.8.8.8', count=3)

Returns: Ping statistics including round-trip times (min/avg/max) and packet loss percentage.

🔧 `ssh_dns_lookup`

Perform DNS lookup for a domain (equivalent to dig or nslookup).

Parameter	Type	Required	Default	Description
`domain`	`str`	Yes	—	Domain name to look up.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_dns_lookup(domain='example.com')

Returns: DNS records including A, AAAA, MX, NS, and CNAME records (where available).

Category 7: Docker Operations (7 tools)

Manage Docker containers, images, and compose stacks on the remote host.

🔧 `ssh_docker_ps`

List Docker containers.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.
`all`	`bool`	No	`False`	If `True`, shows all containers (including stopped). Default shows only running.

Examples:

# List running containers
ssh_docker_ps()

# List all containers (including stopped)
ssh_docker_ps(all=True)

🔧 `ssh_docker_logs`

View logs from a Docker container.

Parameter	Type	Required	Default	Description
`container`	`str`	Yes	—	Container name or ID.
`session_name`	`str`	No	`'default'`	Session to use.
`lines`	`int`	No	`100`	Number of log lines to retrieve.

Example:

ssh_docker_logs(container='nginx-proxy', lines=50)

🔧 `ssh_docker_exec`

Execute a command inside a running Docker container.

Parameter	Type	Required	Default	Description
`container`	`str`	Yes	—	Container name or ID.
`command`	`str`	Yes	—	Command to execute inside the container.
`session_name`	`str`	No	`'default'`	Session to use.

Examples:

# Check nginx config inside container
ssh_docker_exec(container='nginx', command='nginx -t')

# List files in a container
ssh_docker_exec(container='myapp', command='ls -la /app')

# Check environment variables
ssh_docker_exec(container='myapp', command='env')

🔧 `ssh_docker_images`

List all Docker images on the remote host.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_docker_images()

Returns: Repository, tag, image ID, creation date, and size for each image.

🔧 `ssh_docker_stats`

Show real-time resource usage statistics for running containers.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_docker_stats()

Returns: CPU %, memory usage/limit, memory %, network I/O, and block I/O for each running container.

🔧 `ssh_docker_compose`

Run Docker Compose commands on a compose project.

Parameter	Type	Required	Default	Description
`action`	`str`	Yes	—	Compose action: `'up'`, `'down'`, `'restart'`, `'ps'`, or `'logs'`.
`path`	`str`	Yes	—	Path to the `docker-compose.yml` file or its parent directory.
`session_name`	`str`	No	`'default'`	Session to use.

Examples:

# Start services in detached mode
ssh_docker_compose(action='up', path='/opt/myapp/docker-compose.yml')

# Check running services
ssh_docker_compose(action='ps', path='/opt/myapp/')

# Restart all services
ssh_docker_compose(action='restart', path='/opt/myapp/')

# Bring everything down
ssh_docker_compose(action='down', path='/opt/myapp/')

# View compose logs
ssh_docker_compose(action='logs', path='/opt/myapp/')

🔧 `ssh_docker_inspect`

Inspect a Docker container's configuration and state.

Parameter	Type	Required	Default	Description
`container`	`str`	Yes	—	Container name or ID.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_docker_inspect(container='redis-cache')

Returns: Detailed JSON output including container config, network settings, mount points, environment variables, and state information.

Category 8: Package Management (4 tools)

Install, remove, and manage system packages. Auto-detects the package manager on the remote system:

Distro Family	Package Manager
Debian / Ubuntu	`apt`
RHEL / CentOS / Fedora	`yum` or `dnf`
Arch Linux	`pacman`

🔧 `ssh_install_package`

Install a system package.

Parameter	Type	Required	Default	Description
`package`	`str`	Yes	—	Package name to install (e.g., `'nginx'`, `'htop'`, `'git'`).
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_install_package(package='nginx')
# Auto-detects: runs "apt install -y nginx" on Ubuntu, "yum install -y nginx" on CentOS, etc.

🔧 `ssh_remove_package`

Remove/uninstall a system package.

Parameter	Type	Required	Default	Description
`package`	`str`	Yes	—	Package name to remove.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_remove_package(package='apache2')

🔧 `ssh_list_packages`

List installed packages with optional filtering.

Parameter	Type	Required	Default	Description
`filter`	`str`	No	—	Filter pattern to search for (e.g., `'python'`, `'libssl'`).
`session_name`	`str`	No	`'default'`	Session to use.

Examples:

# List all installed packages
ssh_list_packages()

# List only Python-related packages
ssh_list_packages(filter='python')

🔧 `ssh_check_updates`

Check for available package updates.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_check_updates()

Returns: List of packages with available updates, including current and available versions.

Category 9: User Management (4 tools)

View and inspect user accounts and login history.

🔧 `ssh_list_users`

List all user accounts on the system.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_list_users()

Returns: Username, UID, GID, home directory, and shell for each user.

🔧 `ssh_user_info`

Get detailed information about a specific user.

Parameter	Type	Required	Default	Description
`username`	`str`	Yes	—	Username to look up.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_user_info(username='deploy')

Returns: Username, UID, GID, groups (primary and supplementary), home directory, shell, account status, and last login.

🔧 `ssh_whoami`

Show the current authenticated user on the remote session.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_whoami()

Returns: The username of the currently authenticated SSH user.

🔧 `ssh_last_logins`

Show recent login history.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_last_logins()

Returns: Recent login records including username, terminal, source IP/hostname, and login/logout times.

Category 10: Cron Jobs (3 tools)

Manage scheduled tasks (cron jobs) on the remote server.

🔧 `ssh_list_cron`

List all cron jobs for the current user (or root).

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_list_cron()

Returns: All crontab entries with their schedule expressions and commands.

🔧 `ssh_add_cron`

Add a new cron job.

Parameter	Type	Required	Default	Description
`schedule`	`str`	Yes	—	Cron schedule expression (e.g., `'0 2 * * *'` for daily at 2 AM).
`command`	`str`	Yes	—	Command to execute on schedule.
`session_name`	`str`	No	`'default'`	Session to use.

Examples:

# Daily backup at 2 AM
ssh_add_cron(schedule='0 2 * * *', command='/opt/scripts/backup.sh >> /var/log/backup.log 2>&1')

# Every 5 minutes health check
ssh_add_cron(schedule='*/5 * * * *', command='curl -s http://localhost:8080/health > /dev/null')

# Weekly log rotation on Sunday at midnight
ssh_add_cron(schedule='0 0 * * 0', command='/usr/sbin/logrotate /etc/logrotate.conf')

Cron Schedule Quick Reference:

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of month (1 - 31)
│ │ │ ┌───────────── month (1 - 12)
│ │ │ │ ┌───────────── day of week (0 - 7, where 0 and 7 = Sunday)
│ │ │ │ │
* * * * *  command

🔧 `ssh_remove_cron`

Remove a cron job matching a pattern.

Parameter	Type	Required	Default	Description
`pattern`	`str`	Yes	—	Pattern to match against cron entries. All matching entries are removed.
`session_name`	`str`	No	`'default'`	Session to use.

Example:

# Remove the backup cron job
ssh_remove_cron(pattern='backup.sh')

Category 11: Archive & Compression (2 tools)

Create and extract compressed archives.

🔧 `ssh_compress`

Create a compressed archive (tar.gz or zip).

Parameter	Type	Required	Default	Description
`source`	`str`	Yes	—	Path to file or directory to compress.
`destination`	`str`	Yes	—	Output archive path (e.g., `/tmp/backup.tar.gz` or `/tmp/files.zip`).
`session_name`	`str`	No	`'default'`	Session to use.

Examples:

# Create a tar.gz archive
ssh_compress(source='/var/www/html', destination='/backups/site-backup.tar.gz')

# Create a zip archive
ssh_compress(source='/home/admin/documents', destination='/tmp/documents.zip')

The archive format is automatically determined by the file extension of destination.

🔧 `ssh_extract`

Extract a compressed archive.

Parameter	Type	Required	Default	Description
`source`	`str`	Yes	—	Path to the archive file.
`destination`	`str`	Yes	—	Directory to extract into.
`session_name`	`str`	No	`'default'`	Session to use.

Examples:

# Extract a tar.gz
ssh_extract(source='/backups/site-backup.tar.gz', destination='/var/www/html')

# Extract a zip
ssh_extract(source='/tmp/release-v2.zip', destination='/opt/app')

Supports .tar.gz, .tgz, .tar.bz2, .tar.xz, .zip, and .tar formats.

Category 12: Security & Audit (3 tools)

Service management and security auditing tools.

🔧 `ssh_check_service`

Check the status of a systemd service (equivalent to systemctl status).

Parameter	Type	Required	Default	Description
`service`	`str`	Yes	—	Service name (e.g., `'nginx'`, `'sshd'`, `'docker'`).
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_check_service(service='nginx')

Returns: Service active/inactive status, enabled/disabled state, PID, memory usage, and recent log entries.

🔧 `ssh_manage_service`

Start, stop, restart, enable, or disable a systemd service.

Parameter	Type	Required	Default	Description
`service`	`str`	Yes	—	Service name.
`action`	`str`	Yes	—	Action to perform: `'start'`, `'stop'`, `'restart'`, `'enable'`, or `'disable'`.
`session_name`	`str`	No	`'default'`	Session to use.

Examples:

# Restart nginx after config change
ssh_manage_service(service='nginx', action='restart')

# Enable a service to start on boot
ssh_manage_service(service='docker', action='enable')

# Stop a service
ssh_manage_service(service='apache2', action='stop')

🔧 `ssh_failed_logins`

Show failed SSH login attempts (checks auth logs and/or lastb).

Useful for security auditing — detect brute-force attempts, unauthorized access, and suspicious login activity.

Parameter	Type	Required	Default	Description
`session_name`	`str`	No	`'default'`	Session to use.

Example:

ssh_failed_logins()

Returns: Recent failed login attempts with timestamp, username attempted, source IP address, and authentication method.

🔀 Multi-Session Usage Examples

One of the most powerful features of this MCP server is the ability to manage multiple Linux servers simultaneously through named sessions.

Example: Managing Production + Staging

You: "Connect to my production server at prod.example.com and staging at staging.example.com"

→ AI calls: ssh_connect(host='prod.example.com', username='admin', password='...', session_name='prod')
→ AI calls: ssh_connect(host='staging.example.com', username='admin', password='...', session_name='staging')

You: "Show disk usage on both servers"

→ AI calls: ssh_disk_usage(session_name='prod')
→ AI calls: ssh_disk_usage(session_name='staging')

→ AI presents a comparison table of disk usage across both environments

Example: Rolling Deployment Across Multiple Servers

You: "Connect to all three web servers"

→ ssh_connect(host='web1.internal', session_name='web1')
→ ssh_connect(host='web2.internal', session_name='web2')
→ ssh_connect(host='web3.internal', session_name='web3')

You: "Deploy the latest version to each server one at a time"

→ For each server:
   1. ssh_manage_service(service='nginx', action='stop', session_name='web1')
   2. ssh_execute(command='cd /var/www && git pull origin main', session_name='web1')
   3. ssh_manage_service(service='nginx', action='start', session_name='web1')
   4. ssh_check_service(service='nginx', session_name='web1')  # verify healthy
   → Repeat for web2, web3...

Example: Comparing Configurations Across Environments

You: "Compare the nginx config between prod and staging"

→ ssh_read_file(path='/etc/nginx/nginx.conf', session_name='prod')
→ ssh_read_file(path='/etc/nginx/nginx.conf', session_name='staging')

→ AI shows a diff of the two configurations

Session Management

You: "Show me all my active sessions"

→ ssh_list_sessions()

Result:
┌──────────┬──────────────────┬──────────┬────────┬──────────┐
│ Session  │ Host             │ Username │ Uptime │ Commands │
├──────────┼──────────────────┼──────────┼────────┼──────────┤
│ prod     │ prod.example.com │ admin    │ 45m    │ 23       │
│ staging  │ stg.example.com  │ admin    │ 42m    │ 18       │
│ web1     │ web1.internal    │ deploy   │ 12m    │ 8        │
└──────────┴──────────────────┴──────────┴────────┴──────────┘

You: "Disconnect from all servers"

→ ssh_disconnect_all()

🛡 Security Best Practices

1. Use SSH Key Authentication in Production

Password-based authentication is convenient for development but less secure. For production servers:

ssh_connect(host='prod.example.com', username='deploy', key_path='C:\\Users\\pawan\\.ssh\\prod_key')

Generate a key pair if you don't have one:

ssh-keygen -t ed25519 -C "mcp-server"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

2. Credential Cache File Permissions

The credential cache at ~/.ssh-mcp-cache/credentials.json is created with restricted permissions (600 — owner read/write only). Verify this:

ls -la ~/.ssh-mcp-cache/credentials.json
# Should show: -rw------- 1 user user ... credentials.json

3. Don't Commit Credentials to Git

Never commit mcp.json files containing passwords to version control.

Add to your .gitignore:

# MCP configuration with credentials
.cursor/mcp.json
mcp.json

# SSH MCP credential cache
.ssh-mcp-cache/

4. Use Environment Variables or Interactive Mode

Instead of hardcoding passwords in config files:

Option A: Set environment variables in your shell profile (they won't be in any file checked into git)
Option B: Omit the env section entirely and let the server prompt you in chat

5. Principle of Least Privilege

Create a dedicated SSH user for MCP operations with only the permissions needed:

# On the remote server
sudo useradd -m -s /bin/bash mcp-user
sudo usermod -aG docker mcp-user  # if Docker access is needed
# Avoid giving root access unless absolutely necessary

6. Network Security

Use a VPN or SSH bastion host for accessing production servers
Configure firewall rules to restrict SSH access to known IP addresses
Consider using fail2ban to block brute-force attempts

🔧 Troubleshooting

Server Not Loading in AI IDE

Symptom: The MCP server shows as disconnected or doesn't appear in the tools list.

Solutions:

Verify uv is in your PATH:
```
uv --version
```
If not found, reinstall uv or add it to your system PATH.
Check the config file path: Ensure your mcp.json is in the correct location for your IDE (see Configuring Your AI IDE).
Validate JSON syntax: A single missing comma or bracket will break the config. Use a JSON validator.
Check the --directory path: Make sure the path in args points to the actual project directory containing server.py.
Restart the IDE: Some IDEs only read MCP configs on startup.

Connection Refused

Symptom: ssh_connect fails with "Connection refused."

Solutions:

Verify the host is reachable:
```
ping your-host
```
Check SSH is running on the remote host:
```
sudo systemctl status sshd
```

Verify the port:

Test-NetConnection -ComputerName your-host -Port 22

Check firewall rules on both the remote server and your local network.

Authentication Failed

Symptom: ssh_connect fails with "Authentication failed."

Solutions:

Verify credentials manually:
```
ssh username@host
```
Check username/password: Ensure no typos, especially with special characters.
SSH key permissions: Private key files must have restricted permissions:
```
chmod 600 ~/.ssh/id_rsa
```
Server allows password auth: Check /etc/ssh/sshd_config on the remote host:
```
PasswordAuthentication yes
```

Command Timeout

Symptom: Commands fail with a timeout error.

Solutions:

Increase the timeout parameter:

ssh_execute(command='find / -name "*.log"', timeout=120)

Use background execution for long-running commands:

ssh_execute_background(command='tar czf /backup/full.tar.gz /')

Check network latency between your machine and the remote host.

Debugging with MCP Inspector

For any issue, the MCP Inspector provides detailed insight:

cd C:\AI_Workspaces\Anti_Workspace\linux-ssh-mcp
uv run mcp dev server.py

This opens a browser-based UI where you can:

See all registered tools and their schemas
Test individual tools with custom inputs
View raw JSON requests and responses
Check server logs for errors

Common Error Messages

Error Message	Likely Cause	Fix
`No active session 'default'`	Not connected yet	Call `ssh_connect` first
`Session 'prod' already exists`	Duplicate session name	Use a different name or disconnect first
`Connection timed out`	Host unreachable or wrong port	Check host, port, and firewall
`Authentication failed`	Wrong credentials	Verify username/password/key
`Permission denied`	Insufficient privileges	Use `sudo` or connect as root
`Command not found`	Missing tool on remote host	Install the required package
`No such file or directory`	Invalid path	Verify the path exists on the remote server

👥 Author & Contact

This project was created by Pawan Gunjkar.

Author: Pawan Gunjkar
Email: pawangunjkar@gamil.com
Bug Reports: If you find any bugs, issues, or want to report bugs/request help, please report them to me at my email above.

📄 License

This project is licensed under the MIT License.

MIT License

Copyright (c) 2026 Pawan Gunjkar <pawangunjkar@gamil.com>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Built with ❤️ using FastMCP + Paramiko

If you find this useful, give it a ⭐!

Available Tools

62 tools

ssh_add_cronB

Add a new cron job for the current user.

Args: schedule: Cron schedule expression (e.g., '0 2 * * *' for daily at 2am) command: Command to run session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`command`	Yes
`schedule`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided. Description does not disclose behavioral traits such as overwrite behavior, permission requirements, or error handling. Only states action without 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise with one line and a parameter list. No redundant information. Could benefit from slightly more detail without becoming verbose.

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?

Provides basic information needed to invoke the tool, but lacks details on valid schedule formats, allowed commands, and error scenarios. With an output schema present, returns are not required, but completeness is still moderate.

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?

Provides an example for schedule ('0 2 * * * for daily at 2am') adding meaning beyond the schema. However, command and session_name have no extra context. With 0% schema description coverage, some compensation but insufficient.

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?

Clearly states 'Add a new cron job for the current user' with specific verb and resource. Distinct from sibling tools like ssh_list_cron and ssh_remove_cron.

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., modifying cron jobs) or any prerequisites. Lacks context for agent decision-making.

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

ssh_change_ownerC

Change file ownership (chown).

Args: path: Path to file/directory owner: New owner username group: New group name (optional) session_name: SSH session to use recursive: Apply recursively

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`group`	No
`owner`	Yes
`recursive`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, and description does not disclose behavioral traits such as required permissions (e.g., ownership change may need root), destructive nature, or side effects. Only a terse summary.

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?

Description is concise (one line plus list of args) and front-loaded with purpose. However, the list of args is redundant with the input schema and could be omitted or expanded with useful details.

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?

For a 5-parameter tool with no annotations and an output schema (not shown), the description is incomplete. It does not cover prerequisites, error conditions, return values, or behavior of optional parameters like group and recursive.

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

Parameters1/5

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

Schema coverage is 0%, yet description merely lists parameter names without adding meaning. For example, 'owner' and 'group' are not explained, and 'recursive' is just named. Does not compensate for lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Change file ownership (chown)', which is a specific verb+resource. It distinguishes from siblings like ssh_file_permissions (which changes permissions). However, it lacks additional context about scope or edge cases.

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 vs alternatives (e.g., when to use ssh_file_permissions instead). No mention of prerequisites or when not to use.

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

ssh_check_portA

Test if a specific port is reachable from the remote machine.

Args: host: Target hostname or IP port: Target port number session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`host`	Yes
`port`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/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 details such as protocol (TCP/UDP), timeout behavior, or whether the check requires specific permissions. The description carries the full burden for behavioral disclosure but provides minimal information.

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 compact and front-loaded with the purpose. Each sentence serves a clear function 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?

Given the absence of annotations and the presence of an output schema (which likely covers return details), the description is adequate but could include more context, such as what 'reachable' means (e.g., open TCP connection) or return type. It is minimally complete for a simple 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?

The description adds concise parameter descriptions that are absent from the input schema (0% coverage). It explains host, port, and session_name in a helpful way, compensating for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states that the tool tests port reachability, distinguishing it from related tools like ssh_open_ports (which lists open ports) and ssh_ping (which tests host reachability). The verb and resource 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 Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description only explains what it does, not the context for its use.

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

ssh_check_serviceB

Check the status of a systemd service.

Args: service: Service name (e.g., 'nginx', 'docker', 'sshd') session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`service`	Yes
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

The description does not disclose behavioral traits such as whether the tool requires sudo, what happens if the service is missing, or if it has side effects. No annotations are provided to supplement this information.

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 extremely concise with no wasted words. The purpose is front-loaded and the Args list is clear and brief.

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 status check tool with an output schema, the description covers the basic purpose and parameters. However, it lacks context about prerequisites (e.g., existing SSH session) and error handling, making it adequate but not thorough.

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 description adds example values for the 'service' parameter (e.g., 'nginx', 'docker') and states the purpose of 'session_name', but provides no additional detail beyond the parameter names. Given 0% schema coverage, the description only partially compensates.

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 checks the status of a systemd service, with specific verb and resource. However, it does not explicitly differentiate from sibling 'ssh_manage_service' which may also check status, but the name and description imply a read-only check.

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 like 'ssh_manage_service' or when not to use it. The context of use is only implied by the name.

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

ssh_check_updatesC

Check for available package updates.

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

The description implies a read-only operation ('check'), but does not explicitly state that it is non-destructive or disclose any behavioral traits such as whether it modifies system state, what the output contains, or any required permissions. With no annotations, this gap is significant.

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 description is extremely concise (two lines), but it lacks structure and omits important details. While brevity is valued, the extreme under-specification reduces clarity.

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 does not explain what the output contains (though an output schema exists, it is not described in the text) or how to interpret 'available updates.' For a simple check tool, the description leaves the agent with incomplete 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?

The description adds minimal meaning beyond the schema by noting that 'session_name' refers to the SSH session to use. However, with 0% schema description coverage, the tool relies on this brief mention. The parameter is optional with a default, but no additional details are provided.

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 'Check for available package updates' clearly states the tool's purpose with a specific verb and resource. However, it does not distinguish itself from sibling tools like ssh_list_packages or ssh_install_package, which could also involve package updates.

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 usage guidelines are provided. The description does not indicate when to use this tool instead of alternatives (e.g., ssh_list_packages to list installed packages or ssh_install_package to install updates). It also lacks any prerequisites or context for usage.

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

ssh_compressA

Compress files or directories into an archive.

Args: source: Path to file/directory to compress destination: Output archive path (auto-generated if empty) session_name: SSH session to use format: Archive format — 'tar.gz' (default), 'tar.bz2', 'zip'

ParametersJSON Schema

Name	Required	Default
`format`	No	tar.gz
`source`	Yes
`destination`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description discloses core behavior (compression, auto-generated destination, supported formats) but omits details like remote execution, overwrite behavior, or error handling.

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 very concise with two short sentences plus a brief parameter list. No wasted words; the core purpose is 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 tool with an output schema, return values need not be explained, but the description could cover error scenarios, overwrite behavior, or confirmation of archive creation. Adequate for simple use, but not fully complete.

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 0%, and the description clearly explains all four parameters: source path, auto-generated destination, session name, and supported archive formats including default. Adds 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 'Compress files or directories into an archive' uses a specific verb and resource clearly stating the tool's function. It distinguishes from siblings like ssh_extract.

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 explicit guidance on when to use this tool versus alternatives such as ssh_extract or other file operations. Does not mention prerequisites like an active SSH session.

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

ssh_connectA

Connect to a remote Linux host via SSH and create a named session.

If a session with the same name exists, it will be disconnected first. Credentials are automatically cached for future reconnection.

Args: host: Linux server IP address or hostname username: SSH username (default: root) password: SSH password (leave empty if using key_path) key_path: Path to SSH private key file (alternative to password) port: SSH port number (default: 22) session_name: Name for this session, e.g. 'prod', 'staging' (default: 'default')

ParametersJSON Schema

Name	Required	Default
`host`	Yes
`port`	No
`key_path`	No
`password`	No
`username`	No	root
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Discloses that existing sessions with the same name are disconnected first and that credentials are cached. No annotations provided, but description lacks details on error handling, timeouts, or authentication failure behavior.

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?

Compact and informative: purpose sentence, two behavioral statements, then clear argument list. No redundant or unnecessary text.

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?

Covers purpose, session behavior, credential caching, and all parameters. However, omits mention of timeout, error messages, or output details (though output schema exists). Adequate for a connection tool.

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?

With 0% schema description coverage, the description fully documents each parameter with defaults and usage notes (e.g., 'leave empty if using key_path'), adding significant value 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?

Clearly states the action 'Connect to a remote Linux host via SSH' and adds 'create a named session', distinguishing it from other SSH siblings like ssh_execute 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?

Mentions session reuse and credential caching but does not explicitly state when to use this tool versus alternatives (e.g., ssh_execute after connecting). Usage is implied rather than guided.

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

ssh_copyB

Copy a file or directory.

Args: source: Source path destination: Destination path session_name: SSH session to use recursive: If True, copy directories recursively

ParametersJSON Schema

Name	Required	Default
`source`	Yes
`recursive`	No
`destination`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

Lacks behavioral details: no mention of overwrite behavior, permission preservation, or error handling. With no annotations, the description carries full burden but only gives parameter names.

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?

Extremely concise: one line for purpose, four lines for args. No extraneous info, front-loaded with the action.

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?

Despite having an output schema, the description omits critical context like whether copy is local-to-remote, remote-to-local, or both, and whether it requires an active SSH session (session_name suggests so but not explicit).

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 0%, so description must compensate. It provides brief explanations for all 4 parameters, but lacks depth (e.g., source/destination paths could be local or remote).

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 copies a file or directory, using a specific verb and resource. It distinguishes from sibling tools like ssh_move, ssh_delete, etc.

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 copy vs alternatives (e.g., move) or prerequisites like active session. The description simply defines the action without context.

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

ssh_cpu_infoB

Show CPU information, core count, and current load averages.

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/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 the full burden. It does not disclose whether the tool is read-only, requires authentication, or has rate limits. The only behavioral detail is that it relies on an SSH session, which is implied by the parameter name.

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 short sentences plus a minimal Args section, with no redundant or filler content. It is efficiently front-loaded with the tool's purpose.

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 output schema exists (so return values are documented), the description is adequate but lacks details about session requirements and differentiation from similar siblings. It covers the basic functionality but is not fully complete for tool selection.

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 0%, but the description adds a brief explanation for the sole parameter ('SSH session to use'), which clarifies its purpose. However, it does not specify valid values or prerequisites (e.g., session must be active).

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 shows 'CPU information, core count, and current load averages', which is a specific verb and resource. It distinguishes from sibling tools like ssh_system_load and ssh_memory_usage by explicitly naming CPU-related outputs.

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 given on when to use this tool versus alternatives such as ssh_system_info or ssh_system_load. The description does not mention context or exclusions, leaving the agent to infer usage.

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

ssh_create_directoryA

Create a directory (and parent directories if needed).

Args: path: Directory path to create (uses mkdir -p) session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are present, so the description must disclose behavior. It notes the use of 'mkdir -p' which implies recursive creation, but does not cover permissions, error handling, or behavior when the directory already 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 extremely concise: two sentences for the purpose and a brief bullet list for parameters. No extraneous information, and the key action is front-loaded.

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

Completeness4/5

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

For a simple directory creation tool, the description covers the essential behavior and parameters. The presence of an output schema (not shown) reduces the need to explain return values. Minor gaps like default permissions or error handling are forgivable.

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?

With 0% schema description coverage, the description compensates by explaining both parameters: 'path' (directory path, uses mkdir -p) and 'session_name' (SSH session). This adds meaningful context beyond the schema's bare titles.

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's action ('Create a directory') and the resource ('directory'), using a specific verb. It also mentions creating parent directories, distinguishing it from sibling tools like ssh_list_directory or ssh_delete.

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 versus alternatives (e.g., ssh_move, ssh_copy). It only describes the operation, leaving the agent to infer usage context from the tool name alone.

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

ssh_deleteA

Delete a file or directory on the remote machine.

Args: path: Path to delete session_name: SSH session to use recursive: If True, delete directories recursively (rm -rf)

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`recursive`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. Mentions recursive flag and rm -rf, hinting at destructiveness, but does not explain safety, confirmation prompts, or behavior on nonexistent paths.

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?

Very concise: one purpose sentence followed by parameter list. No redundancy or unnecessary details.

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?

Missing context around prerequisites (SSH session must exist), error handling, and irreversibility. Output schema may cover return values, but behavioral context could be richer.

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 0%, so description adds meaning. Each parameter gets a brief explanation: path, session_name, and recursive with note about rm -rf. Clear but lacks examples or edge cases.

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?

Description clearly states 'Delete a file or directory on the remote machine', which is a specific verb and resource. It distinguishes from siblings like ssh_compress, ssh_move, and ssh_copy.

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?

No explicit when-to-use or when-not-to-use guidance. The tool name implies its purpose, but no comparison to alternatives like ssh_move or ssh_copy. Usage is implied rather than explicit.

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

ssh_disconnectB

Disconnect a specific SSH session.

Args: session_name: Name of the session to disconnect (default: 'default')

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the action is destructive, what happens if the session does not exist, or any side effects. The description is minimal.

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 short and direct, with the parameter documentation following the main sentence. No unnecessary words, but the parameter description could be integrated more seamlessly.

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 tool is simple with one parameter, so the description is mostly complete. However, it lacks information about return values, error handling, and confirmation of disconnection. The output schema exists but is not shown.

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 0%, so the description must compensate. It explains the only parameter 'session_name' with its default value, adding meaning beyond the schema which has no descriptions. This is adequate for a single parameter.

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 ('Disconnect') and resource ('SSH session'). It differentiates from sibling 'ssh_disconnect_all' by specifying 'specific' session.

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_disconnect_all. The description does not mention prerequisites, error states, or recommended usage context.

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

ssh_disconnect_allB

Disconnect all active SSH sessions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as safety, permissions, or impact on running processes; for a destructive action, more transparency is needed.

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?

One short, focused sentence with no unnecessary words; perfectly sized for the tool's simplicity.

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?

Description states core functionality but lacks behavioral context for a potentially destructive operation; output schema exists but doesn't compensate for missing behavioral details.

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?

No parameters exist, and schema coverage is 100% by default; baseline of 3 applies as description adds no param info beyond 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 'disconnect all active SSH sessions' with a specific verb and resource, distinguishing from the sibling ssh_disconnect by specifying 'all'.

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 vs alternatives like ssh_disconnect or ssh_list_sessions; no prerequisites or when-not-to-use context.

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

ssh_disk_file_usageB

Check disk usage of a file or directory (du -sh).

Args: path: Path to check session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 bears full responsibility for behavioral disclosure. The description only states 'check' which implies a read operation, but does not explicitly confirm it is non-destructive, mention permissions, or describe any other behavioral traits.

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 extremely concise, using a single sentence plus a two-parameter list. The purpose is stated upfront with the equivalent command 'du -sh', making it immediately understandable.

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?

Although the tool has an output schema, the description does not mention what it returns (e.g., disk usage value, human-readable format). The description is adequate for a simple check but lacks detail on output and differentiation from similar sibling tools.

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 0%, so the description must add meaning. It repeats the parameter names with minimal elaboration: 'path: Path to check' and 'session_name: SSH session to use'. This adds slight clarification beyond the schema titles but is insufficient to fully compensate for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Check disk usage of a file or directory (du -sh)', which is a specific verb and resource. It distinguishes from the sibling 'ssh_disk_usage' presumably by focusing on a single file/dir rather than overall disk usage, but does not explicitly make this distinction.

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_disk_usage'. It does not specify when it is appropriate or inappropriate, nor does it mention any exclusions or prerequisites.

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

ssh_disk_usageA

Show disk usage across all mounted filesystems (df -h).

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

The description explicitly mentions the command 'df -h', indicating a non-destructive read operation. Since no annotations are provided, this is sufficient for behavioral transparency. It does not describe output format but output schema exists, so that is covered elsewhere.

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?

Extremely concise and well-structured. The primary purpose is stated in the first line, followed by parameter documentation. No redundant 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?

For a simple tool with one parameter and an output schema, the description provides adequate context. It could mention that it runs on the remote SSH session, but that is implied. The presence of an output schema likely documents return values.

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 description provides a brief semantic explanation for the one parameter ('SSH session to use'), compensating for the 0% schema coverage. It is clear and sufficient for the tool's purpose.

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 shows disk usage across all mounted filesystems and mentions the underlying command (df -h). This distinguishes it from sibling ssh_disk_file_usage which likely focuses on individual file usage.

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?

No explicit guidance on when to use this tool versus alternatives. The presence of sibling ssh_disk_file_usage implies a distinction but is not stated. Usage context is implied by the description.

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

ssh_dns_lookupA

Perform DNS lookup for a domain.

Args: domain: Domain name to look up session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden. It only says 'perform DNS lookup' but does not explain how the lookup is executed (e.g., via dig, nslookup), what happens on failure, or any side effects on the SSH session. Behavioral details are minimal.

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 extremely concise, with a clear one-line purpose followed by parameter definitions. Every sentence is necessary and there is no fluff. Well 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?

The tool has an output schema (not shown) but the description does not mention what the return data is (e.g., IP addresses, records). For a DNS lookup tool, this is a notable gap, but the description is adequate for basic understanding.

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?

Despite 0% schema coverage, the description explains both parameters: 'Domain name to look up' and 'SSH session to use', adding meaning beyond the schema's titles. This provides useful context for an agent.

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 performs a DNS lookup for a domain, which is a specific and distinct action among the many SSH-related sibling tools. The verb 'perform' and resource 'DNS lookup' are precise.

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. The description lacks any context about prerequisites, typical use cases, or when not to use it. It's implied by the name but not explicit.

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

ssh_docker_composeB

Run docker compose commands.

Args: action: Compose action — 'up', 'down', 'restart', 'ps', 'logs', 'build', 'pull' path: Path to the directory containing docker-compose.yml session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`path`	No	.
`action`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must compensate. It does not mention potential side effects (e.g., container creation or destruction), required permissions, or safety considerations for actions like 'up' or 'down'.

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 front-loaded with the core purpose. Every sentence is necessary and adds value without redundancy.

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 3 parameters, no annotations, and an output schema (not detailed), the description is minimally adequate. It covers the main actions but does not explain return values or behavior for each action, nor does it account for potential errors.

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 description lists possible action values but does not define them beyond examples. Schema has 0% description coverage, so the description adds some value by enumerating actions, but lacks details on path format or session_name usage.

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 'Run docker compose commands.' and lists actions, making the tool's purpose apparent. It distinguishes from sibling tools like ssh_docker_exec by focusing on docker compose specific commands, but does not explicitly differentiate.

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_docker_exec, ssh_docker_logs). No prerequisites or context provided.

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

ssh_docker_execA

Execute a command inside a running Docker container.

Args: container: Container name or ID command: Command to execute inside the container session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`command`	Yes
`container`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/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 states execution inside a container, but does not disclose requirements (e.g., Docker must be installed, container must be running), permissions, side effects, or error cases. Minimal transparency beyond the obvious.

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: one sentence followed by a parameter list. Every sentence adds value. No redundant or extraneous information. Front-loaded with the tool's purpose.

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 and the presence of an output schema, the description is largely complete. It could benefit from noting that the Docker container must already be running and that the session_name indicates the SSH session, but overall sufficient for an exec 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 coverage is 0%, so description must add meaning. It does so by explaining each parameter in plain language (e.g., 'container: Container name or ID', 'command: Command to execute'). However, it could provide more detail (e.g., command format, validation rules).

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 'Execute a command inside a running Docker container,' specifying the action, resource, and context. It effectively distinguishes from sibling tools like ssh_execute (for commands on the host) and other Docker tools.

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?

Usage context is implied (inside a running Docker container), but no explicit guidance is given on when to choose this tool over alternatives like ssh_execute or when the container must already exist. 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_docker_imagesC

List Docker images on the remote machine.

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 operation is read-only, requires specific permissions, or has side effects. For a listing tool, read-only behavior 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and to the point, but lacks structure like sections or emphasis. It is not verbose, but could be better organized.

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 simplicity of the tool (listing images) and existence of an output schema, the description covers the basic purpose. However, it lacks information about output format or usage prerequisites, making it slightly incomplete.

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

Parameters2/5

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

The description adds minimal meaning to the 'session_name' parameter by stating 'SSH session to use', but with 0% schema coverage, more detail is expected (e.g., default value behavior, valid values).

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 'List' and resource 'Docker images on the remote machine', making the purpose unambiguous. This distinguishes it from sibling tools like ssh_docker_ps (list processes) and ssh_docker_logs.

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. Among many Docker-related sibling tools, there is no mention of selection criteria 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_docker_inspectA

Inspect a Docker container (detailed configuration and state).

Args: container: Container name or ID session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`container`	Yes
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 the full burden. It implies a read-only operation ('Inspect') but doesn't explicitly state it's non-destructive, what happens if the container doesn't exist, or whether an active SSH session is required. The description is adequate but lacks important behavioral details.

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 extremely concise: one sentence and a two-line arg list. It is front-loaded with the purpose and wastes no 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?

Given the tool has an output schema, the description does not need to explain return values. However, it could mention that the output is a JSON object with configuration and state. The description is complete enough for a simple tool but lacks context for differentiating from siblings.

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 description adds basic meaning to parameters: 'container' is a name or ID, 'session_name' is the SSH session. However, it doesn't specify format expectations, that 'container' is required (though schema does), or any constraints. With 0% schema coverage, the description provides minimal but useful context.

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 inspects a Docker container, providing detailed configuration and state. This distinguishes it from sibling tools like ssh_docker_ps (list), ssh_docker_stats (resource usage), and ssh_docker_logs (logs), 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?

The description does not provide any guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or when to choose inspect over other Docker tools like ps or stats.

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

ssh_docker_logsB

Get Docker container logs.

Args: container: Container name or ID session_name: SSH session to use lines: Number of log lines to retrieve (default: 100)

ParametersJSON Schema

Name	Required	Default
`lines`	No
`container`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose any behavioral traits (e.g., permissions, rate limits, idempotency, error handling). Only states the basic function.

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?

Description is very short with one line for purpose and a list of args. It is front-loaded and efficient, with no redundant information.

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 complexity (3 params, no annotations, unknown output schema), the description lacks context on when to use this tool versus other Docker/SSH tools. Does not describe output format or edge cases.

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 0%, but the description adds clear meanings for all three parameters (container, session_name, lines), including defaults. This compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get Docker container logs', which is a specific verb and resource. It distinguishes from siblings like 'ssh_search_logs' which is for searching logs, so purpose is clear but could explicitly differentiate.

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 vs alternatives like 'ssh_docker_exec' or 'ssh_docker_inspect'. No exclusions or prerequisites mentioned.

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

ssh_docker_psA

List Docker containers (running or all).

Args: session_name: SSH session to use all: If True, show all containers including stopped ones

ParametersJSON Schema

Name	Required	Description	Default
`all`	No
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It states it lists containers and mentions the 'all' parameter for stopped ones, but does not disclose behavioral traits like whether it's read-only, authentication needs, or side effects. Adequate but minimal.

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 very concise: two lines for the main action, then two lines for the args. Front-loaded with purpose, no redundant sentences. Every word earns its place.

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 list tool with an output schema, the description is adequate. It covers the essential function and parameters. Could be more complete by mentioning that it uses SSH sessions, but that is implied by the sibling context. Minor 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 coverage is 0%, so the description compensates by explaining both parameters: session_name (SSH session to use) and all (show all containers including stopped ones). This adds meaningful context beyond the schema's titles and defaults.

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 lists Docker containers, with a specific verb 'List' and resource 'Docker containers'. It distinguishes between running and all via the 'all' parameter, and among sibling tools like ssh_docker_exec and ssh_docker_logs, it uniquely identifies its purpose.

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 gives an implied usage (list containers) but lacks explicit guidance on when to use this tool vs alternatives, such as checking container status, or when not to use it. No exclusions or context about prerequisites.

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

ssh_docker_statsB

Show Docker container resource usage statistics (CPU, memory, network).

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so the description must fully disclose behavior. It only states 'show' but doesn't explain if the command is read-only, requires specific permissions, or returns a single snapshot vs. live stream.

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?

Very concise with clear front-loading of purpose. The two-sentence structure is efficient, though it could include more detail without being verbose.

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 an output schema exists, return values don't need explanation. However, the description lacks prerequisites (e.g., Docker active) and edge cases, leaving some gaps for an agent.

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 description adds meaning to the 'session_name' parameter ('SSH session to use'), but schema description coverage is 0%. This provides basic context, but no additional details like format or constraints.

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 shows Docker container resource usage statistics (CPU, memory, network). This distinguishes it from sibling tools like ssh_docker_ps (list containers) and ssh_docker_logs (logs).

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. It doesn't specify prerequisites (e.g., Docker installed, running containers) or scenarios where it's appropriate.

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

ssh_executeA

Execute a shell command on the remote Linux machine.

Returns stdout, stderr, and exit code. Output is truncated if too large.

Args: command: Shell command to execute (e.g., 'ls -la /var/log') session_name: SSH session to use (default: 'default') timeout: Command timeout in seconds (default: 30, max: 300)

ParametersJSON Schema

Name	Required	Default
`command`	Yes
`timeout`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Discloses output truncation, timeout defaults and maximum, and return values (stdout, stderr, exit code). Without annotations, this provides sufficient behavioral context. Could mention that command is run in the default shell and is blocking.

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?

Concise yet comprehensive. Uses clear sections (Args) and sentences are to the point. No redundant or verbose language.

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?

Covers parameters, behavior, and outputs. With an output schema present, return value explanation is sufficient. Minor gap: does not explain what 'session_name' refers to (preexisting SSH connection).

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?

Adds meaningful details beyond raw schema: provides example for command, explains session_name default, and specifies timeout range (default 30, max 300). Schema description coverage is 0%, so this extra context is valuable.

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?

Clearly states it executes a shell command on a remote Linux machine and returns stdout/stderr/exit code. Distinguished from siblings like ssh_execute_background and ssh_execute_script by focusing on foreground execution.

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?

Implies usage for running immediate shell commands but does not explicitly specify when to use vs alternatives or provide any prerequisites or conditions. 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_execute_backgroundA

Run a command in the background using nohup.

The command will continue running even after the SSH session ends. Output is redirected to a log file.

Args: command: Command to run in background log_file: Path for output log (default: /tmp/bg_command_.log) session_name: SSH session to use (default: 'default')

ParametersJSON Schema

Name	Required	Default
`command`	Yes
`log_file`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It describes nohup usage and logging behavior, but omits potential issues like nohup availability, job persistence across shell restarts, or permissions needed.

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 concise and front-loaded with the purpose. The 'Args' section is efficient, though merging it into prose might reduce bulk slightly. Overall, every sentence adds value.

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 moderate complexity, an output schema exists (not shown), so return values are covered. All parameters are explained, and core behavior is described. Minor gaps like error handling and multi-job management remain.

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 0%, but the description provides an 'Args' section explaining each parameter's purpose and defaults (e.g., log_file default path includes timestamp). This adds significant meaning beyond the schema, though could be slightly more detailed.

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 'Run a command in the background using nohup', specifying a specific verb and resource. It distinguishes itself from sibling tools like ssh_execute (runs foreground) and ssh_execute_script (scripts).

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 explains that the command continues after SSH session ends and output is redirected to a log file, providing clear context for long-running tasks. However, it does not explicitly state when not to use this tool or mention alternatives.

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

ssh_execute_scriptC

Execute a multi-line bash script on the remote machine.

The script is passed to bash via stdin. Use this for complex operations.

Args: script: Multi-line bash script content session_name: SSH session to use (default: 'default') timeout: Script timeout in seconds (default: 60, max: 300)

ParametersJSON Schema

Name	Required	Default
`script`	Yes
`timeout`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the script is passed via stdin, but fails to describe return values (stdout/stderr), error handling, side effects, or required permissions. This leaves critical behavioral traits hidden from the agent.

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 concise (3 sentences + short list), front-loaded with purpose, and well-structured. Every sentence adds value, though the Args list partially duplicates the schema, which is acceptable given the schema lacks descriptions.

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 executes arbitrary scripts (high complexity), the description is incomplete. It omits return value semantics (though output schema exists, it's not referenced), error behavior, and safety implications. The agent lacks crucial context to assess risks and interpret results, making this tool potentially dangerous without further documentation.

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?

Despite 0% schema description coverage, the description includes an Args section that adds meaning: clarifies script is 'multi-line bash content', session_name is 'SSH session to use', and timeout has a max of 300s. This compensates partially but could be more detailed (e.g., encoding, escaping). Baseline for 0% coverage is low, so this average effort nets a 3.

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 it executes a multi-line bash script, and implicitly distinguishes from sibling tools like ssh_execute (single-line) and ssh_execute_background by emphasizing 'multi-line' and 'complex operations'. However, it does not explicitly contrast with these siblings, so it falls short of a perfect 5.

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 phrase 'Use this for complex operations' provides vague guidance, but there is no explicit instruction on when not to use this tool or mention of alternatives like ssh_execute for single commands. This lack of clear usage boundaries is a significant gap.

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

ssh_extractB

Extract an archive file.

Supports: .tar.gz, .tgz, .tar.bz2, .tar, .zip, .gz, .bz2

Args: archive: Path to the archive file destination: Directory to extract to (default: current directory) session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`archive`	Yes
`destination`	No	.
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 must bear the full burden of behavioral disclosure. It only states 'Extract an archive file' without detailing potential side effects (e.g., overwriting files, required permissions, handling of invalid archives, or remote execution context via SSH). This is insufficient for a mutation 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 with three clear sentences: a one-line action statement, a line listing supported formats, and a brief parameter listing with defaults. No unnecessary verbiage; every part serves a purpose.

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 presence of an output schema (the description need not explain return values), the description adequately covers core functionality. However, it lacks important context such as that the extraction occurs remotely via SSH, error handling behavior, and whether the archive is removed after extraction. These gaps reduce completeness for a tool with no 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?

The input schema has 0% description coverage, so the description must compensate. It lists the parameters with minimal explanations (e.g., 'Path to the archive file') and mentions default values. The list of supported archive formats adds useful context but does not detail parameter constraints (e.g., valid paths, format-specific behaviors). This provides some added value over the schema, hence a 3.

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 'Extract an archive file' and lists supported formats, effectively distinguishing it from sibling tool 'ssh_compress' (compress vs. extract). However, it does not explicitly contrast with other sibling tools, preventing a perfect score.

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 versus alternatives (e.g., ssh_compress for compression, ssh_copy for copying files). There is no mention of prerequisites, context, 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_failed_loginsA

Show recent failed login attempts (from auth.log or journalctl).

Args: session_name: SSH session to use count: Number of entries to show (default: 30)

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description bears full burden. It discloses the data source (auth.log or journalctl) but does not mention permissions (e.g., root required), output format, or potential limitations (e.g., log rotation). Adequate but lacking depth.

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 concise with two short paragraphs. It includes parameter explanations, though structuring them as a list would improve scannability. No redundant 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?

The tool has an output schema, so return value details are not required. The description covers the core functionality and parameters. Minimal but sufficient for a straightforward tool given the output schema existence.

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 0% (no descriptions in schema), but the tool description explains both parameters: 'session_name' as the SSH session to use and 'count' as the number of entries. This adds meaningful semantics beyond type and default values.

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 'recent failed login attempts' from specific sources (auth.log or journalctl), using a specific verb and resource. This distinguishes it from siblings like ssh_last_logins (which likely shows all logins) and ssh_search_logs (general search).

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 like ssh_last_logins or ssh_search_logs. The description does not include context about scenarios (e.g., security auditing, troubleshooting) 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_file_infoB

Get detailed information about a file (size, type, permissions, owner, timestamps).

Args: path: Path to the file session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It states it gets file info but does not mention side effects, authentication needs, error handling (e.g., file not found), or any limitations. This is insufficient for a tool with no annotations.

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 concise (3 lines) and front-loaded with the main purpose. The Args section is slightly redundant but still efficient. Every sentence serves a purpose.

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 complexity (simple read tool) and presence of an output schema (not shown), the description adequately states it returns detailed info. However, it lacks details on return format, error conditions, or permissions required. For a tool with many siblings, more completeness would be beneficial.

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 no descriptions for parameters (0% coverage). The description adds minimal clarification: 'path' is 'Path to the file', 'session_name' is 'SSH session to use'. This provides some context beyond the schema titles but does not explain formats, constraints, or default behavior.

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 'Get' and the resource 'detailed information about a file', listing specific attributes (size, type, permissions, owner, timestamps). This distinguishes it from sibling tools like ssh_file_permissions (focused only on permissions) and ssh_list_directory (lists directory contents).

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 versus siblings. It does not mention alternatives or when not to use it. For a tool with many siblings (e.g., ssh_file_permissions, ssh_find_files), explicit usage context is missing.

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

ssh_file_permissionsB

Change file permissions (chmod).

Args: path: Path to file/directory permissions: Permission string (e.g., '755', '644', 'u+x') session_name: SSH session to use recursive: Apply recursively to directories

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`recursive`	No
`permissions`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It lacks details on behavior (e.g., overwrites existing permissions? fails on non-existent path?). Only mentions recursive flag.

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?

Concise docstring format with purpose line and Args block. No extra fluff, but could be slightly more structured (e.g., avoid markdown-like formatting).

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 an output schema exists, return values are covered. However, as a mutation tool, more context on error handling or permission validation would improve completeness.

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 0%, but the description explains each parameter meaningfully (e.g., examples for permissions like '755', 'u+x'). Adds value beyond schema's type and title.

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 'Change file permissions (chmod)' with a specific verb and resource. It distinguishes this tool from SSH siblings like ssh_change_owner (chown) and others.

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, nor any prerequisites or exclusions. The description only lists parameters.

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

ssh_find_filesB

Find files and directories using the 'find' command with filters.

Args: path: Base directory to search in name: File name pattern (supports wildcards, e.g., '*.log') file_type: Type filter — 'f' for files, 'd' for directories, 'l' for symlinks size: Size filter (e.g., '+10M' for >10MB, '-1k' for <1KB) modified_within: Time filter (e.g., '7' for modified in last 7 days) session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`name`	No
`path`	No	/
`size`	No
`file_type`	No
`session_name`	No	default
`modified_within`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/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 burden. It mentions using the 'find' command but does not disclose performance implications, read-only nature, or that it requires an active SSH session. Behavioral traits are insufficiently described.

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 description uses a docstring format with a purpose line followed by parameter listing. It is fairly efficient, but the parameter list could be more compact. Nonetheless, it is readable and 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?

Given the 6 parameters and no annotations, the description covers all inputs but lacks warnings about potential large output if no filters are applied. An output schema exists, so return format is not required, but behavioral completeness is moderate.

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 0%, so the description must compensate. It provides meaningful examples for size ('+10M') and modified_within ('7'), and clearly explains file_type values. However, some details like wildcard syntax for name could be more explicit.

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 'find' and resource 'files and directories', specifying it uses the 'find' command with filters. This distinguishes it from sibling tools like ssh_file_info or ssh_search_in_files.

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 versus alternatives. For example, it does not mention that to search file content one should use ssh_search_in_files, or that for a simple directory listing ssh_list_directory is more appropriate.

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

ssh_head_fileB

Get the first N lines of a file.

Args: path: Path to the file lines: Number of lines from the beginning (default: 50) session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`lines`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and the description adds minimal behavioral context beyond the basic operation. It does not disclose how the tool handles large files, binary content, or error cases, leaving significant gaps for the agent.

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 structured as a brief docstring with an Args section. It is concise (few lines) and front-loaded with the core purpose, though the 'Args:' formatting could be omitted for brevity.

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 tool's simplicity and the presence of an output schema, the description covers the basic functionality. However, it omits details about error handling, file permissions, and interaction with the SSH session, which are relevant for a production environment.

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?

With 0% schema description coverage, the description explains each parameter: path is 'Path to the file', lines is 'Number of lines from the beginning', session_name is 'SSH session to use'. This adds meaning beyond the schema's titles and defaults, but lacks detail on constraints like file encoding or line counting behavior.

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?

Description states 'Get the first N lines of a file' with clear verb and resource. It distinguishes from siblings like ssh_read_file (full file) and ssh_tail_file (last N lines), making its purpose explicit.

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 explicit guidance on when to use this tool versus alternatives like ssh_read_file or ssh_tail_file. The description only implies usage for beginning-of-file access but lacks context or exclusions.

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

ssh_install_packageA

Install a package (auto-detects apt/yum/dnf/pacman).

Args: package: Package name to install session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`package`	Yes
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided. Description mentions auto-detection of package manager but lacks details on required permissions, error behavior, or idempotency. For a system-modifying tool, more transparency is needed.

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?

Extremely concise: two lines of description followed by structured argument definitions. 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?

Covers basic functionality and inputs, but lacks details on error handling, outcome, or return values. Output schema exists (not shown) but description doesn't leverage it for completeness.

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?

Description includes an Args section that briefly describes both parameters (package and session_name), adding meaning beyond the schema property titles. Schema coverage is 0%, so description compensates well.

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?

Clearly states 'Install a package' and specifies auto-detection of package managers (apt/yum/dnf/pacman), distinguishing it from sibling tools like ssh_remove_package.

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 vs alternatives, such as prerequisites (e.g., root access) or when not to use it (e.g., unsupported package manager).

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

ssh_kill_processB

Kill a process by its PID.

Args: pid: Process ID to kill session_name: SSH session to use signal: Signal to send (default: TERM, options: KILL, HUP, INT, etc.)

ParametersJSON Schema

Name	Required	Default
`pid`	Yes
`signal`	No	TERM
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations given, so description must cover behavioral traits. It mentions default signal but omits details on permissions, error cases (e.g., non-existent PID), or 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?

Extremely concise: one sentence plus parameter list. Front-loaded with action. No superfluous content.

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?

Output schema exists but not shown; description does not explain return value or error behavior. For a destructive tool, more context on success/failure indicators is needed.

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 0%. Description adds meaning: pid is process ID, session_name usage, signal defaults. Could list valid signals more explicitly.

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?

Clearly states 'Kill a process by its PID' – specific verb and resource. Distinguishes from siblings like ssh_process_list and ssh_execute.

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 vs alternatives (e.g., ssh_top_processes or ssh_execute). No prerequisites or signal selection rationale provided.

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

ssh_last_loginsA

Show recent login history.

Args: session_name: SSH session to use count: Number of recent logins to show (default: 20)

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so the description must convey behavior. It states what the tool does (read-only) but lacks details like session requirements, permissions, or return format.

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 short and includes a clear docstring and parameters. It is efficient but could be slightly more concise by removing the 'Args:' header if not needed.

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 simple nature and presence of an output schema, the description sufficiently covers purpose and parameters, though it omits details like default session behavior.

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?

With 0% schema description coverage, the description adds meaning by explaining 'session_name: SSH session to use' and 'count: Number of recent logins to show (default: 20)', effectively compensating for the schema gaps.

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 'Show recent login history' uses a specific verb and resource, clearly distinguishing it from siblings like ssh_failed_logins or ssh_user_info.

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?

No explicit guidance on when to use this tool versus alternatives like ssh_failed_logins. The description implies it is for recent successful login history, but does not state exclusions.

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

ssh_list_cronA

List cron jobs for the current or specified user.

Args: user: Username (empty = current user) session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`user`	No
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It mentions SSH session use and lists cron jobs, but doesn't disclose behavior on empty results, error cases, 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?

Extremely concise with no wasted words. The purpose and parameters are front-loaded in a clear format.

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 listing tool with an output schema available, the description covers the essential behavior. Could add details on empty results or permissions, but sufficient.

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 has 0% description coverage, but description adds meaning for both parameters: user is 'username (empty = current user)' and session_name is 'SSH session to use'. This compensates partially.

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 (list), resource (cron jobs), and scope (by user). It distinguishes from siblings like ssh_add_cron and ssh_remove_cron.

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 vs alternatives. The description only notes that user can be empty for current user, but no context about prerequisites or exclusions.

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

ssh_list_directoryC

List directory contents with details (permissions, owner, size, date).

Args: path: Directory path to list (default: '/') session_name: SSH session to use show_hidden: Include hidden files (default: True)

ParametersJSON Schema

Name	Required	Default
`path`	No	/
`show_hidden`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior1/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention any side effects, authentication needs, error conditions, or read-only nature. The tool might be read-only but there is no confirmation.

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 description is reasonably concise with a clear first sentence, but the Args block repeats schema info. Every sentence is not strictly necessary, but it is not overly verbose.

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?

Despite having an output schema, the description does not explain the output format beyond listing fields. It lacks usage context, prerequisites, or behavior on failure. Given the complexity of file listing, more detail would be helpful.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must add meaning. It repeats parameter names and defaults but does not add new semantic info (e.g., path format, session requirements). The Args section is largely redundant with 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 it lists directory contents with specific details (permissions, owner, size, date). The verb 'list' and resource 'directory' are explicit, and it distinguishes from siblings like ssh_find_files or ssh_file_info.

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_find_files, ssh_file_info). The description only states what it does, not when it is appropriate or when to avoid it.

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

ssh_list_packagesB

List installed packages with optional filter.

Args: filter_pattern: Filter packages by name pattern session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default
`filter_pattern`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It only states the basic function without revealing behavioral traits like command execution context, permissions, or side effects. As a read operation, it could disclose that it does not modify the system.

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 concise (4 lines) with no fluff, though the 'Args' section could be formatted more tightly. It is front-loaded with the main 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 that an output schema exists (but not shown), the minimal description is acceptable for a simple list operation. However, it could mention that filtering is case-insensitive or provide an example output format.

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 0%, but the description adds meaning for both parameters: filter_pattern is described as 'Filter packages by name pattern' and session_name as 'SSH session to use,' which goes beyond the schema's titles and defaults.

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 ('list installed packages') and includes an optional filter, which distinguishes it from sibling tools like ssh_install_package or ssh_remove_package.

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 such as ssh_install_package, ssh_remove_package, or ssh_check_updates. Missing explicit when-to-use or when-not-to-use instructions.

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

ssh_list_saved_credentialsA

List all saved SSH credentials (passwords are masked for security).

Shows credentials from environment variables and cached sessions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Notes passwords are masked and shows sources (env vars, cached sessions). No annotations, so description covers key behavioral traits; no contradiction.

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 concise sentences with front-loaded purpose. Every word adds value, zero fluff.

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?

Adequately complete for a no-param list tool with output schema; covers scope and security note. Could add more but not required.

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?

No parameters; schema coverage is 100%. Baseline score applies as description adds no param info but none 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?

Description clearly states 'List all saved SSH credentials' with verb and resource, distinguishes from sibling 'ssh_save_credentials' and other list tools.

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?

Implies use case (listing saved credentials vs saving) but lacks explicit when-to-use or alternatives. Scope clarified (environment variables and cached sessions).

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

ssh_list_sessionsA

List all active SSH sessions with connection details.

Shows session name, host, username, uptime, and command count.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

Without annotations, the description carries the full burden. It correctly states the tool lists sessions and shows details, but does not explicitly state it is read-only or non-destructive. The behavior is implied but not fully transparent regarding permissions or 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 two sentences, front-loaded with the main action, and adds clarifying details without any unnecessary words. Every sentence earns its place.

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 list tool with no parameters and an output schema, the description covers what the tool does and what it returns. It lacks mention of authentication or limitations but is otherwise complete.

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?

There are no parameters, so the input schema fully covers the interface. The description does not need to add parameter details; the baseline for zero parameters is 4.

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 uses the specific verb 'List' and identifies the resource as 'all active SSH sessions', clearly distinguishing it from sibling tools like ssh_list_cron or ssh_list_users. The details on connection information (session name, host, etc.) further clarify its scope.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for listing sessions, but does not mention when not to use it or point to specific alternatives among the many sibling tools.

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

ssh_list_usersA

List system users (human accounts with login shells).

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral burden. It discloses that only human accounts with login shells are listed, which is a key filtering behavior. However, it does not mention prerequisites, side effects (e.g., read-only), or error conditions, 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 extremely concise, front-loaded with the core action, and includes parameter documentation in a clear format. Every sentence adds value 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?

Given the output schema exists, the description does not need to detail return values. However, it omits any mention of output format or error handling. For a simple tool, this is minimally adequate but could briefly state the output type (e.g., 'returns a list of usernames').

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 0%, so the description must compensate. It adds meaning by explaining that session_name specifies the SSH session to use. This is sufficient for a single parameter, though it could mention that the default is 'default'.

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 tool name and description clearly indicate it lists system users, specifically human accounts with login shells. This differentiates it from sibling tools like ssh_user_info or ssh_last_logins, providing a precise verb+resource.

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 states what it does but offers no guidance on when to use it versus alternatives (e.g., ssh_user_info). It implies usage for listing system users, but lacks explicit context or exclusions.

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

ssh_manage_serviceA

Manage a systemd service (start, stop, restart, enable, disable).

Args: service: Service name (e.g., 'nginx', 'docker') action: Action — 'start', 'stop', 'restart', 'enable', 'disable', 'reload' session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`action`	Yes
`service`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/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 burden. It lists actions but does not disclose behavioral traits such as requiring root privileges, destruction of state (e.g., enable/disable), error handling, or return value nature. This is a significant gap for a system management 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 extremely concise, using a clear list format for arguments. Every sentence adds value, and the purpose is stated first. No unnecessary 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?

The description covers the basic usage but misses important context like required privileges (root), what happens on failure, and how the output is structured. Given the tool's simplicity and existence of an output schema, it is adequate but not thorough.

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?

With 0% schema description coverage, the description adds meaning by listing parameters with examples (e.g., 'nginx' for service) and enumerating allowed actions ('start', 'stop', etc.). This compensates for the bare 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's purpose: 'Manage a systemd service (start, stop, restart, enable, disable).' It includes a specific verb ('Manage') and resource ('systemd service'), differentiating it from siblings like ssh_check_service which checks 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?

No explicit guidance on when to use this tool vs alternatives. It does not mention ssh_check_service for status checks or other service-related tools, leaving the agent to infer context without direction.

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

ssh_memory_usageB

Show detailed memory and swap usage.

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full transparency burden. It only says 'Show detailed memory and swap usage' without revealing details like command run, output format, or whether it is read-only. The term 'detailed' is vague.

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 extremely concise, using a single sentence and an args list. However, it lacks separation of concerns (e.g., mixing description and args) and could be better structured. It is not verbose but sacrifices clarity for brevity.

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 tool's simplicity (one optional param, read-only monitoring), the description is minimally adequate. However, it does not specify output beyond 'details', and while an output schema exists, the description does not reference it or set expectations.

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

Parameters2/5

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

The parameter 'session_name' is described as 'SSH session to use', which adds minimal meaning beyond the schema's title. With 0% schema coverage, the description should compensate but does not explain purpose, format, or interaction with the tool.

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 'Show detailed memory and swap usage', providing a clear verb and resource. It distinguishes itself from sibling tools like ssh_cpu_info and ssh_system_info, which focus on other system aspects.

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 given on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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

ssh_moveC

Move or rename a file/directory.

Args: source: Source path destination: Destination path session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`source`	Yes
`destination`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden of behavioral disclosure, but it fails to mention key traits like overwrite behavior, error handling, or permission requirements.

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 very concise with one sentence plus an args list. It is front-loaded, but could be slightly expanded without losing conciseness.

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?

Despite having an output schema, the description lacks essential context for a move operation (e.g., behavior on overwrites, directory moves, side effects). Incomplete for a 3-parameter tool with no annotations.

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

Parameters2/5

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

Schema coverage is 0%, meaning the description must add meaning beyond parameter names. The description only repeats parameter names ('Source path', 'Destination path') without any additional clarification (e.g., format, constraints).

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 'Move or rename a file/directory,' which is a specific verb and resource. It distinguishes from sibling tools like ssh_copy (copy) and ssh_delete (delete).

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_copy, ssh_create_directory). No prerequisites or restrictions mentioned.

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

ssh_network_infoC

Show network interfaces, IP addresses, and basic network configuration.

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/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 burden. It states the tool 'shows' data, implying read-only behavior, but does not explicitly confirm it. It lacks disclosure of any side effects, authorization needs, or limitations.

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?

Very concise two sentences. Front-loads the purpose. No extra words. However, the Args section is redundant with the schema, but that's acceptable.

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 minimal for a tool that likely returns complex network data. Although an output schema exists (not shown), the description does not hint at the return structure or any nuances like whether it shows only active interfaces, IPv4/IPv6, etc.

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

Parameters2/5

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

Schema description coverage is 0% (no parameter descriptions in schema). The description adds minimal meaning beyond the schema: 'session_name: SSH session to use' identifies the parameter as an SSH session selector, but does not explain what 'default' means or how session names are managed.

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 'Show network interfaces, IP addresses, and basic network configuration' uses a specific verb ('Show') and clearly identifies the resource (network info). It distinguishes from sibling tools like cpu_info, memory_usage, etc., which focus on other system aspects.

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. For example, it doesn't mention that this is for network-specific queries compared to general system_info or other diagnostics. No exclusions or context provided.

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

ssh_open_portsB

List all listening (open) ports and the processes using them.

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries the full burden but only states the action. It does not disclose read-only nature, required privileges, or output format. The existence of an output schema reduces the burden slightly, but the description itself lacks 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?

The description is very short (two sentences) and front-loaded with the core purpose. The 'Args:' section is a slight structure, but it could be more organized. Overall, it is concise without unnecessary detail.

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 listing tool, the description is minimally adequate. The output schema handles return values, but the description lacks usage guidance, prerequisites (active session), and behavioral details. It meets the bare minimum but misses opportunities for 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?

The description adds meaning to the sole parameter 'session_name' by stating 'SSH session to use,' which clarifies its purpose. However, schema description coverage is 0%, and the description does not elaborate on default behavior or constraints, so it only partially compensates.

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's primary function: 'List all listening (open) ports and the processes using them.' The verb 'List' and resource 'listening ports' are specific and distinct from sibling tools like ssh_check_port or ssh_process_list.

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. There is no mention of prerequisites, exclusions, or comparisons with sibling tools such as ssh_network_info or ssh_process_list.

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

ssh_pingC

Ping a host from the remote machine.

Args: target: Hostname or IP to ping count: Number of ping packets (default: 4) session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`count`	No
`target`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior1/5

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

No annotations are provided, so the description bears full responsibility. It only states the basic action without disclosing behavioral traits like blocking behavior, error handling, or output format. Even with an output schema existing, the description omits any details about what the tool returns.

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 highly concise, with a one-sentence purpose and a list of arguments. It is front-loaded and every sentence serves a purpose, though it could benefit from a bit more detail without becoming verbose.

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?

Despite having an output schema, the description does not mention return values or behavior. For a simple ping tool, basic usage is clear, but missing output context and behavioral notes make it incomplete. The lack of annotations further reduces 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?

Schema description coverage is 0%, so the description must compensate. It provides brief meanings for each parameter: 'target' as hostname/IP, 'count' as number of packets with default 4, 'session_name' as SSH session. This adds some value beyond the schema but is minimal.

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 'Ping a host from the remote machine,' which is a specific verb and resource. The tool name ssh_ping aligns perfectly, and it is distinct from sibling tools like ssh_check_port or ssh_network_info.

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_check_port or ssh_network_info. The description only states what it does without any context on prerequisites, when to prefer it, 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_process_listB

List running processes with optional filtering and sorting.

Args: session_name: SSH session to use filter_pattern: Filter processes by name/pattern (grep) sort_by: Sort by 'cpu' or 'mem' (default: no sorting)

ParametersJSON Schema

Name	Required	Default
`sort_by`	No
`session_name`	No	default
`filter_pattern`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 must disclose all behavioral traits. It only mentions optional filtering/sorting but does not cover default behavior, error handling, or read-only nature.

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 brief with a clear Args list. Every sentence adds value, but it could be slightly more informative without being verbose.

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 basics but lacks context about remote execution, session management, and error cases. The existence of an output schema reduces the need for return value details.

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?

Despite 0% schema description coverage, the description explains all three parameters: session_name, filter_pattern (grep), and sort_by (cpu/mem). This adds significant meaning 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 lists running processes with filtering and sorting. It distinguishes from sibling ssh_top_processes, which focuses on top resource-consuming processes.

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_top_processes. No prerequisites or context about SSH session requirements are 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

Read the contents of a file on the remote machine.

Args: path: Absolute path to the file session_name: SSH session to use max_lines: Maximum number of lines to read (0 = all lines)

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`max_lines`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided. The description covers basic read behavior but does not disclose error handling (e.g., missing file) or return format details. With no annotations, the description carries full burden; it provides minimum viable 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 extremely concise: one sentence for purpose, then a clear list of arguments. No redundant information; every sentence adds value.

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?

The tool is simple, and the description covers purpose and parameters well. The absence of usage guidelines is a minor gap given the many sibling file-reading tools. Output schema exists but does not need description. Overall, it's complete for a basic read operation.

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?

Although schema description coverage is 0%, the description explains all three parameters: path (absolute path), session_name (SSH session to use), and max_lines (max lines to read, 0=all). This adds meaning beyond the schema's types and defaults.

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 file contents on a remote machine. The verb 'read' and resource 'file contents' are specific, and it distinguishes from siblings like ssh_head_file, ssh_tail_file, and ssh_file_info.

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 vs siblings. There is no mention of whether to use this for full-file reads versus head/tail, or considerations like file size or performance.

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

ssh_remove_cronB

Remove cron jobs matching a pattern.

Args: pattern: Pattern to match (lines containing this will be removed) session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	Yes
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

The description implies a destructive action (removal) but does not disclose behavioral traits like whether changes are permanent, if confirmation is needed, or access requirements. With no annotations, the description should provide more context about the operation's impact.

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, using a clear one-line purpose followed by parameter descriptions. No extraneous information, well-structured for quick comprehension.

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?

Despite having an output schema, the description does not explain return values. It also lacks context on the operation's effect (e.g., immediate, persistent) and error conditions, leaving gaps for a tool that modifies remote cron jobs.

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?

While the input schema has no descriptions (0% coverage), the description adds meaning by explaining that 'pattern' is used to match lines for removal and 'session_name' identifies the SSH session. This adds value beyond the schema's titles.

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 'Remove' and the resource 'cron jobs', specifying that it removes lines matching a pattern. This distinguishes it from sibling tools like ssh_add_cron and ssh_list_cron.

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 or when not to use it. The description does not mention prerequisites, such as requiring an active SSH session.

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

ssh_remove_packageB

Remove/uninstall a package.

Args: package: Package name to remove session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`package`	Yes
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits, but it only states the action without details on side effects (e.g., dependency removal, confirmation prompts), error handling, or the need for an existing SSH session (session_name).

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 extremely concise, consisting of two short sentences. The main action is front-loaded in the first line, and the parameter descriptions are direct and free of unnecessary 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?

While the tool is simple (2 parameters, no nested objects) and an output schema is present, the description omits critical context such as prerequisite SSH sessions, package manager specifics, and potential consequences. It is adequate but not fully self-contained.

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 description adds basic meaning for both parameters beyond their schema titles, explaining that 'package' is the name to remove and 'session_name' is the SSH session. However, it does not elaborate on format, constraints, or how to obtain a session name, leaving gaps for a tool with 0% schema description 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 removes/uninstalls a package using SSH, with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like ssh_remove_cron or ssh_install_package, though the resource type 'package' provides implicit distinction.

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 offers no guidance on when to use this tool versus alternatives, such as ssh_execute for manual removal or ssh_install_package for the reverse operation. It also does not mention prerequisites like an active SSH session or required permissions.

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

ssh_save_credentialsA

Save SSH credentials for a session name (persisted to disk for future use).

Saved credentials are used for auto-reconnect and future sessions.

Args: session_name: Name to save these credentials under host: Linux server hostname or IP username: SSH username password: SSH password (leave empty if using key) key_path: Path to SSH private key port: SSH port

ParametersJSON Schema

Name	Required	Default
`host`	Yes
`port`	No
`key_path`	No
`password`	No
`username`	No	root
`session_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It mentions persistence to disk but omits important details like overwrite behavior, error handling, permissions needed, or what happens if the session already exists.

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 concise with a clear opening sentence, one extra context sentence, and a bulleted Args list. Every sentence adds value, and the structure is easy to parse.

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 complexity (6 parameters, no annotations, output schema present), the description covers the core purpose, persistence, and parameter relationships. Minor gaps exist (e.g., overwrite behavior), but overall it is sufficient for correct invocation.

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 description includes an Args section that adds meaning beyond the schema, e.g., clarifying the relationship between password and key_path ('leave empty if using key'). Although the schema has defaults, the description provides useful guidance.

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 saves SSH credentials for a session name and persists them to disk. The verb 'save' and resource 'credentials' are specific, and the purpose is distinct from sibling tools like ssh_connect or ssh_list_saved_credentials.

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 mentions credentials are used for auto-reconnect and future sessions, providing context for when to use. However, it does not explicitly differentiate from alternatives or state when not to use this tool, leaving some ambiguity.

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

ssh_search_in_filesB

Search for a pattern in files using grep.

Args: pattern: Search pattern (text or regex) path: File or directory to search in session_name: SSH session to use case_insensitive: Case-insensitive search recursive: Search recursively in directories

ParametersJSON Schema

Name	Required	Default
`path`	No	.
`pattern`	Yes
`recursive`	No
`session_name`	No	default
`case_insensitive`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/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 burden for behavioral disclosure. It states 'using grep' but does not disclose read-only nature, output format, performance implications, or how it handles binary files. The description adds little beyond the parameter list.

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: a single-line header followed by a clean bulleted list of arguments. Every element serves a purpose with 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?

The tool has 5 parameters and 1 required, with no annotations but an output schema. The description covers the basic purpose and parameters but omits details like that it operates over SSH (implied by session_name), return behavior, or handling of recursive/case-sensitive search (though these are parameter defaults). Adequate but not thorough.

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 0%, and the description adds brief explanations for each parameter (e.g., 'Search pattern (text or regex)', 'File or directory to search in'). This provides some meaning beyond parameter names, but does not fully compensate for the lack of schema 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 'Search for a pattern in files using grep' clearly states the verb 'search', the resource 'files', and the method 'using grep'. This distinguishes it from sibling tools like ssh_find_files or ssh_search_logs, which have different search approaches.

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 versus alternatives, nor does it mention when not to use it. There is no comparison to sibling tools such as ssh_find_files or ssh_grep, leaving the agent to infer usage context.

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

ssh_search_logsB

Search system logs using journalctl or grep.

Args: pattern: Search pattern log_path: Specific log file path (if empty, uses journalctl) session_name: SSH session to use since: Time filter for journalctl (e.g., '1 hour ago', '2024-01-01', 'today')

ParametersJSON Schema

Name	Required	Default
`since`	No
`pattern`	Yes
`log_path`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior3/5

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

The description explains the dual behavior (journalctl vs grep) based on the log_path parameter, which adds transparency. However, it omits important behaviors such as authentication requirements (e.g., sudo for journalctl), performance implications, or error handling. With no annotations, more detail is expected.

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 concise with a clear Args list. It avoids unnecessary fluff. Could be improved by formatting the Args more descriptively, but overall it's efficient.

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?

Despite an output schema (not shown), the description does not mention the format or content of the search results. Given the complexity of log searching (e.g., large outputs, truncation), this is a significant gap. The tool has 4 parameters but only partial behavior is documented.

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 0%, so the description must compensate. It adds meaning for 'log_path' (selects grep vs journalctl) and 'since' (time filter for journalctl). However, 'pattern' and 'session_name' get no extra explanation beyond their names, leaving ambiguity.

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 says 'Search system logs using journalctl or grep', which is a specific verb and resource. It distinguishes itself from the sibling 'ssh_search_in_files' (which searches files generally) by focusing on system logs. However, it does not explicitly differentiate from all siblings.

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_search_in_files' or other log-related tools. It also does not explain when to choose journalctl vs grep based on context.

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

ssh_sed_replaceB

Find and replace text in a file using sed.

Args: file_path: Path to the file find: Text pattern to find replace: Replacement text session_name: SSH session to use backup: Create a .bak backup before modifying (default: True)

ParametersJSON Schema

Name	Required	Default
`find`	Yes
`backup`	No
`replace`	Yes
`file_path`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must fully disclose behavior. It mentions backup creation but does not clarify that the tool modifies files destructively, potential impacts of regex patterns, or error handling. Minimal behavioral disclosure.

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 concise with a clear action statement followed by parameter list. No unnecessary text, but could be better structured with warnings or usage notes.

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?

Despite simple functionality, the description lacks completeness: no mention of sed's regex capabilities, effects on file, or when to prefer this over related tools. With many siblings, more context is needed.

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 0%, but description provides brief explanations for each parameter (e.g., backup creates .bak). However, these explanations are minimal and do not add significant detail beyond parameter names and types.

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 tool name and description clearly state it finds and replaces text in a file using sed. The action is specific and distinct from siblings like ssh_write_file, which writes entire content, or ssh_search_in_files, which only searches.

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 vs alternatives such as ssh_write_file or manual editing. Lacks context for appropriate usage scenarios or prerequisites.

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

ssh_system_infoC

Get comprehensive system information (OS, kernel, CPU, RAM, uptime, hostname).

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must bear full behavioral disclosure. It only states the tool gets system info, with no mention of side effects, permissions, error behavior, or limitations. The read-only nature is implicit but not explicitly safe.

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?

Description is concise (two sentences) with the main purpose front-loaded. No redundant information; structure is efficient.

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 that an output schema exists (as per context signals), the description sufficiently covers the tool's purpose for a straightforward read-only operation. Could mention it aggregates multiple info types in one call, but not critical.

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

Parameters2/5

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

Schema coverage is 0%, and the description only repeats the parameter name and type ('SSH session to use') without adding format details, default behavior, or how to specify sessions. Adds minimal value beyond the schema's title.

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?

Description clearly states it retrieves comprehensive system information listing specific categories (OS, kernel, CPU, RAM, etc.). It distinguishes from more specific sibling tools like ssh_cpu_info or ssh_memory_usage by being comprehensive, but does not explicitly name them.

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_cpu_info, ssh_memory_usage). The description only mentions the session parameter, lacking context on appropriate usage scenarios.

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

ssh_system_loadA

Show system load averages (1, 5, 15 minutes) and running process count.

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states what data is shown (load averages and process count), implying it is a read-only, safe operation. However, it does not explicitly confirm it is non-destructive, describe permissions required, or mention that an active SSH session is needed. The existence of an output schema likely covers return format, but the description could still be clearer about safety.

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 extremely concise: one sentence for purpose and one line for the argument. Every word is necessary, and the structure front-loads the core functionality. There is no redundancy or irrelevant information, making it efficient for an AI agent 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?

Given the tool's low complexity (one optional parameter) and the presence of an output schema, the description is mostly adequate. However, it lacks any mention of prerequisites (e.g., an active SSH session), potential error conditions, or how the tool integrates with the SSH workflow. A slightly more complete description would include a reference to session management.

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 one parameter (session_name) with no description, and schema description coverage is 0%. The description's Args line adds meaning by stating 'session_name: SSH session to use,' which clarifies its purpose. While it's a simple parameter, this addition compensates for the schema's lack of description. More detail (e.g., default session behavior) would have earned a 5.

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 'Show system load averages (1, 5, 15 minutes) and running process count.' It uses a specific verb and resource, and the output is well-defined. Among sibling tools like ssh_cpu_info, ssh_memory_usage, and ssh_system_info, this tool is uniquely identified by focusing on load averages, making its purpose 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?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it. For example, it does not advise using this tool for quick system health checks or contrast it with more comprehensive tools like ssh_system_info. This lack of usage direction reduces its helpfulness for an AI agent.

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

ssh_tail_fileA

Get the last N lines of a file (useful for logs).

Args: path: Path to the file lines: Number of lines from the end (default: 50) session_name: SSH session to use

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`lines`	No
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

Describes the read-only operation, but no annotations provided. Does not disclose potential behaviors like error handling or file size limits, though basic enough.

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?

Short and front-loaded with purpose. The 'Args' section is helpful but could be more concise. Overall efficient.

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?

Simple tool with output schema present. Description covers main functionality and parameters sufficiently for typical use.

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?

Description adds meaning beyond schema by explaining each parameter (path, lines with default, session_name). Compensates for zero schema coverage effectively.

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?

Clearly states 'Get the last N lines of a file' with specific use case 'useful for logs'. Distinguishes from siblings like ssh_head_file 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 Guidelines3/5

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

Implies usage for tailing logs but does not explicitly state when to use vs alternatives or when not to use. No mention of exclusion criteria.

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

ssh_top_processesA

Show top N processes by CPU or memory usage.

Args: session_name: SSH session to use count: Number of processes to show (default: 10) sort_by: Sort by 'cpu' or 'mem' (default: 'cpu')

ParametersJSON Schema

Name	Required	Default
`count`	No
`sort_by`	No	cpu
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It indicates a read-only operation (showing processes), but does not explicitly state that no system changes are made or that an active SSH session is required (implied by session_name parameter).

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 very concise: one line summary followed by a clear list of argument explanations. Every sentence is necessary and front-loaded. No redundancy.

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 existence of an output schema, return values need not be explained. However, the description does not mention prerequisites like an active SSH session or saved credentials, which are implicit but not explicit. The tool likely requires a session, and this could be clarified.

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 0%, but the description adds helpful comments for each parameter: stating defaults and possible values for 'sort_by'. This adds meaning beyond the schema's type and default definitions.

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 'Show top N processes by CPU or memory usage' with a specific verb and resource. It distinguishes from siblings like 'ssh_process_list' (likely lists all processes) and 'ssh_cpu_info' (system-wide CPU info).

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 like 'ssh_process_list' or 'ssh_memory_usage'. It implicitly is for monitoring top processes, but lacks explicit context or exclusions.

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

ssh_user_infoB

Get detailed information about a specific user.

Args: username: Username to look up session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It only states the basic function without disclosing behavioral traits like read-only nature, permissions required, or what 'detailed information' includes. The output schema exists but is not described.

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 short and to the point, with no wasted words. However, the 'Args' section is redundant with the schema and could be removed for better structure.

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 nature of the tool and the presence of an output schema, the description is adequate but incomplete. It does not explain when to use this tool over similar info tools, leaving some contextual gaps.

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 0%, but the description adds meaning for both parameters ('username' and 'session_name'), explaining their roles. It compensates for the schema gaps, though it doesn't note the default value for session_name.

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 'Get detailed information about a specific user' with a specific verb and resource, distinguishing it from sibling tools like ssh_list_users (list all users) and ssh_whoami (current user).

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 such as ssh_list_users or ssh_whoami. The description lacks context for selection among many sibling tools.

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

ssh_whoamiB

Show current user, groups, and environment info.

Args: session_name: SSH session to use

ParametersJSON Schema

Name	Required	Description	Default
`session_name`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose behavioral traits like whether an active session is required, error handling, or side effects. The description is minimal.

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?

Description is short and front-loaded with the main purpose. The Args section is minimal but structured. Could be improved by separating the purpose and parameters more clearly.

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 an output schema exists, return values need not be explained. However, missing context about when to use this tool over similar ones and lack of behavioral details leave gaps.

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 0% but description adds 'SSH session to use' for session_name. This clarifies the parameter's role but does not explain default behavior or valid values.

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?

Description clearly states the verb 'Show' and the resources: current user, groups, and environment info. This distinguishes it from sibling tools like ssh_user_info or ssh_system_info by implying a combined summary.

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_user_info or ssh_system_info. No context provided about prerequisites or typical use cases.

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

ssh_write_fileA

Write content to a file on the remote machine.

Args: path: Absolute path to the file content: Content to write session_name: SSH session to use append: If True, append to file instead of overwriting

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`append`	No
`content`	Yes
`session_name`	No	default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

The description lacks behavioral details beyond the basic operation. It does not mention file creation, permission requirements, error handling, or whether the file is truncated on write. With no annotations, more transparency is expected.

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 concise and well-structured, with a clear purpose sentence and an 'Args' section listing parameters. It avoids redundancy and is appropriately sized for the tool's simplicity.

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 operation but lacks information about return values (though an output schema exists) and preconditions like an active SSH session. It is adequate for a simple write operation but not fully comprehensive.

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?

Despite 0% schema description coverage, the description explicitly explains each parameter: path, content, session_name, and the append flag. This adds significant meaning beyond the bare schema, helping an agent understand usage.

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 'Write content to a file on the remote machine,' clearly indicating the verb (write) and resource (file). This purpose is distinct from sibling tools like ssh_read_file, ssh_delete, and others, making it easy for an agent to select the correct tool.

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 such as ssh_execute for echoing content, or prerequisites like ensuring an active SSH session. The agent receives no contextual hints for decision-making.

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.

62 tool updatesv1.0.0Jul 15, 2026
- First observedssh_add_cron
- First observedssh_change_owner
- First observedssh_check_port
- First observedssh_check_service
- First observedssh_check_updates
- First observedssh_compress
- First observedssh_connect
- First observedssh_copy
- First observedssh_cpu_info
- First observedssh_create_directory
- First observedssh_delete
- First observedssh_disconnect
- First observedssh_disconnect_all
- First observedssh_disk_file_usage
- First observedssh_disk_usage
- First observedssh_dns_lookup
- First observedssh_docker_compose
- First observedssh_docker_exec
- First observedssh_docker_images
- First observedssh_docker_inspect
- First observedssh_docker_logs
- First observedssh_docker_ps
- First observedssh_docker_stats
- First observedssh_execute
- First observedssh_execute_background
- First observedssh_execute_script
- First observedssh_extract
- First observedssh_failed_logins
- First observedssh_file_info
- First observedssh_file_permissions
- First observedssh_find_files
- First observedssh_head_file
- First observedssh_install_package
- First observedssh_kill_process
- First observedssh_last_logins
- First observedssh_list_cron
- First observedssh_list_directory
- First observedssh_list_packages
- First observedssh_list_saved_credentials
- First observedssh_list_sessions
- First observedssh_list_users
- First observedssh_manage_service
- First observedssh_memory_usage
- First observedssh_move
- First observedssh_network_info
- First observedssh_open_ports
- First observedssh_ping
- First observedssh_process_list
- First observedssh_read_file
- First observedssh_remove_cron
- First observedssh_remove_package
- First observedssh_save_credentials
- First observedssh_search_in_files
- First observedssh_search_logs
- First observedssh_sed_replace
- First observedssh_system_info
- First observedssh_system_load
- First observedssh_tail_file
- First observedssh_top_processes
- First observedssh_user_info
- First observedssh_whoami
- First observedssh_write_file

Install Server

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

TDQS

B3.4/5.0

Disambiguation5/5

Every tool has a clearly distinct purpose, even among similar operations like ssh_execute variants or process listing tools. Descriptions sufficiently differentiate them.

Naming Consistency5/5

All tools follow a consistent 'ssh_verb_noun' pattern using snake_case, with only minor deviations like ssh_whoami which is a standard command.

Tool Count2/5

62 tools is excessive for easy navigation, exceeding the typical well-scoped range. While the server aims to be comprehensive, many tools could be merged (e.g., multiple system info commands).

Completeness5/5

The tool surface is extremely comprehensive, covering file operations, system monitoring, Docker, package management, networking, cron, and more. No obvious gaps for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1
KodyOAuth
io.github.kentcdodds
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2514
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2

Related MCP Servers

SSH MCP Server
Shell Access Code Execution
vilasone455
F
license
A
quality
D
maintenance
A local Model Context Protocol server that allows LLMs to securely execute shell commands on remote Linux and Windows systems via SSH connections.
Updated a year ago (2025-05-27 06:59 UTC)
6
17
2
-
SSH MCP Server
Shell Access Command Line OS Automation
tufantunc
A
license
A
quality
A
maintenance
A Model Context Protocol server that allows LLMs to securely execute shell commands on remote Linux and Windows systems via SSH. It supports password and key-based authentication, command timeouts, and sudo elevation for administrative tasks.
Updated 2 days ago (2026-09-04 06:30 UTC)
11
14,123
688
MIT
Simple SSH MCP Server
Shell Access Command Line OS Automation
bhayanak
A
license
Not graded
quality
D
maintenance
An MCP server that gives AI assistants full SSH/SFTP remote operations — session management, command execution, interactive shells, file transfers, port forwarding, and system diagnostics.
Updated 5 months ago (2026-04-17 09:50 UTC)
2
MIT
mcp-ssh-tool
Shell Access Command Line OS Automation
skot
A
license
B
quality
D
maintenance
A Model Context Protocol (MCP) SSH client server that provides autonomous SSH operations for GitHub Copilot and VS Code. Enable natural language SSH automation without manual prompts or GUI interactions.
Updated 6 months ago (2026-03-06 22:25 UTC)
20
1
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/Pawangunjkar/linux-ssh-mcp'

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

🐧 Linux SSH MCP Server

📋 Table of Contents

🌐 Overview

How is this different from just "running commands"?

✨ Key Features

📥 Quick Install

Option 1: PyPI / uvx (Recommended)

Option 2: Smithery

Option 3: Clone from GitHub

🏗 Architecture

📦 Prerequisites

1. Python 3.10 or higher

2. uv (Python Package Manager by Astral)

3. A Remote Linux Server with SSH Access

🚀 Installation & Setup

Step 1: Navigate to the project directory

Step 2: Install dependencies

Option A: Using uv (Recommended)

Option B: Using Standard Python venv & pip

Step 3: Verify the installation

If using uv:

If using standard venv (make sure the virtual environment is activated):

Step 4 (Optional): Test with MCP Inspector

🔌 Configuring Your AI IDE

Understanding the Configuration

1. 🖱 Cursor

Project-Level Configuration (Recommended)

Global Configuration

Without Environment Variables (Interactive Mode)

Verifying in Cursor

2. 🤖 Claude Desktop

Configuration File Location

Configuration

Verifying in Claude Desktop

3. 🌀 Antigravity (Google DeepMind)

Configuration

Steps

4. 💻 VS Code with Continue / Cline

Continue Extension

Cline Extension

5. 🏄 Windsurf

Configuration File Location

Configuration

Steps

⚡ How It Works

Startup Flow

Connection Flow

For Manual Testing / Debugging

🔐 Environment Variables

Authentication Priority

📖 Complete Tool Reference

Category 1: Session & Authentication (6 tools)

🔧 ssh_connect

🔧 ssh_disconnect

🔧 ssh_disconnect_all

🔧 ssh_list_sessions

🔧 ssh_save_credentials

🔧 ssh_list_saved_credentials

Category 2: Command Execution (3 tools)

🔧 ssh_execute

🔧 ssh_execute_script

🔧 ssh_execute_background

Category 3: File & Directory Operations (12 tools)

🔧 ssh_list_directory

🔧 ssh_create_directory

🔧 ssh_read_file

🔧 ssh_write_file

🔧 ssh_delete

🔧 ssh_move

🔧 ssh_copy

🔧 ssh_file_info

🔧 ssh_file_permissions

🔧 ssh_change_owner

🔧 ssh_find_files

🔧 ssh_disk_file_usage

Category 4: Log & Search (5 tools)

🔧 ssh_search_in_files

🔧 ssh_tail_file

🔧 ssh_head_file

🔧 ssh_search_logs

Option A: Using `uv` (Recommended)

Option B: Using Standard Python `venv` & `pip`

If using `uv`:

If using standard `venv` (make sure the virtual environment is activated):

🔧 `ssh_connect`

🔧 `ssh_disconnect`

🔧 `ssh_disconnect_all`

🔧 `ssh_list_sessions`

🔧 `ssh_save_credentials`

🔧 `ssh_list_saved_credentials`

🔧 `ssh_execute`

🔧 `ssh_execute_script`

🔧 `ssh_execute_background`

🔧 `ssh_list_directory`

🔧 `ssh_create_directory`

🔧 `ssh_read_file`

🔧 `ssh_write_file`

🔧 `ssh_delete`

🔧 `ssh_move`

🔧 `ssh_copy`

🔧 `ssh_file_info`

🔧 `ssh_file_permissions`

🔧 `ssh_change_owner`

🔧 `ssh_find_files`

🔧 `ssh_disk_file_usage`

🔧 `ssh_search_in_files`

🔧 `ssh_tail_file`

🔧 `ssh_head_file`

🔧 `ssh_search_logs`

🔧 `ssh_sed_replace`

🔧 `ssh_system_info`

🔧 `ssh_disk_usage`

🔧 `ssh_memory_usage`

🔧 `ssh_cpu_info`

🔧 `ssh_process_list`

🔧 `ssh_top_processes`

🔧 `ssh_kill_process`

🔧 `ssh_system_load`

🔧 `ssh_network_info`

🔧 `ssh_open_ports`

🔧 `ssh_check_port`

🔧 `ssh_ping`

🔧 `ssh_dns_lookup`

🔧 `ssh_docker_ps`

🔧 `ssh_docker_logs`

🔧 `ssh_docker_exec`

🔧 `ssh_docker_images`

🔧 `ssh_docker_stats`

🔧 `ssh_docker_compose`

🔧 `ssh_docker_inspect`

🔧 `ssh_install_package`

🔧 `ssh_remove_package`

🔧 `ssh_list_packages`

🔧 `ssh_check_updates`

🔧 `ssh_list_users`

🔧 `ssh_user_info`

🔧 `ssh_whoami`

🔧 `ssh_last_logins`

🔧 `ssh_list_cron`

🔧 `ssh_add_cron`

🔧 `ssh_remove_cron`

🔧 `ssh_compress`

🔧 `ssh_extract`

🔧 `ssh_check_service`

🔧 `ssh_manage_service`

🔧 `ssh_failed_logins`