Skip to main content
Glama

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
instance_idYesAn instance id, a deployment's id / name / instance_id, or a managed datastore's id / name / instance_id. All are resolved.
keypair_nameNoThe 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

TableJSON Schema
NameRequiredDescriptionDefault
hostNo
modeNo
portNo
userNo
floating_ipNo
ssh_commandNo
keypair_nameNo
instance_nameNo
instance_statusNo

TDQS

A4.4/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, so the description does not need to restate safety. However, it adds significant behavioral detail: the tool resolves instance, deployment, or datastore identifiers; it best-effort looks up keypair if omitted; and it constructs an SSH command with -i and -o IdentitiesOnly. These details go well beyond the annotations and help the agent understand operational nuances.

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?

The description is longer than average but well-structured. It opens with the core purpose, then provides advanced usage scenarios, parameter details, and an example. Every sentence adds information—no tautology or filler. Minor reduction could be possible, but it remains clear and easy to scan.

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?

Given that an output schema exists (as indicated by context signals), the description does not need to explain return values. It covers the primary use case, edge cases (datastore before app VM), parameter behavior, and fallback keypair lookup. For a tool with only two parameters and a clear output, this is complete and well-rounded.

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 the schema already provides descriptions for both parameters. The description adds extra meaning: it explains that instance_id can be any of three resource types and that keypair_name is read from get_deployment. It also includes an example showing the constructed command. This adds value beyond the schema's minimal descriptions.

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?

The description clearly states the tool returns an SSH command to connect to an instance via a TCP proxy. It specifies the exact verb ('Returns the SSH command') and resource ('to connect to an instance'). Among sibling tools, none duplicate this functionality—get_instance_logs is different—so it is well-distinguished.

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?

The description provides explicit guidance on when to use the tool, including the datastore VM use case for reaching private databases before any app VM exists. It explains when to pass the keypair_name parameter for deployment VMs and that omission triggers a best-effort lookup. While it does not include a formal 'when not to use' statement, the context is clear and the alternatives are implicitly covered (e.g., tunneling through an app VM is not needed here).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, and the descriptions include specific details (e.g., create_database for Postgres vs create_relational_database for MySQL/MariaDB) that prevent confusion. Even similar tools like plan_deploy, plan_instance, and plan_managed_datastore are well-differentiated by their contexts.

Naming Consistency5/5

The vast majority of tools follow the verb_noun pattern with underscores (create_*, list_*, delete_*, etc.). Only minor deviations like 'whoami' exist, but the overall pattern is highly consistent and predictable.

Tool Count2/5

With 69 tools, the server has an excessive number for an MCP context, far exceeding the typical 3-15 range. While it may mirror the full redu.cloud API, the sheer count overwhelms agents and increases selection latency.

Completeness4/5

The tool set covers the majority of cloud management operations: CRUD for instances, volumes, databases, deployments, and more. However, update operations are missing for several resources (e.g., instance resize, volume resize), and there is no tool to modify deployments without redeploying.

Resources