Skip to main content
Glama
pmboxbiz

mcp-ssh-live

by pmboxbiz

ssh_list_jobs

List all jobs (running, finished, crashed) on SSH hosts with metadata. Filter by host to assess capacity before spawning new jobs.

Instructions

List every job registered on this mcp-ssh-live server — running, finished-but-not-yet-reaped, and crashed. Returns metadata only (job_id, cmd, host, label, started_at, finished_at, exit_status, status, pid, pty, stdout_lines, stderr_lines); use ssh_tail to fetch the actual output of a specific job.

Filter by host with the 'host' argument (alias or raw address). Pass include_finished=false to see only still-running jobs, which is typical when deciding whether to spawn a new one without hitting the max_jobs_per_host cap.

Finished jobs are kept in the registry for a grace window (reap_finished_after_sec, default 600 s) so you can still fetch their final tail output after they exit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNoIf provided, only return jobs whose host equals this alias OR whose raw address matches. If omitted or null, return jobs across every host. We resolve the filter against the config so a user who types the raw IP still gets jobs tagged with the configured alias.
include_finishedNoWhen True (default), return jobs in every lifecycle state. When False, skip jobs that have already exited / crashed / been killed — useful for capacity planning.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

With no annotations, description discloses key behaviors: returns metadata only, filter resolution against config, grace window for finished jobs (reap_finished_after_sec). Could mention auth or rate limits, but given the nature of a read-only list, this is solid.

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 well-organized paragraphs: what the tool does, filtering, and reaping behavior. Front-loaded with key info. No unnecessary words.

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?

Covers the main aspects of the tool: listing, filtering, metadata-only return, and grace window. Output schema exists so return values are not needed. Slightly missing ordering or pagination, but these are minor for a local list tool.

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%, baseline 3. Description adds meaning beyond schema: explains host resolution (alias vs raw address) and the purpose of include_finished=false (capacity planning, avoiding max_jobs_per_host).

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 lists every job on the server, returns metadata only, and distinguishes from ssh_tail for fetching output. It is specific with verb 'list' and resource 'jobs'.

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 tells when to use this tool (to list jobs) vs when to use ssh_tail (to fetch output). Provides guidance on filtering by host and using include_finished=false for capacity planning.

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/pmboxbiz/mcp-ssh-live'

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