mcp

Get SSH command for instance

get_ssh_command

Read-only

Returns the SSH command to connect to an instance via the redu.cloud TCP proxy. ACCEPTS an instance id, a deployment's id / name / instance_id, OR a MANAGED DATASTORE's id / name / instance_id (Postgres, MySQL/MariaDB, ClickHouse, Redis) - it resolves all of them, so you do not have to work out which one you are holding (a deployment's instance_id is a placeholder until provisioning finishes, and passing it used to fail). ⭐ SSH TO THE DATASTORE VM IS HOW YOU REACH A PRIVATE-NETWORK-ONLY DATABASE BEFORE ANY APP VM EXISTS: the datastore's own VM is SSH-reachable and ships the client on PATH (psql at /usr/bin/psql), so you can apply a schema or rotate a seeded admin account without an app VM to tunnel through. For a DEPLOYMENT VM (created by deploy_app/deploy_compose) pass keypair_name - read it from get_deployment - so the command uses -i ~/.ssh/<keypair_name> and authenticates with the RIGHT key instead of your default identity (without it, SSH to a deploy VM usually fails). The tool also best-effort looks up the keypair from the deployment if you omit it. Example: ssh -i ~/.ssh/redu-deploy -o IdentitiesOnly=yes -p 22011 ubuntu@myinstance-abc12345.redu.cloud

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": {
      "instance_id": "<instance_id>"
    },
    "name": "get_ssh_command"
  }
}

Input Schema

Name	Required	Description	Default
`instance_id`	Yes	An instance id, a deployment's id / name / instance_id, or a managed datastore's id / name / instance_id. All are resolved.
`keypair_name`	No	The SSH keypair the instance was created with (read it from get_deployment for a deploy VM). When given, the command uses `-i ~/.ssh/<keypair_name>` so it authenticates with the right key.

Output Schema

Name	Required	Description	Default
`host`	No
`mode`	No
`port`	No
`user`	No
`error`	No
`status`	No
`details`	No
`message`	No
`recovery`	No
`validation`	No
`floating_ip`	No
`ssh_command`	No
`keypair_name`	No
`instance_name`	No
`account_notices`	No
`instance_status`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 5, 2026
- addedOutput schema / properties / details
```
Added value: +{}
```
- addedOutput schema / properties / error
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / recovery
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / status
```
Added value: +{}
```
- addedOutput schema / properties / validation
```
Added value: +{}
```

Changed1 schema field changedOct 31, 2026

addedOutput schema / properties / account_notices

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "dismissible": {
+        "type": "boolean"
+      },
+      "id": {
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      },
+      "url": {
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "message",
+      "url",
+      "dismissible"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed1 schema field changedAug 18, 2026

changedInput schema / properties / instance_id / description

Previous value: -"An instance id, or a deployment's id / name / instance_id. All are resolved."New value: +"An instance id, a deployment's id / name / instance_id, or a managed datastore's id / name / instance_id. All are resolved."

Changed1 schema field changedAug 17, 2026

changedInput schema / properties / instance_id / description

Previous value: -"ID of the instance to get the SSH command for."New value: +"An instance id, or a deployment's id / name / instance_id. All are resolved."

Changed2 schema fields changedJun 23, 2026

addedInput schema / properties / keypair_name

Added value: +{
+  "description": "The SSH keypair the instance was created with (read it from get_deployment for a deploy VM). When given, the command uses `-i ~/.ssh/<keypair_name>` so it authenticates with the right key.",
+  "type": "string"
+}

addedOutput schema / properties / keypair_name
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedJun 9, 2026

addedInput schema / properties / instance_id / description

Added value: +"ID of the instance to get the SSH command for."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "floating_ip": {
+      "type": "string"
+    },
+    "host": {
+      "type": "string"
+    },
+    "instance_name": {
+      "type": "string"
+    },
+    "instance_status": {
+      "type": "string"
+    },
+    "mode": {
+      "type": "string"
+    },
+    "port": {
+      "type": "string"
+    },
+    "ssh_command": {
+      "type": "string"
+    },
+    "user": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedJun 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds substantial non-obvious behavior: identifier resolution across instances, deployments, and managed datastores, the placeholder instance_id during provisioning, best-effort keypair lookup on omission, and the fact the datastore VM ships psql at /usr/bin/psql. It stops short of stating whether the returned command expires or whether the SSH port is fixed beyond the example, so it is not exhaustive.

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 purpose and the accepted-id list, then the operational recipe and a concrete example command, which is good ordering. It is slightly overlong and repetitive ('it resolves all of them, so you do not have to work out which one you are holding' restates the id list), and the all-caps emphasis is noisy, but no sentence is truly wasted.

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

Completeness5/5

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

For a two-parameter read-only tool with an output schema (so return format need not be described), the description covers the input variety, the keypair prerequisite, the datastore use case, and includes a literal example output. Nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is 100%, so a 3 would be the floor, but the description adds real meaning beyond the schema: it explains why keypair_name exists (correct -i identity, avoiding default-identity auth failure) and that all identifier forms are resolved, including the provisioning-placeholder trap. That is semantic value the schema text alone does not convey as forcefully.

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?

Opens with a specific verb and resource: 'Returns the SSH command to connect to an instance via the redu.cloud TCP proxy.' It immediately distinguishes itself from the SSH siblings (get_private_vps_ssh, get_free_website_ssh) by scope and names the exact accepted identifier types.

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

Usage Guidelines5/5

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

Gives explicit routing guidance: use this to reach a private-network-only datastore when no app VM exists yet, and pass keypair_name for deployment VMs, reading it from get_deployment. It also states the failure mode of omitting keypair_name ('without it, SSH to a deploy VM usually fails'), which is exactly the when/when-not signal an agent needs.

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

All mcp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?