Skip to main content
Glama
cygnussystems

cygnus-ssh-mcp

Official

ssh_file_copy

Copy a file from one remote path to another over SSH, with optional sudo and timestamped destination backups; use for remote-to-remote operations, not local transfers.

Instructions

Copy a file on the remote host (source and destination are both remote paths - for local<->remote transfers use ssh_file_transfer instead).

If append_timestamp=True, a timestamp is inserted before the destination's file extension in the format %Y%m%dT%H%M%S, e.g. destination_path="/etc/hosts.bak" becomes /etc/hosts.20260704T153045.bak - not appended after the extension, and not configurable to a different format.

Returns: On success: {'success': True, 'copied_to': <actual destination path used, including the timestamp if applied>}. On failure (source not found, permission error): {'success': False, 'error': str} - not a raised exception.

Long-running calls: if this takes longer than the server's wait cap (default 50s), it
returns {"status": "in_progress", "handle_id": ...} instead of the result - the work keeps
running. Get the result by polling ssh_cmd_check_status(handle_id=...), which returns this
tool's normal response once finished. Do not call it again meanwhile. Only one such
operation runs at a time; another one started meanwhile fails with a 'busy' error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
use_sudoNoUse sudo for the operation
source_pathYesSource file path
append_timestampNoWhether to append a timestamp to the destination
destination_pathYesDestination file path

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A4.8/5.0
Behavior5/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 and does so thoroughly: it declares that failures return a dict rather than raising, that the timestamp is non-configurable and inserted before the extension, the default 50s wait cap, the in_progress/handle_id escape hatch, the polling tool to use, and the single-concurrent-operation 'busy' constraint.

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?

Front-loads purpose and the sibling exclusion first, then appends behavioral detail in clearly labeled Returns / Long-running blocks. It is longer than average but nearly every sentence conveys a constraint an agent needs; only minor tightening of the timestamp prose would help.

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

Completeness5/5

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

For a mutation tool with no annotations, the description supplies the missing safety and control context: failure-not-exception semantics, non-reversibility-adjacent details of timestamping, concurrency limits, and the async handoff. Even though an output schema exists, the added return-shape detail is accurate and 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 description coverage is 100%, so the baseline is 3, but the description goes well beyond the schema on append_timestamp by spelling out the exact format (%Y%m%dT%H%M%S), the insertion point (before the extension), and a concrete example, while flagging what it is not (not appended after, not configurable). use_sudo and the path params get no additional treatment, keeping it just short of 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?

States a specific verb (copy) and resource (file on remote host) and immediately scopes it: 'source and destination are both remote paths'. It names the sibling it is not (ssh_file_transfer) and the condition that selects that sibling (local<->remote), so an agent can distinguish it without opening any schema.

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

Usage Guidelines5/5

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

Provides an explicit when-to-use-this vs when-to-use-the-alternative rule ('for local<->remote transfers use ssh_file_transfer instead'), plus the operational condition for the long-running path ('if this takes longer than the server's wait cap...'). Nothing is left to inference.

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