safe-ssh-mcp

Overview Schema Source Related Servers Discussions Admin

get_installed_packages

Lists installed packages and versions on a remote Linux host over SSH, selecting the available package manager to simplify software inventory checks.

Instructions

Lists installed packages with versions on a remote Linux host via SSH, using the first available package manager. The FIRST output line starts with '#' and names the package manager and the columns; the rest is one package per line: dpkg (Debian/Ubuntu), tab-separated: package, version, architecture, status ('ii' installed, 'hi' installed and held), source_package, source_version. Security advisories for Debian/Ubuntu are keyed by SOURCE package (openssh, not openssh-server). Removed packages whose config files are left behind (state 'rc') are not listed. rpm (RHEL/Fedora/SUSE): name-version-release.arch, as printed by rpm -qa. apk (Alpine), tab-separated: package, version, architecture, origin. Security advisories for Alpine are keyed by ORIGIN (openssl, not libcrypto3); it has the same version as the package.

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": {
      "host": "<host>",
      "user": "<user>"
    },
    "name": "get_installed_packages"
  }
}

Input Schema

Name	Required	Description	Default
`host`	Yes
`port`	No
`user`	Yes
`timeout`	No
`key_path`	No
`password`	No
`accept_new_hostkey`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.16Nov 10, 2026

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the burden and does add real value: it discloses SSH transport, the first-available-package-manager selection strategy, and that 'rc' state packages are excluded. It omits security-relevant behavior such as auth mode (password vs key), what accept_new_hostkey does, permission/sudo requirements, and what happens when no supported package manager is found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, which is good, but the bulk of the text is a multi-line enumeration of per-package-manager output formats despite an output schema existing. That detail is useful for parsing but is duplicative and crowds out connection-behavior guidance.

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

Completeness3/5

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

Return format is documented both here and in the output schema, so that is covered; however, for a 7-parameter SSH tool with no annotations, the description leaves connection semantics (auth choice, host key acceptance, timeout, failure modes) unexplained. Adequate for calling it, incomplete for calling it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 7 parameters, so the description must compensate. 'Remote Linux host via SSH' loosely contextualizes host, user, port, key_path and password, but it says nothing about timeout, accept_new_hostkey (a risky security toggle), or the defaults, leaving the most consequential parameter undefined.

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 and resource ('Lists installed packages with versions') plus transport and scope ('remote Linux host via SSH', 'first available package manager'). An agent can distinguish this from a single-package check like get_is_installed purely from the opening sentence.

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

Usage Guidelines3/5

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

The phrase 'lists installed packages' implies the inventory use case and the contrast with a per-package check is inferable, but the description never explicitly says when to pick this over siblings or what conditions make it inappropriate. Usage is implied rather than guided.

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

Deploy Server