Loading ToolBench

Reading the current corpus…

hardened-ssh-mcp MCP server · C · ToolBench

hardened-ssh-mcp

A single-purpose MCP server that lets an AI assistant run commands over SSH on one fixed, pre-configured host - and only that host - with an explicit per-call confirmation gate. Built as a deliberately hardened, minimal alternative to general-purpose "run any PowerShell/shell command" MCP tools.

2026-07-28+STDIO1 tools

64/100

Definition Quality87

Protocol Readiness50

Supportability35

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

Single tool 'run-ssh-command' has excellent naming (verb_noun, clear action), comprehensive description (380+ chars, explains constraints and confirmation gate), and well-defined schema with typed parameters and descriptions. Input schema uses Zod with proper type constraints (string.min(1), boolean.default(false)). Output structure is implicit but reasonable (text content with isError flag). However, output schema is not formally documented in code comments or JSDoc, and no explicit error recovery guidance is provided beyond the isError flag. The confirmation-gate pattern is well-implemented but could benefit from explicit documentation of the two-call workflow (preview then execute).

Tools (1)

run-ssh-commandwritesource verified87/100

Run exactly one command over SSH on the fixed target ${SSH_USER}@${SSH_HOST} and nothing else. This tool cannot reach any other host, cannot run local commands, and cannot touch the local filesystem directly - the only thing it can ever do is relay one command over SSH to that one account on that one machine, which is fixed by whoever deployed this server, not something you (the model) can choose. Standing rule: always show the user the exact command in chat and get their explicit go-ahead BEFORE calling this tool. Call it with confirmed=false (or omit confirmed) to preview what would run without executing anything. Only call it with confirmed=true after the user has approved this specific command in this specific turn - never assume consent from an earlier, different command.

Issues (3)

MEDIUMtool ↗

Output schema not formally documented. Code returns {content: [{type, text}], isError: boolean} but this structure is not documented in JSDoc or parameter descriptions, forcing LLMs to infer the response shape.

run-ssh-command

MEDIUMrecovery-guide ↗

Error recovery guidance is minimal. Timeout and execution errors return isError=true with text, but do not suggest next steps (e.g., 'Increase SSH_COMMAND_TIMEOUT_MS and retry' or 'Check SSH key permissions').

run-ssh-command

LOWtool-annotations ↗

No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The tool is destructive (can modify remote state) but lacks explicit annotation to signal this to the LLM.

run-ssh-command

Recommendations

Add JSDoc block documenting the return type: @returns {{content: Array<{type: string, text: string}>, isError: boolean}}
Enhance error messages with actionable recovery steps. E.g., timeout error: 'Command timed out after 30s. Increase SSH_COMMAND_TIMEOUT_MS environment variable and retry, or break the command into smaller steps.'
Register tool with destructiveHint annotation to signal to LLMs that this tool can modify remote state and should be called only after explicit user approval.
Add JSDoc @example block showing the two-call workflow: first call with confirmed=false to preview, second with confirmed=true after user approval.
Document the confirmation-gate pattern in the tool description more explicitly: 'This tool requires a two-step workflow: (1) call with confirmed=false to preview the command, (2) call with confirmed=true only after the user has explicitly approved it in chat.'

Score history

Overall score trend

First recorded score · v2 rubric

64/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	64	2026-07-28+	v2