Run shell commands on remote SSH hosts through a persistent session, with authentication, timeout, sudo, and enable options.
Execute a command on an SSH host using a persistent session.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| port | No | ||
| command | Yes | ||
| timeout | No | ||
| password | No | ||
| username | No | ||
| key_filename | No | ||
| sudo_password | No | ||
| enable_command | No | enable | |
| enable_password | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the persistent-session behavior, which is valuable, but omits critical traits: that it is a write/execution operation with side effects, auth requirements (password vs key_filename vs enable_password/sudo_password), timeout behavior, and what a 'persistent session' means for subsequent calls. A single sentence cannot cover a 10-param, no-annotation execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded, waste-free sentence. Sized appropriately for its content, though not for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be explained, but the description leaves the persistent-session semantics, authentication modes, timeout behavior, and sibling differentiation entirely unaddressed for a high-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description names none of the 10 parameters. Crucial params like sudo_password, enable_command, enable_password, timeout, and the SSH auth options are completely undocumented anywhere. The description must compensate and does not, so this falls below the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Execute) and resource (a command on an SSH host) with the added architectural detail of a persistent session. It does not, however, distinguish itself from execute_command_async or execute_command_enhanced, which is the key differentiation burden given this sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this synchronous execute_command versus execute_command_async, execute_command_enhanced, or send_input to a running command. An agent facing 21 siblings has to guess, and 'persistent session' hints at state without explaining the implications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.