Enables executing Git commands on remote servers to automate workflows such as code updates and deployment tasks.
Allows for the management of Node.js projects on remote systems by running npm commands like install and ci during deployment processes.
Supports remote server management and command execution on Ubuntu-based systems through persistent SSH connections.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcpHydroSSH connect to the production server and show me the current disk usage"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
中文 | English | Configuration Guide | 配置指南
MCP server that provides SSH remote connection capabilities for Claude Code. Connect to remote servers, execute commands, and automate deployments without needing a separate SSH terminal.
mcp-hydrocoder-ssh is an MCP (Model Context Protocol) server that enables Claude Code to:
🔌 Connect to remote SSH servers directly (persistent background connections)
⚡ Execute commands and get complete output
🔄 Maintain connection state for multi-step operations
🚀 Run deployment scripts (git pull, npm install, systemctl restart, etc.)
Benefit | Description |
No window switching | Complete all remote operations within Claude Code conversation |
Smart deployment | Claude can auto-determine next steps based on command output |
Multi-server management | Manage multiple server configs, switch quickly |
Secure authentication | Support SSH agent, key files |
Connection pooling | Maintain persistent connections, avoid re-authentication overhead |
SSH Connection Tools (5):
ssh_list_servers - List all configured servers
ssh_connect - Connect to a server
ssh_exec - Execute commands (with working directory support)
ssh_get_status - Get connection status
ssh_disconnect - Disconnect from server
Configuration Management Tools (5):
ssh_add_server - Add new server configuration
ssh_remove_server - Remove server configuration
ssh_update_server - Update server configuration
ssh_view_config - View config (filters sensitive info)
ssh_help - Show help information
Related MCP server: mcp-ssh-tool
npm install -g mcp-hydrocoder-ssh
claude mcp add -s user hydrossh mcp-hydrocoder-sshnpm install -g mcp-hydrocoder-ssh
claude mcp add hydrossh mcp-hydrocoder-sshclaude mcp add -s user hydrossh npx mcp-hydrocoder-ssh@latestclaude mcp add hydrossh npx mcp-hydrocoder-ssh@latestNotes:
-s userflag sets user-level MCP configuration, available to all projectsWithout
-s user, configuration is project-level, only available to current projectUsing
npxdoes not require pre-installing the npm package
In Claude Code, enter:
List available SSH serversIf you see a server list (empty list means no servers configured yet), the installation was successful.
git clone https://github.com/hydroCoderClaud/mcpHydroSSH.git
cd mcpHydroSSHnpm installnpm run buildBuild output goes to dist/ directory:
dist/index.js - MCP server entry point
dist/ssh-manager.js - SSH connection management
dist/config.js - Configuration management
Edit ~/.claude.json:
{
"mcpServers": {
"hydrossh": {
"command": "node",
"args": ["<absolute-path>/dist/index.js"]
}
}
}Note: Replace
<absolute-path>with your actual source directory absolute path.
Close and reopen Claude Code.
For hot-reload development:
npm run devThen configure Claude Code with:
{
"mcpServers": {
"hydrossh": {
"command": "npx",
"args": ["tsx", "<absolute-path>/src/index.ts"]
}
}
}Configuration file location: ~/.hydrossh/config.json
Auto-created on first run: The ~/.hydrossh/ directory and config file are automatically created when the MCP server first starts.
After installation, you can add server configs using natural language commands.
{
"servers": [
{
"id": "prod-server",
"name": "Production Server",
"host": "example.com",
"port": 22,
"username": "deploy",
"authMethod": "agent"
},
{
"id": "test-server",
"name": "Test Server",
"host": "test.example.com",
"username": "ubuntu",
"authMethod": "key",
"privateKeyPath": "~/.ssh/id_rsa"
}
],
"settings": {
"defaultConnectTimeout": 30000,
"defaultKeepaliveInterval": 60000,
"commandTimeout": 60000,
"maxConnections": 5,
"logCommands": true
}
}Method | Configuration | Description |
SSH Agent |
| Recommended, uses system SSH agent |
Key File |
| Default, reads private key file |
Password |
| Not recommended, password stored in plaintext |
See CONFIG-GUIDE_EN.md for details.
User: List available servers
Claude: Found 2 configured servers: prod-server, test-server
User: Connect to prod-server
Claude: [ssh_connect] Connected! connectionId: xxx
User: Execute command: uptime
Claude: [ssh_exec] Returns: up 30 days, 2 users, load average: 0.1, 0.2, 0.5
User: Disconnect
Claude: [ssh_disconnect] DisconnectedUser: Deploy latest code to production server
Claude: Okay, I'll execute the deployment flow...
1. Connect to prod-server
2. cd /opt/myapp && git pull
3. npm ci --production
4. sudo systemctl restart myapp
5. Check service status
6. Disconnect
Deployment complete!🔒 SSH Agent Recommended - Prefer authMethod: "agent"
🔒 Config File Permissions - Ensure ~/.hydrossh/config.json is readable only by you
🔒 Config Viewing - ssh_view_config tool automatically filters passwords and key paths
Issue | Solution |
SSH Agent not running | Windows: Start "OpenSSH Authentication Agent" service |
Connection timeout | Check server address, port, network connectivity |
Command not found | Verify npm global install or check PATH environment variable |
Config not loaded | Check if |
Config file not found | Auto-created on first run, or manually create |
npm run build # Build TypeScript
npm run dev # Development mode (hot reload)
npm test # Run tests
npm run lint # Code linting
npm run format # Code formattingTool | Parameters | Description |
| none | List all configured servers |
|
| Connect to server |
|
| Execute command |
|
| Get connection status (all if not specified) |
|
| Disconnect (most recent if not specified) |
|
| Add server config |
|
| Remove server config |
|
| Update server config |
| none | View config (filters sensitive info) |
|
| Show help information |
MIT
Add a new SSH server to config
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unique server ID | |
| name | Yes | Server display name | |
| host | Yes | Server hostname or IP | |
| port | No | SSH port (default: 22) | |
| username | Yes | SSH username | |
| authMethod | No | Authentication method (default: "key") | |
| privateKeyPath | No | Path to private key (required for "key" auth) | |
| password | No | Password (required for "password" auth) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description lacks details on side effects (e.g., persistence, configuration file modification, validation checks). Minimal information beyond the action.
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?
Single sentence, no fluff. Could benefit from slightly more detail, but remains concise and front-loaded.
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?
Given the complexity (8 parameters, no output schema, no annotations), the description is insufficient. Does not explain behavior like duplicate IDs or error handling.
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 coverage is 100% with descriptions for each parameter. The tool description adds no additional meaning, so baseline 3 is appropriate.
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?
The description clearly states the action (Add), the resource (SSH server), and the target (config). It distinguishes from siblings like ssh_remove_server and ssh_update_server.
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?
No guidance on when to use this tool vs alternatives like ssh_update_server. No prerequisites or context for using add versus other server management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to an SSH server
| Name | Required | Description | Default |
|---|---|---|---|
| serverId | Yes | Server ID from ssh_list_servers | |
| timeout | No | Connection timeout in milliseconds (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Connect to an SSH server'. It does not disclose whether this establishes a persistent session, modifies state, requires authentication, or what the side effects are. The behavior is underspecified for a potentially stateful operation.
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?
The description is a single, concise sentence with no superfluous words. It is front-loaded with the action and resource. Every word earns its place.
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?
Given the tool's likely stateful nature and lack of output schema, the description is incomplete. It does not mention connection life cycle, success/failure behavior, or how this tool relates to siblings like ssh_exec or ssh_disconnect. More context is needed for an agent to use it correctly.
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 coverage is 100%, so the input schema already documents both parameters adequately. The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate as the description does not enhance understanding of parameter semantics.
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?
The description clearly states the action ('Connect') and resource ('SSH server'), making the primary function evident. However, it does not differentiate from siblings like ssh_disconnect or ssh_exec, which are clearly separate actions, but the purpose is still unambiguous.
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?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives (e.g., use this before ssh_exec, or when to use ssh_connect vs ssh_list_servers). An agent would have no context on prerequisites or order of operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect from an SSH server
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | No | Connection ID (optional, disconnects most recent if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'disconnect' without detailing side effects, error handling, or authorization needs. For a destructive action, more transparency is needed.
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?
Single sentence, directly states purpose, no wasted words. Front-loaded and efficient.
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?
Adequate for a simple one-parameter tool, but lacks behavioral depth and usage guidance that would fully inform an agent.
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?
Input schema already describes the sole parameter (connectionId) well, so description adds no extra semantic value. Baseline 3 given 100% schema coverage.
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?
Description clearly states action (disconnect) and resource (SSH server). Distinct from sibling tools like ssh_connect (connect) and ssh_exec (execute command).
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?
No explicit guidance on when to use vs alternatives, but usage is implied by the name and sibling context. Could mention it's the counterpart to ssh_connect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a command on an SSH server
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Command to execute | |
| connectionId | No | Connection ID (optional, uses most recent if not provided) | |
| timeout | No | Command timeout in milliseconds (optional) | |
| cwd | No | Working directory (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It only states 'Execute a command' without disclosing side effects, required permissions, or behavior when connectionId is missing. The schema indicates default behavior (most recent connection), but the description omits this.
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?
The description is a single sentence with no waste, but it is too brief given the tool's complexity. It front-loads purpose but lacks structure for additional context.
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?
With 4 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain return values (e.g., stdout, exit code) or the need for an existing connection, which is critical for effective use.
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 100%, so parameters are documented. The description adds no extra meaning beyond the schema, earning a 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?
The description clearly states the action: 'Execute a command on an SSH server'. It distinguishes from sibling tools (e.g., ssh_connect, ssh_add_server) which manage connections rather than execute commands.
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?
No guidance is provided on when to use this tool. It does not mention prerequisites (e.g., an existing connection via ssh_connect) or alternatives (e.g., using ssh_connect for connecting).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SSH connection status
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | No | Connection ID (optional, shows all connections if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only says 'Get SSH connection status' without detailing what status information is returned, side effects, or authentication needs. The parameter hint about showing all connections if no ID is useful but insufficient.
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?
The description is a single, front-loaded sentence with no wasted words. However, it may be overly terse at the expense of completeness.
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?
Given the tool's simplicity, the description is minimally viable but lacks details on output format or what 'status' includes. Without annotations or output schema, the description should compensate but does not.
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?
The schema already documents the one parameter with 100% coverage. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
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?
The description clearly states the verb 'Get' and the resource 'SSH connection status'. It effectively distinguishes from sibling tools like ssh_connect and ssh_disconnect by focusing on status retrieval.
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?
No guidance on when to use this tool versus alternatives such as ssh_list_servers or ssh_connect. The description does not provide context for usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show help and usage examples for mcpHydroSSH
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Specific topic to get help on (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose the tool's read-only nature or any side effects. It only states it shows help, but does not explain that no state changes occur or what the output format is.
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?
The description is a single sentence that is concise and front-loaded. However, it lacks any structured breakdown of usage or output details, which could be beneficial.
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?
Given the simplicity of the tool (one optional parameter, no output schema), the description is minimally adequate but does not explain the output format or provide examples, leaving some ambiguity.
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?
The input schema is fully described with 100% coverage, listing the optional 'topic' parameter with enum values. The description does not add meaning beyond the schema, so the baseline score of 3 applies.
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?
The description 'Show help and usage examples for mcpHydroSSH' clearly states the tool's function: providing help and examples for the SSH server. It distinguishes from sibling tools that perform actions like connecting or executing commands.
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?
No guidance is provided on when to use this tool versus sibling tools. It does not clarify that this tool is for learning about other tools or obtaining examples, nor does it exclude any use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured SSH servers
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks disclosure of behavioral traits such as authentication requirements, return format, or side effects. The agent has no insight beyond the basic listing operation.
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?
Single sentence, front-loaded with action and resource. No redundant information.
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?
Given no parameters and no output schema, the description minimally covers purpose. However, lacks behavioral details (e.g., return format, authentication) that would be needed for a complete understanding.
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?
No parameters in schema, so description adds value by clarifying scope ('all configured'), which tells the agent the tool lists everything without filters.
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?
Description clearly states 'List all configured SSH servers', specifying verb (list) and resource (configured SSH servers). It distinguishes from sibling tools like ssh_add_server (adds) and ssh_connect (connects).
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?
No guidance on when to use this tool versus alternatives. Sibling tools exist (e.g., ssh_get_status), but no exclusion criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a server from config
| Name | Required | Description | Default |
|---|---|---|---|
| serverId | Yes | Server ID to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states a destructive action without disclosing reversibility, authorization needs, or impact on connections. Must carry full burden but fails to do so.
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?
The description is a single, clear sentence with no wasted words. Could be slightly improved by front-loading key behavioral info, but remains efficient.
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?
For a simple tool with one parameter and no output schema, the description is minimally adequate but lacks safety context about irreversibility or authorization, which is important for a removal operation.
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 100%, so the parameter is already documented. The description adds no extra information beyond what the schema provides, resulting in baseline score.
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?
The description specifies the verb 'Remove' and the resource 'a server from config', clearly distinguishing it from sibling tools like ssh_add_server and ssh_update_server.
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?
No guidance is provided on when to use this tool versus alternatives like ssh_update_server or ssh_disconnect. Missing context such as irreversible nature or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing server config
| Name | Required | Description | Default |
|---|---|---|---|
| serverId | Yes | Server ID to update | |
| name | No | Server display name | |
| host | No | Server hostname or IP | |
| port | No | SSH port (default: 22) | |
| username | No | SSH username | |
| authMethod | No | Authentication method (default: "key") | |
| privateKeyPath | No | Path to private key (required for "key" auth) | |
| password | No | Password (required for "password" auth) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only says 'update' without disclosing whether it overwrites or merges fields, whether it is destructive, or any permission requirements. This is insufficient for a mutation 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?
The description is a single 4-word sentence. While concise, it is underspecified and could be more informative without becoming verbose.
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?
No output schema, no annotations, and minimal description. With 8 parameters and a mutation action, the description fails to provide enough context for safe and correct use.
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 100%, so the schema fully documents each parameter. The description adds no extra meaning beyond 'update', achieving the baseline.
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?
The description clearly states the action (Update) and the resource (existing server config). It distinguishes from add/remove tools but lacks specificity about what config fields are updated.
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?
No guidance on when to use this tool versus alternatives like ssh_add_server or ssh_remove_server. No prerequisites mentioned (e.g., server must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View the full SSH configuration including servers and settings
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Implies read-only via 'View', but lacks disclosure of output format, caching, or error behavior. With no annotations, description carries burden; minimal but adequate for a simple view 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?
Single concise sentence with clear front-loaded verb and resource. No filler.
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?
For a parameterless view tool with no output schema, the description sufficiently conveys purpose. Could note read-only explicitly, but not necessary.
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?
No parameters, so schema coverage is 100%. Description adds no param info, which is acceptable given zero params.
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?
Clear verb 'View' and resource 'SSH configuration' with scope 'including servers and settings'. Distinct from siblings like ssh_list_servers and ssh_get_status.
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?
No guidance on when to use vs alternatives such as ssh_list_servers for just servers or ssh_get_status for status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.4ssh_add_serverssh_connectssh_disconnectssh_execssh_get_statusssh_helpssh_list_serversssh_remove_serverssh_update_serverssh_view_configEach tool has a clearly distinct purpose: managing server config, connecting/disconnecting, executing commands, and viewing status. No two tools overlap in functionality.
All tools follow a consistent verb_noun pattern with the ssh_ prefix (e.g., ssh_add_server, ssh_list_servers). No naming conflicts or mixed conventions.
10 tools cover the full SSH management lifecycle without being excessive or minimal. Each tool serves a clear need.
Covers server config management, connection handling, command execution, and status. Minor gaps like file transfer (SCP/SFTP) are absent but not essential for a basic SSH shell tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hydroCoderClaud/mcpHydroSSH'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
