Skip to main content
Glama
Sign In
ssh-licco

ssh-licco

by Echoqili
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ssh_file_transfer

Transfer and manage files between local and remote servers via SFTP: upload, download, list, write, append, delete, create directories, inspect stats, and copy directly server-to-server.

Instructions

Transfer and manage files between local and remote server via SFTP. Supports upload, download, list, write (write content directly to remote file), append, delete, mkdir, stat, and remote_copy (server-to-server direct transfer via scp/rsync, avoiding local relay).

Input Schema

NameRequiredDescriptionDefault
hostNoSSH server hostname or IP. Alternative to session_id/name, can override hosts.json entry.
nameNoUse a pre-configured host from hosts.json by name. Alternative to session_id.
portNoSSH port (used with host).
contentNoContent to write/append to remote file. Required for write/append.
passwordNoSSH password (used with host).
usernameNoSSH username (used with host).
directionYesAction: upload, download, list, write (content->remote file), append, delete, mkdir, stat, remote_copy (server-to-server direct transfer).
use_rsyncNoremote_copy: Use rsync instead of scp (better for large directories, supports resume).
local_pathNoLocal file path. Required for upload/download.
session_idYesActive SSH session ID. If omitted, connects via name/host/env vars.
remote_pathNoRemote file/directory path. Required for all directions. For remote_copy, this is the source path on the connected server.
target_hostNoremote_copy: Target server hostname/IP.
target_pathNoremote_copy: Destination path on target server.
target_portNoremote_copy: Target SSH port.
target_userNoremote_copy: Target SSH username.root
target_passwordNoDeprecated: password-based remote_copy is disabled. Configure key-based authentication on the source server.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.8.0
    • changedInput schema / properties / target_password / description
      Previous value: -"remote_copy: Target server password (uses sshpass). If omitted, assumes key-based auth is configured."New value: +"Deprecated: password-based remote_copy is disabled. Configure key-based authentication on the source server."
  2. First observedv2.7.2

TDQS

A3.6/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, yet it says nothing about the destructive/irreversible nature of delete, whether upload overwrites existing files, whether mkdir creates parent directories, or what authentication constraints apply. Only the remote_copy relay behavior is disclosed, and that detail is already repeated in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The core purpose is front-loaded in the first clause, and the long operation enumeration is dense but informative rather than filler. It is appropriately sized for a nine-direction tool, though the list partially duplicates the direction enum.

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?

With 16 parameters, no annotations, and no output schema, the description is complete on the 'what operations exist' axis but silent on results (what stat or list returns) and on safety semantics for delete/upload. The rich schema covers parameter-level details, so the gap is behavioral rather than structural.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents every parameter including the remote_copy target_* set and the deprecated target_password. The description adds modest value by clarifying that write accepts content directly and that remote_path is the source path for remote_copy, but goes no further than 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 states a specific verb and resource ('Transfer and manage files ... via SFTP') and enumerates all nine supported operations, including the non-obvious remote_copy variant. It is clearly distinguishable from the ssh_execute/ssh_process siblings, which run commands rather than move files.

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?

It gives real selection guidance inside the tool: remote_copy is for server-to-server, 'avoiding local relay', which tells the agent not to chain upload+download. It does not say when to prefer this tool over ssh_execute or when a direction is inappropriate, so it stops short of explicit when-not 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