Skip to main content
Glama
TMYTiMidlY

portal-mcp-server

by TMYTiMidlY

remote_job

Run a command on a remote host in the background and return a job ID immediately. Poll for output incrementally or cancel the job as needed.

Instructions

Run a command in the background and get a job_id back immediately, so you can keep thinking while it runs, poll for incremental output, and cancel it. Use this for long tasks; for a command that finishes quickly just use remote_exec (it waits and returns the result).

Actions

  • action="submit": start command on host in the background — in a LOGIN shell (bash -lc, loading ~/.profile/.bashrc PATH+env; login=False to opt out) via nohup + remote tmp files — returning {job_id, host, remote_pid, started_at, status} right away. The job keeps running even if the SSH connection drops. NOTE: sudo / secret injection are NOT supported in the background and passing use_sudo=True or secrets=[...] here is rejected with guidance (sudo -S needs a stdin the nohup process detaches; secrets would land on argv / ps for the whole job) — run those with remote_exec (one-shot) or remote_shell instead.

  • action="poll": fetch this job's status + new output on demand, not all at once. Required: job_id. Pass since= to get only the bytes produced since then; each poll returns at most max_bytes (default 64 KiB) so a big backlog doesn't dump in one shot. Keep polling with since=new_offset while the returned more is true to drain the rest. Or pass tail=N to just peek the last N lines. Returns {status: running|done|failed|cancelled| unknown, exit_code?, output_chunk, new_offset, more, finished_at?}.

  • action="cancel": signal the job. Required: job_id. signal=TERM (default) or KILL. Best-effort — kill doesn't guarantee instant death; poll to confirm. Returns {job_id, signal_sent, status_after}.

  • action="list": list all known jobs {job_id, host, status, started_at, age_s, exit_code?}.

Limits (L1): job_ids are best-effort persisted across a server restart (the table reloads from /jobs.json and a poll re-probes the remote PID); set PORTAL_JOB_PERSIST=0 to disable. It's not a durable queue — a crash mid-write loses the view, but the remote process keeps running and is recoverable via ps. Finished jobs are swept after a TTL (default 1h) and their tmp files removed. There is a cap on concurrent live jobs (default 50).

Manual fallback (no remote_job): you can always background a command yourself with remote_exec(command="nohup mycmd >/tmp/x.log 2>&1 & echo $!") and poll the log with remote_exec(command="tail /tmp/x.log").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNo
tailNo
loginNo
sinceNo
actionYes
job_idNo
signalNoTERM
commandNo
secretsNo
use_sudoNo
max_bytesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations provided, so description carries full burden. It thoroughly discloses behavioral traits: background execution via nohup, login shell behavior, persistence across restarts, concurrent job limits, TTL cleanup, and why sudo/secrets are rejected. Also notes best-effort persistence and recovery via ps.

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?

The description is quite long but well-structured with sections for actions and limits. However, it includes a 'Manual fallback' section that may be extraneous for an AI agent. It is front-loaded with the main purpose but could be more concise by trimming less essential details.

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?

Given the tool's complexity (11 parameters, 4 actions, persistence, limits), the description is highly complete. It covers all actions with parameter requirements, explains output schema fields implicitly, mentions persistence behavior and limits, and provides a fallback. The presence of an output schema (context indicates exists) reduces the need to describe return values.

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 0%, so description must compensate. It explains most parameters in context of actions: for poll, it explains since, max_bytes, tail; for cancel, signal; for submit, command, host, login. It explains the login parameter's default and ability to opt out. However, not all parameters are explicitly described (e.g., host's default is not clarified, tail default is not mentioned), but overall adds significant meaning beyond schema.

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 runs a command in the background and returns a job_id immediately. It distinguishes itself from sibling tools by noting when to use remote_exec (quick commands) versus this tool (long tasks). The four actions (submit, poll, cancel, list) are clearly enumerated with specific purposes.

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?

Explicit usage guidance: use for long tasks, use remote_exec for quick tasks. Also specifies what not to do: sudo/secrets are rejected and explains why, directing to remote_exec or remote_shell instead. Provides a manual fallback alternative using remote_exec.

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/TMYTiMidlY/portal-mcp-server'

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