Skip to main content
Glama
hypnosis

SSH MCP Server

by hypnosis
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

ssh_job_status

Read-only

Check the status of a detached job, see its last output lines, and understand whether 'lost' means missing exit code rather than failure.

Instructions

Reports the state of a detached job, with the last lines it wrote so you can see where it got to. lost means no exit code was left behind, not that the work failed — ssh_job_output still has the output.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesJob id returned by ssh_exec with detach: true. A job started with sudo is reached as root from the id alone — nothing extra to pass.
profileYesMachine name.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobsNo
legendNoWhat the words in this answer mean. A key names the field before the value — "state=limited", "jobs[].state=lost" — and only the values this answer actually used are listed.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changedv2.3.3
    • addedOutput schema / properties / jobs / items / properties / started_at / description
      Added value: +"Seconds since the epoch; null — the server did not record it."
    • addedOutput schema / properties / jobs / items / properties / state / description
      Added value: +"running — started and still running: this is not the outcome, come back later; finished — the job ended and reported its exit code; lost — the job is gone and left no exit code behind; missing — the server knows no job under this id."
  2. Changed2 schema fields changedv2.3.0
    • changedInput schema / properties / id / description
      Previous value: -"Job id returned by ssh_exec with detach: true"New value: +"Job id returned by ssh_exec with detach: true. A job started with sudo is reached as root from the id alone — nothing extra to pass."
    • addedOutput schema / properties / legend / description
      Added value: +"What the words in this answer mean. A key names the field before the value — \"state=limited\", \"jobs[].state=lost\" — and only the values this answer actually used are listed."
  3. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already mark the tool as read-only, so the description adds value by explaining the 'lost' status semantics and clarifying that 'lost' does not mean the work failed. It also discloses that the output remains available via ssh_job_output, which is useful behavioral context beyond what the annotations state.

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?

Two sentences convey the core purpose, the extra output detail, and the important 'lost' edge-case semantics. Every phrase carries meaning, and the key information is front-loaded.

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 simple read-only status tool with complete schema descriptions and an output schema present, the description covers all essential context. The 'lost' clarification removes a likely source of confusion, and the readOnlyHint addresses safety.

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?

The input schema already provides 100% parameter coverage with descriptive text for both 'id' and 'profile', including the note about sudo. The tool description itself adds no additional parameter-level meaning, so the baseline of 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?

The description uses a specific verb ('Reports') and a specific resource ('the state of a detached job'), and also states it includes the last lines written for progress visibility. This distinguishes it from sibling tools like ssh_job_output (which retrieves full output) and ssh_job_list (which lists jobs).

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 makes clear when to use this tool: to check the state of a detached job and see where it got to via its last lines. It also gives an implicit when-not by pointing to ssh_job_output for cases where the job is 'lost' but output still exists. It does not explicitly contrast with ssh_job_list, but the single-job framing is enough.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hypnosis/ssh-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server