Skip to main content
Glama
Sign In
SSH MCP Server

SSH MCP Server

by YawLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ssh_service_status

Read-only

Check a remote systemd service's status over SSH, including active state, PID, uptime, and description, without running raw systemctl commands.

Instructions

Check the status of a systemd service on a remote host. Returns whether it's active, its PID, uptime, and description. Use this instead of ssh_exec with systemctl.

Input Schema

NameRequiredDescriptionDefault
hostYesSSH hostname or IP address
portNoSSH port (default: 22)
serviceYesSystemd service name (e.g. nginx, sshd, docker)
timeoutNoCommand timeout in milliseconds (default: 30000). Also the longest the call waits for a free connection-pool slot (SSH_MCP_MAX_POOL_SIZE, default 100) before the command starts; the wait and the command are bounded separately.
passwordNoSSH password. STRONGLY prefer key-based auth (privateKeyPath or ssh-agent). Passwords pass through MCP protocol frames as plaintext and may be logged by the transport or host process.
usernameNoSSH username (default: current user)
privateKeyPathNoPath to SSH private key

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.17.0
    • changedInput schema / properties / timeout / description
      Previous value: -"Command timeout in milliseconds (default: 30000)"New value: +"Command timeout in milliseconds (default: 30000). Also the longest the call waits for a free connection-pool slot (SSH_MCP_MAX_POOL_SIZE, default 100) before the command starts; the wait and the command are bounded separately."
  2. Addedv0.9.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds value by disclosing the return payload (active state, PID, uptime, description), which is meaningful since there is no output schema. It doesn't mention failure behavior for an unreachable host or unknown unit, keeping it at 4.

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

Conciseness5/5

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

Three short sentences with no filler: purpose first, return contents second, sibling routing third. Every sentence earns its place.

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

Completeness4/5

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

With no output schema, the description usefully summarizes the returned fields, and the schema carries auth and timeout detail. Minor gaps on error/edge behavior (host unreachable, service not found) keep it just short of complete.

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

Parameters3/5

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

Schema description coverage is 100% and every parameter — including the plaintext-password warning and timeout/pool-slot semantics — is documented in the schema itself. The description adds nothing about the 'service' or 'host' arguments, so the baseline 3 applies.

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 ('Check the status of a systemd service on a remote host') and immediately distinguishes itself from the generic sibling by saying to use it instead of ssh_exec with systemctl. An agent can select it over the 20 siblings without opening the schema.

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?

Explicitly names the alternative it replaces ('Use this instead of ssh_exec with systemctl'), which is the key routing decision. It stops short of covering edge cases — e.g. non-systemd hosts or when ssh_exec would still be appropriate — so it is clear but not exhaustive.

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

Deploy Server

Other Tools