Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
SSH MCP Server demonstrates solid foundational structure with 19 well-named tools covering SSH operations, SFTP file transfer, and server management. However, critical gaps exist: (1) Tool descriptions lack LLM-optimization guidance and action context. Average description length ~80 chars, well below the 194-char baseline for A+ tools. Descriptions are functional but terse (e.g., 'exec': '在远程服务器执行命令' = 'Execute commands on remote server'). (2) Parameter descriptions are minimal, many params lack format guidance, constraints, or dependency hints. For example, 'timeout' params say '命令执行超时时间（毫秒）' (timeout in ms) but omit min/max bounds; 'command' param has no guidance on shell metacharacters or multi-line handling. (3) Output schemas are not documented in visible source code, tools return results but response field structure is not explicitly defined for LLMs. (4) Error handling descriptions exist ('确认验证失败') but lack recovery guidance (no 'call X next' hints). (5) Security patterns are partially implemented: confirmation tokens for destructive ops (remove_server, sftp_rm, exec with dangerous commands) are present, but param descriptions do not clearly warn against secrets or note server-side credential injection. Positives: tool naming is excellent (19/19 use verb_noun pattern), schemas use Zod validation with proper type constraints, and the confirmation manager pattern for DESTRUCTIVE operations is well-implemented. All tools have descriptions, though brevity is the weakness.
Tools (19)
connectwritesource verified73/100
建立 SSH 连接。两种方式二选一：(1) 通过 alias 连接已保存的服务器；(2) 通过 host + username + password/privateKey 直接连接。使用 alias 时可额外传 password/privateKey 覆盖已存储的凭证。
Parameter descriptions lack format guidance and constraint documentation. Examples: 'timeout' params state milliseconds but omit min/max bounds (e.g., 'timeout: 1000ms min' vs unbounded). 'command' param for exec/exec_sudo/exec_shell lacks guidance on shell metacharacters, multi-line handling, or dangerous patterns (rm -rf /). 'promptPattern' in exec_shell has no regex format guidance. LLMs cannot infer constraints from names alone.
Tool descriptions are minimal and lack LLM-optimized context. Average length ~80 chars vs 194-char baseline for A+ tools. Descriptions state WHAT but omit WHEN and WHY. Example: 'exec': '在远程服务器执行命令' provides no guidance on when to use vs exec_sudo, exec_batch, or exec_shell. Missing: dependency hints (e.g., 'Call connect() first unless using alias'), prerequisite clarity, and recovery paths for errors.
disconnectshell_sendshell_readshell_close
Recommendations
Expand tool descriptions to 150-250 characters. For each tool, add: (1) What it does in one sentence. (2) When to use it (vs similar tools). (3) Prerequisites (e.g., 'Requires active connection via connect() or alias from save_server'). Example: 'exec' → 'Execute arbitrary shell commands on a connected remote server. Use exec for one-off commands, exec_batch for multi-server deployment, exec_sudo for elevated privileges. Requires prior connect() or saved alias.'
Add format and constraint guidance to every numeric and string parameter. Examples: (1) timeout params: 'Timeout in milliseconds. Minimum 1000, maximum 600000 (10 min). Recommended 30000-60000 for typical operations.' (2) command param: 'Shell command to execute. Supports pipes, redirects, and variables. Dangerous patterns (rm -rf, *, truncate) require confirmationToken. Avoid hardcoding secrets, use environment variables.' (3) promptPattern: 'Regex pattern matching shell prompt (e.g., '.*[$#]\s*$' for bash). Required for shell mode when interacting with non-standard prompts.'
Document output schemas explicitly for all tools. Add a 'Response' section to each tool definition. Example for exec: 'Response: {success: boolean, stdout: string, stderr: string, exitCode: number, executionTime: number}'. Include field descriptions and example values (avoid example secrets).
Implement per-tool error guidance. When a tool can fail, document common failures and recovery paths. Example for save_server: 'Error: Alias already exists. Call remove_server() with confirmationToken to overwrite, or choose a different alias.' Example for exec: 'Error: Connection timeout. Verify host/port/credentials via health_check(), or increase timeout parameter.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Output schemas not documented in source code. Tools return success/error responses (e.g., 'success: true, message: string') but response field structure is not explicitly defined for LLMs. LLMs cannot plan downstream tool calls or extract required fields (e.g., connection_id, session_id) without documented return schemas. Missing: per-tool response examples and field descriptions.
Error handling descriptions lack recovery guidance. Example: save_server may return '配置验证失败' (config validation failed) but LLMs are not told what to do next (e.g., 'check field X' or 'call list_servers to see valid environments'). Missing: actionable error messages with invalid value + constraint pairs, and next-step hints for common failures.
Parameter interdependencies not documented. Examples: (1) 'connect' requires alias OR (host+username), but this mutual exclusivity is not emphasized in param descriptions. (2) 'save_server' requires confirmationToken only for overwrite, but this condition is buried in the param description. (3) 'exec' requires alias OR host, but the exclusivity rule is unclear. LLMs will attempt invalid combinations without explicit guidance in each param's description.
Security descriptions lack explicit warnings. 'privateKey' and 'password' params in connect/save_server do not warn against passing secrets as strings in chat logs or traces. No mention of secure credential storage or server-side injection patterns. 'sudoPassword' in exec_sudo is particularly risky, no guidance on how this is handled or logged. Missing: explicit 'Do NOT pass secrets directly' warnings and vault/keytar integration guidance.
Batch tool (exec_batch) lacks clarity on multi-server handling and failure modes. Parameter 'servers' accepts an array but no description explains expected format, whether partial failures are acceptable, or what the response includes (per-server success/failure or aggregate?). Missing: guidance on error aggregation and idempotency for multi-target operations.
exec_batch
Explicitly document parameter interdependencies in EVERY affected param description. Use clear phrasing: (1) For 'connect': 'Required: Either alias OR (host + username). Cannot specify both.' (2) For 'exec': 'Target server: Specify alias (preferred, requires prior save_server) OR host. With single active connection, host is optional.' (3) For 'save_server': 'confirmationToken required only when overwriting existing alias. First call returns token; second call with token confirms override.'
Add security warnings to all credential parameters. For 'privateKey' and 'password' in connect/save_server: 'WARNING: Credentials are sensitive. Consider using server-side credential injection (keytar integration) instead of passing raw values. Secrets in parameters may appear in logs and traces.' For 'sudoPassword' in exec_sudo: 'Sudo password is transmitted and must be handled securely. Verify server enforces NOPASSWD if possible, or use keytar for secure storage.'
Clarify exec_batch response structure. Document: (1) Does it return per-server results or aggregate? (2) If one server fails, does batch continue? (3) Example response: '{success: boolean, results: [{alias: string, success: boolean, stdout: string, stderr: string, error?: string}], failed: number, total: number}'
Add 'Idempotency' notes to WRITE and DESTRUCTIVE tools. Example for save_server: 'Idempotent: Calling save_server twice with same alias and credentials produces identical state.' Example for sftp_rm: 'Non-idempotent with recursive=true: calling twice may fail if directory already removed. Consider checking existence first via sftp_ls.'
Include LLM-friendly examples in descriptions without hardcoding secrets. Example for connect: 'Usage: connect via saved alias='production-db' for recurring tasks, or connect via host='10.0.1.5' + username='deploy' for ad-hoc access. Use password for testing; use privateKey for production (rotate regularly).'
Implement pagination documentation for list_servers and sftp_ls. Add explicit guidance: 'Large result sets are truncated to 50 items. Use group filter (list_servers) or implement client-side pagination for 100+ servers. Sorted by alias alphabetically.'
Add tool annotations for Protocol Readiness. Explicitly mark tools with destructiveHint for remove_server, sftp_rm, exec_sudo; mark shell_* as read-only where applicable; mark connect/disconnect as having side effects.