Skip to main content
Glama

ssh_upload

DestructiveIdempotent

Copy a local file or directory to a remote server over SSH, atomically renaming the uploaded data and verifying it with sha256 so no half-written file ever appears.

Instructions

Copies a local file or directory to a server. Data lands under a temporary name and takes its place in one rename, verified by sha256 — a half-written file never appears at the target. A directory replaces the target whole, not file by file, and sudo stages in /tmp first, so the machine needs room for a second copy, and setting an owner needs it too. For text you can paste, ssh_file_write is cheaper; piping base64 through ssh_exec truncates silently.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoOctal, one value for every file sent. Omit to keep local permissions.
sudoNoFor /etc, /opt and the like. Data stages in /tmp first — the machine needs room for a second copy. Default: false
ownerNo"root:root", every file sent. Needs sudo; without it the answer says it was not applied.
verifyNosha256 on both sides, per file. "unavailable" = no sha256 on the machine = delivered, not broken. Default: true
profileYesMachine name.
timeoutNoMilliseconds. No ceiling by default — a transfer runs as long as it takes.
overwriteNofalse = refuse rather than replace, including when the target cannot be checked. A directory is judged whole, not per file. Default: true
recursiveNoOnly to force it — a directory is recognised on its own.
local_pathYesA file or a directory on this machine.
remote_pathYesWhere it goes on the server. A sent directory becomes this path itself and replaces it whole, not file by file.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesNo
legendNoWhat the words in this answer mean. A key names the field before the value — "state=limited", "jobs[].state=lost" — and only the values this answer actually used are listed.
Behavior5/5

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

The description discloses critical behaviors beyond the annotations: atomic rename with sha256 verification, directory replacement whole rather than file-by-file, /tmp staging for sudo, disk space implications, and owner permission requirements. This goes far beyond the basic idempotent/destructive hints, providing exact operational expectations.

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?

Four sentences, each packed with necessary information: the core operation, the atomicity guarantee, directory replacement and sudo caveats, and tool selection guidance. No word is wasted, and the most crucial details are front-loaded in the first sentence.

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?

Given the tool's destructive nature (destructiveHint: true) and 10 parameters, the description covers all key operational aspects: atomicity, verification, directory behavior, disk space, ownership, and alternatives. Combined with a complete schema and output schema, an agent has everything needed to invoke it correctly.

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 schema coverage is 100%, the description adds meaningful behavioral context to parameters like sudo (staging in /tmp), owner (requires sudo), and verify (sha256), explaining consequences not obvious from schema alone. It doesn't enumerate parameters but enriches understanding of their side effects, which is more valuable than simple restatement.

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 opening sentence, 'Copies a local file or directory to a server,' uses a specific verb and resource, immediately clarifying the tool's function. It also distinguishes itself from siblings by explicitly contrasting with ssh_file_write and ssh_exec, making its role unmistakable.

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?

The description explicitly states when to use alternatives: 'For text you can paste, ssh_file_write is cheaper; piping base64 through ssh_exec truncates silently.' This gives clear conditions for choosing this tool over its siblings, leaving no ambiguity about context.

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

Install Server

Other Tools

Latest Blog Posts

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/hypnosis/ssh-mcp-server'

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