Skip to main content
Glama

ssh_exec

Destructive

Run shell commands on a remote server over SSH, capturing exit codes and output. Supports single or multiple commands, detached background jobs, and sudo.

Instructions

Runs one command or a list of them on a server and returns the exit code, stdout and stderr of each. Every command gets its own shell, so a variable set or a directory entered in one is gone in the next. Work measured in minutes should be detached rather than given a longer timeout: a detached call returns a job id at once and outlives this request. Reach for it last — files, logs, transfers, health and jobs each have a tool that batches the round trips and parses the answer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoDirectory to start in, detached jobs included. Cannot be entered -> the command stops, it does not run elsewhere.
sudoNoExecute command(s) with sudo. Default: false
detachNoBackground job on the server: returns an id at once, outlives this call, timeout does not apply. Follow with ssh_job_status / ssh_job_output, stop with ssh_job_kill. One command. With sudo the job runs as root and every later call follows it as root, provided the profile has a password or sudo needs none. Default: false
commandYesOne command, or a list: ["hostname", "whoami"]. Each runs in its own shell — no shared variable, no shared cd; cwd applies to all. A non-zero exit does not stop the list.
profileYesMachine name.
timeoutNoMilliseconds, per command in a list, not for the whole list; default 30000. Work measured in minutes -> detach, not a bigger number.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idNo
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.
commandsNo
Behavior4/5

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

Annotations already carry destructiveHint=true, so the tool's risk profile is available. The description adds genuinely useful runtime behavior: every command runs an independent shell, so variables and cd are not shared across entries, and detached commands outlive the requesting call and return a job id. This goes beyond what the annotations alone communicate.

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?

Every sentence earns its place: the first states what the command returns, the second captures the shell-isolation caveat, the third gives the long-running work guidance, and the fourth points to better alternatives. It is tight, front-loaded, and free of filler.

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 tool with six parameters, an output schema, and a destructive annotation, the description covers the key behavioral risks, the shell semantics, the detach path, and the existence of specialized sibling tools. The parameter docs and output schema carry the remaining details, so nothing essential for correct invocation is missing.

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 baseline is 3. The description reinforces the command-list semantics and timeout/detach tradeoff, but it largely paraphrases what the parameter docs already say rather than revealing new parameter-specific meaning.

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 is explicit: 'Runs one command or a list of them on a server and returns the exit code, stdout and stderr of each.' It names the verb, the resource, and the observable result. The closing instruction 'Reach for it last' distinguishes it from the specialized file, log, transfer, health, and job tools.

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 gives explicit when-to-use guidance: long work in minutes should be detached rather than given a longer timeout. It also provides clear when-not-to-use direction by pointing to dedicated tools for files, logs, transfers, health, and jobs that batch round trips and parse answers.

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