Skip to main content
Glama
cygnussystems

cygnus-ssh-mcp

Official

ssh_host_update

Update fields on an existing SSH host configuration to safely rotate passwords, change ports, or adjust settings without editing the plaintext TOML file.

Instructions

Update one or more fields of an existing host configuration - this is the safe way to rotate a password, change a port, or adjust other settings without ever needing to read or hand-edit the host configuration TOML file (which stores every host's credentials in plaintext - never read it directly; this tool, ssh_conn_add_host, ssh_host_remove, and ssh_host_list cover everything you should need).

Only the fields you pass are changed - any parameter left at its default (omitted/None) keeps its current value. To clear a field entirely (e.g. drop a password when switching a host to key-only auth), pass an empty string "" rather than omitting it. user/host themselves can't be changed this way (that changes the 'user@host' key identity) - remove and re-add instead if you need that.

Prefer this over ssh_host_remove + ssh_conn_add_host for adjusting an existing host: remove+re-add loses every field you don't explicitly resupply, since ssh_conn_add_host has no knowledge of the entry it just deleted.

host_name may be either the 'user@hostname' key or a configured alias - resolved the same way as ssh_conn_connect.

Warn the user that any new password/passphrase value passed here will be visible to the LLM, the same caveat as ssh_conn_add_host.

Returns: On success: {'status': 'success', 'message', 'key', 'updated_fields' (list of field names that were actually changed)}. On failure (the update would leave neither a password nor a keyfile set, or a duplicate alias): {'status': 'error', 'error': <message>} - not a raised exception.

Raises: SshError: If host_name doesn't resolve to any configured host (tried as both key and alias).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
portNoNew SSH port. Omit to leave unchanged
aliasNoNew alias. Omit to leave unchanged; pass an empty string to clear it
keyfileNoNew SSH private key path. Omit to leave unchanged; pass an empty string to clear it (e.g. when switching to password-only auth)
passwordNoNew password. Omit to leave unchanged; pass an empty string to clear it (e.g. when switching to key-only auth)
host_nameYesThe 'user@hostname' key or alias of the host to update
descriptionNoNew description. Omit to leave unchanged; pass an empty string to clear it
sudo_passwordNoNew sudo password. Omit to leave unchanged; pass an empty string to clear it
key_passphraseNoNew passphrase for the SSH key. Omit to leave unchanged; pass an empty string to clear it

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.1

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: omitted fields retain current value, empty string clears, the update fails if it would leave neither password nor keyfile, duplicate aliases error, and failure returns a status dict rather than raising (with SshError reserved for unresolvable host_name). It also flags the plaintext-TOML sensitivity and the LLM-visibility caveat for secrets.

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 action and the safe-alternative framing, then edge cases and return shape. It is longer than strictly necessary (the plaintext warning overlaps the schema's secret flags, and the omit/empty-string rule is restated across fields), but every paragraph addresses a real decision an agent must make.

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?

An 8-parameter mutation tool with no annotations and an output schema, and the description covers all the load-bearing gaps: mutation semantics, clearing behavior, identity constraints, failure modes, and secret-handling warnings. Nothing needed 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 the baseline is 3, and the schema already repeats the omit/empty-string convention per parameter. The description nonetheless adds meaning the schema lacks: host_name resolves as either key or alias (same as ssh_conn_connect), and user/host are deliberately non-updatable. That is genuine value beyond structured fields, though much of the per-field guidance is duplicated.

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?

States a specific verb (update) plus resource (existing host configuration fields) and immediately scopes it against siblings: it names ssh_conn_add_host, ssh_host_remove, and ssh_host_list as the full set covering host config. An agent can distinguish this from ssh_conn_add_host without opening either schema.

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?

Explicitly states when to prefer this over ssh_host_remove + ssh_conn_add_host and why (re-add loses unlisted fields). Also states the negative case: user/host cannot be changed here, remove and re-add instead. Both routing conditions are spelled out.

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