Skip to main content
Glama

ssh_execute

Execute a single command on a Linux host via SSH with ephemeral credentials. Returns 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
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?

The description discloses return values (stdout, stderr, exit_code) and interprets exit_code != 0 as remote command failure, not tool error. It explains that with pty, stdout and stderr are merged. Since no annotations are provided, the description fully carries the burden and does so thoroughly.

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 a single paragraph but well-structured: purpose first, then differentiation, then output clarification, then prerequisites and conditional rules. Every sentence is informative and earns its place. It is front-loaded and concise without being terse.

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 7 parameters (2 required) and existence of an output schema, the description covers all essential aspects: purpose, usage context, output behavior, parameter conditions, and prerequisites. There is no obvious gap for effective selection and invocation.

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 coverage is 100%, so baseline is 3. The description adds value by reiterating and expanding on conditions: e.g., for sudo and pty it restates the allow_* requirements and adds retry guidance. It also explains dry_run behavior beyond the schema's brief description. This extra context pushes the score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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', providing a specific verb and resource. It explicitly distinguishes from ssh_session_open, but does not differentiate from ssh_session_exec, which is a sibling and might be used for similar tasks within an existing session. This minor gap prevents a top score.

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: 'Prefer this tool over ssh_session_open when you only need to run one command or independent commands.' It also provides prerequisites ('BEFORE calling: use ssh_list_servers'), conditional rules for sudo and pty with retry instructions, and clarity on optional parameters like ttl_seconds. This covers usage comprehensively.

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