Mcp-Warden

Overview Schema Source Related Servers Discussions Admin

ssh_run

Execute a preset's named SSH command with typed, validated parameters; credentials stay in the OS keychain, and each call is approval-gated and audit-logged.

Instructions

Run one of an SSH preset's named commands. You supply command (a name the preset declares; list_presets shows each command, what it does and its parameters) and params (values by name). The command line is FIXED in the preset: each value fills one placeholder, checked by its type (a string or path against a pattern, an int within a range, an enum from a list) BEFORE any credential is read. Values are single words without spaces or shell syntax and may not start with -. Returns stdout, stderr and exit_code. Host key verified against known_hosts. The approval prompt shows the full command. If the user previously approved a time-boxed window for this command, the call proceeds without a new prompt and is recorded as 'windowed' in the audit log. Every call is recorded to the audit log.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "preset_name": "<preset_name>",
      "command": "<command>"
    },
    "name": "ssh_run"
  }
}

Input Schema

Name	Required	Description
`params`	No	The command's parameters by name, e.g. {"lines": 50}.
`command`	Yes	One of the preset's named commands; `list_presets` shows them.
`preset_name`	Yes

Output Schema

Name	Required	Description
`notice`	No	Set when mcp-warden stopped reading the output (over the limit).
`stderr`	Yes
`stdout`	Yes
`exit_code`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.6.0Nov 3, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so with real substance: type-checked validation before any credential is read, single-word values with no shell syntax and no leading `-`, host key verification against known_hosts, an approval prompt showing the full command, a time-boxed re-approval bypass recorded as 'windowed', and audit logging of every call. The only gap is that it never says which host or user a preset targets, though that is arguably preset-scoped.

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 the core action in the first clause, then layered with validation, return values, and security/approval behavior. Several sentences are well earned, though the approval/windowed and audit-log statements could be tightened into one thought without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the stdout/stderr/exit_code mention is a bonus rather than a necessity. For a security-sensitive remote execution tool the description covers validation, trust, approval and auditing adequately; what remains thin is preset provenance (host, credentials, who may use it).

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?

Adds meaningful semantics beyond the 67%-covered schema: `params` fills one typed placeholder per value (string/path pattern, int range, enum list) and `command` must be a preset-declared name discoverable via list_presets. `preset_name` is left entirely undefined in both schema and description, which keeps it from a 5.

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 and resource ("Run one of an SSH preset's named commands") and immediately pins down the mechanism that separates it from ssh_exec: the command line is FIXED in the preset and only typed placeholder values are supplied. An agent can tell this apart from an arbitrary-command exec sibling without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: the value for `command` must come from a preset, and `list_presets` is named as the way to discover commands, their behavior and parameters. It does not explicitly state the inverse (use ssh_exec when no preset exists), so no exclusion guidance, but the prerequisites are well covered.

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

Deploy Server