Skip to main content
Glama

ssh_execute

Destructive

Execute a single command on a Linux host via SSH with ephemeral credentials, capturing stdout, stderr, and exit code.

Instructions

Execute a single command on a Linux host via SSH with an ephemeral credential. Prefer this tool over ssh_session_open when you only need to run one command or independent commands. Returns stdout, stderr and exit_code. exit_code != 0 means remote command failure, NOT a tool error; treat it like a process that exits with an error. BEFORE calling: use ssh_list_servers to learn the host capabilities. sudo=true ONLY if allow_sudo=true; if allow_sudo=false, DO NOT retry with sudo and inform the user. pty=true ONLY if allow_pty=true and the command needs a TTY (with pty, stdout and stderr are merged). ttl_seconds is optional; omit to use the maximum allowed by the host policy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ptyNoif true, request a pseudo-terminal (stdout and stderr are merged). Requires allow_pty=true in ssh_list_servers. Use only for commands that need a TTY. If allow_pty=false DO NOT retry.
sudoNoif true, execute with sudo -n (NOPASSWD). Requires allow_sudo=true in ssh_list_servers. If allow_sudo=false DO NOT retry: inform the user that the host does not allow elevation.
serverYeslogical name of the target host (see ssh_list_servers)
commandYescommand to execute on the host
dry_runNoif true, SIMULATE: check whether the command would be allowed by the host policy (allow/deny and whether it requires approval) WITHOUT executing it. Does not connect to the host or produce stdout. Useful to preview before executing.
sudo_userNotarget user for sudo (empty = root). Must be in the host's allowed_sudo_users list.
ttl_secondsNoephemeral certificate validity in seconds; omit to use the maximum allowed by the host policy

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
serialYesaudit identifier; ignore when reasoning about the result
stderrYeserror output of the remote command (empty when pty=true, since stdout and stderr are merged)
stdoutYesstandard output of the remote command
decisionNopresent only on a dry_run: the policy decision (allow/deny/approval) with a machine-readable reason_code, instead of executed output
warningsNoadvisory warnings; command_policy audit-mode warnings mean the command was allowed but would have been blocked or approval-gated in enforce mode
exit_codeYesexit code of the remote command: 0=success, non-zero=command failure (NOT a tool error)
Behavior5/5

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

Beyond annotations (destructiveHint=true, readOnlyHint=false), description discloses ephemeral credential behavior, exit_code semantics, pty stdout/stderr merging, sudo/pty preconditions, and ttl_seconds default. No contradiction with annotations; significant added context.

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?

The description is well-structured and front-loaded with purpose. Every sentence earns its place—there is no filler. Short imperative warnings ('DO NOT retry') and clear separation of concerns make it easy to scan.

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?

The tool has 7 params and an output schema, but the description still covers key contextual aspects: purpose, preference over sibling, return values, exit_code interpretation, prerequisites, safety constraints, and parameter defaults. It is fully self-sufficient for an agent to invoke correctly.

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

Parameters5/5

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

Schema covers all 7 parameters with descriptions, but the tool description adds vital operational semantics: sudo requires allow_sudo=true and 'DO NOT retry' if false, pty requires allow_pty=true, and ttl_seconds is optional with max-allowed default. These go beyond the schema's base descriptions.

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 clearly states 'Execute a single command on a Linux host via SSH with an ephemeral credential'—a specific verb, resource, and mode. It further distinguishes itself from sibling ssh_session_open by advising preference for single or independent commands.

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?

Explicitly tells when to use this tool vs ssh_session_open, requires calling ssh_list_servers before use, and gives conditional rules for sudo and pty with clear 'do not retry if not allowed' instructions. It also clarifies that non-zero exit_code means remote failure not a tool error.

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/luisgf/infrabroker'

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