Skip to main content
Glama
Sign In
ssh-licco

ssh-licco

by Echoqili
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ssh_connect

Establish an SSH connection to a remote server using password, private key, or agent authentication; optionally run a command and save settings for future sessions.

Instructions

Establish an SSH connection to a remote server. If no parameters are provided, auto-connects using environment variables or saved config. Supports password, private key, and agent authentication. Optionally save the config and/or execute a command after connecting.

Input Schema

NameRequiredDescriptionDefault
hostNoSSH server hostname or IP. If omitted, auto-reads from env vars or saved config.
nameNoUse a pre-configured host from hosts.json by name.
portNoSSH port
commandNoOptional command to execute immediately after connecting.
passwordNoSSH password for password-based auth.
usernameNoSSH username. If omitted, auto-reads from env vars.
passphraseNoPassphrase for encrypted private key.
auth_methodNoAuthentication method.private_key
save_configNoSave connection settings to local config file for future use.
sudo_passwordNoSudo password (optional). When set, ssh_execute with use_sudo=true will auto-wrap commands with sudo -S, avoiding plaintext password in process list.
known_hosts_pathNoOptional trusted known_hosts file, in addition to the user's default known_hosts.
private_key_pathNoPath to private key file for key-based auth.
accept_new_host_keyNoExplicitly opt in to accepting unknown host keys. Disabled by default; provision trusted known_hosts before connecting.
strict_host_key_checkingNoReject hosts absent from known_hosts. Keep enabled in production.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.8.0
    • changedInput schema / properties / accept_new_host_key / default
      Previous value: -trueNew value: +false
    • changedInput schema / properties / accept_new_host_key / description
      Previous value: -"Auto-accept new host keys."New value: +"Explicitly opt in to accepting unknown host keys. Disabled by default; provision trusted known_hosts before connecting."
    • addedInput schema / properties / known_hosts_path
      Added value: +{
+  "description": "Optional trusted known_hosts file, in addition to the user's default known_hosts.",
+  "type": "string"
+}
    • addedInput schema / properties / strict_host_key_checking
      Added value: +{
+  "default": true,
+  "description": "Reject hosts absent from known_hosts. Keep enabled in production.",
+  "type": "boolean"
+}
  2. First observedv2.7.2

TDQS

B3.4/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 discloses auto-connect behavior, supported auth methods, and optional saving/command execution, but omits important traits: session persistence, return value or connection handle, failure behavior, and side effects of save_config writing to disk.

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?

Four sentences, front-loaded with the main action. Each sentence contributes information, and there is no filler. It could be slightly more structured or scannable, but it is efficient overall.

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 14 parameters, no annotations, and no output schema, the description covers the main behavior but leaves gaps. It does not explain what the tool returns, how the session lifecycle works, or how it interacts with siblings like ssh_disconnect and ssh_execute, which an agent would need for confident use.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all 14 parameters. The description repeats the auto-read behavior for host/username and lists auth methods, but adds no syntax, format, or interaction details beyond what the schema provides. Baseline 3 is appropriate.

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

Purpose4/5

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

States a specific verb and resource: 'Establish an SSH connection to a remote server.' The purpose is clear, but it does not explicitly distinguish itself from siblings such as ssh_execute or ssh_disconnect, leaving the agent to infer the boundary.

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 auto-connection when no parameters are provided and optional command execution after connecting, which gives some usage context. However, it never explicitly says when to use this tool versus ssh_execute or ssh_disconnect, and offers no exclusions or alternative-routing guidance.

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

Deploy Server

Other Tools