Skip to main content
Glama

execute

Run privileged commands or multi-stage pipelines locally or on a remote sudo-proxy host after a human approves the request at that host's terminal.

Instructions

Execute a command (or multi-stage pipeline) on a sudo-proxy host after a human approves it at that host's terminal. Provide argv for a single command or pipeline for piped stages (e.g. [["ls", "/tmp"], ["wc", "-l"]]); host targets a remote daemon started via start_server (omit for localhost). Unprivileged commands on the local machine are refused — use your Bash tool, which applies the same controls. timeout is in milliseconds (max 600000); it defaults to 120000 for privileged commands but is opt-in for unprivileged ones (omitted = wait as long as the daemon needs, so an approved-but-slow command is not falsely timed out). Blocks until the human answers, then returns the final stage's stdout plus per-stage stderr and exit codes. Errors: 'Request denied by user.' if the human declines, a timeout error if unanswered within 60s, and 'sudo-proxy is not running' if the daemon is down — call start_server first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
envNoEnvironment variables
argvNoCommand as argument array
hostNoTarget host (omit for localhost)
timeoutNoTimeout in milliseconds, max 600000. For privileged commands the default is 120000. For unprivileged commands the timeout is opt-in: if omitted, the call waits as long as the daemon needs (the 60s approval prompt and the executor's own bound still apply), so an approved-but-slow command is not falsely reported as timed out. Set it explicitly to bound either.
pipelineNoPipeline of commands, each as an argument array. Use this for piped commands like [["ls", "/tmp"], ["wc", "-l"]].
privilegedNoPrivilege escalation (default: true)
descriptionNoWhat this command does (shown in TUI prompt)
forward_agentNoForward the local SSH agent to the command (unprivileged only). Requires the proxy session to have been started with `forward_agent: true`. Useful for `git clone` of private repos via SSH on a remote host.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedInput schema / properties / timeout / description
      Previous value: -"Timeout in milliseconds (default: 120000, max: 600000)"New value: +"Timeout in milliseconds, max 600000. For privileged commands the default\nis 120000. For unprivileged commands the timeout is opt-in: if omitted,\nthe call waits as long as the daemon needs (the 60s approval prompt and\nthe executor's own bound still apply), so an approved-but-slow command is\nnot falsely reported as timed out. Set it explicitly to bound either."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well: it blocks until the human answers, times out after 60s if unanswered, returns the final stage's stdout plus per-stage stderr and exit codes, and enumerates exact error strings ('Request denied by user.', 'sudo-proxy is not running'). This is rich behavioral disclosure an agent could not infer from the schema.

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-loaded with purpose, then parameters, then errors — a sensible order. The paragraph is dense and long, but nearly every clause carries operational information rather than filler, so it earns its size.

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 an 8-parameter tool with no output schema and no annotations, the description covers execution mode, targeting, blocking/approval behavior, timeouts, return values, and error conditions. 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.

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 adds genuine meaning: the argv-vs-pipeline choice with a worked example, the host omission default, and the non-obvious timeout semantics (120000 default for privileged, opt-in for unprivileged). It slightly exceeds what the schema alone conveys.

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 (execute), resource (command or multi-stage pipeline), and the defining constraint (on a sudo-proxy host after human approval). This clearly distinguishes it from start_server, status, stop_server, and update_host, which manage the daemon rather than run 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 routes the agent: use `argv` for single commands, `pipeline` for piped stages, omit `host` for localhost, and unprivileged local commands are refused in favor of the Bash tool. It also tells the agent to call start_server if the daemon is down — concrete when-to-use and when-not-to-use guidance.

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

Deploy Server

Other Tools