Termalin MCP Server

List the recent background jobs on a server (newest first): id, state, start time and the command.

Start a long-running shell command on a server in the background and return a job id right away. Use it for anything that can take more than about a minute — package installs, builds, backups, migrations, large downloads. The job keeps running after this call returns and survives the connection closing; its output goes to a log you read with job_status. The command runs from the login user's home directory. On a Windows server the command is PowerShell.

Check a background job started with job_start: whether it is still running or finished (with its exit code), when it started, and the last lines of its output.

Stop a background job started with job_start (asks it to terminate, then forces it after two seconds). Does nothing if the job already finished.

Put an internal web service of one of the user's servers into the owner's Termalin cabinet as an 'internal site': a dashboard, admin panel or app that listens only inside that server's network (e.g. localhost:3000 on the server, or 10.0.0.5:8080 next to it). Termalin gives it its own address that only the owner can open, signed in to Termalin, through the server's Connector — nothing is exposed to the internet and no port is opened. Only private addresses are accepted. One site opens every page of an app: if the server already has a site on the same host:port, that one is returned (reused: true) instead of a new one, and open_url lands on the path you gave — so to send the user to another page or file of the same app, call this again with that path. To rename a site or point it at another port, use web_link_update rather than removing and adding. Returns the link's id, open_url and url. Give the user open_url to open the site (it signs them in to Termalin first). The <slug>.termal.ink address in url shows 'This link doesn't work' to anyone without a session, the owner included, until opened from the account. This tool does not open or read the site, and it can't give anyone else access: sharing with other people is done by the owner in the cabinet. An account can hold a limited number of internal sites; when it is reached, ask the owner to remove one (web_link_delete).

Remove an internal site from the owner's Termalin cabinet by its id (from web_link_list). Its address stops working at once, for the owner and for anyone the owner shared it with. The service on the server is not touched.

The internal sites in the owner's Termalin cabinet on the servers you can reach: id, name, server, target, open_url, url, who added it (the owner or an AI app), when, and how many people the owner shared it with. Give the user open_url to open a site (it signs them in to Termalin first); the url address shows 'This link doesn't work' without a session, the owner included, until opened from the account. Sharing is managed by the owner in the cabinet.

Change one of the internal sites in the owner's Termalin cabinet by its id (from web_link_list or web_link_create): rename it, or point it at another host:port or start page when the app moved — instead of removing it and adding a new one. It keeps its address and the people the owner shared it with. When it now leads somewhere else, everyone signed in to it is signed out and opens it again. To send the user to another page of the same app, don't change the site: call web_link_create with that path, which returns this site with an open_url for the page.

Make an encrypted backup of one of the user's servers now, through Termalin's backup job for that server, and wait for it (up to about a minute; a longer one keeps running and shows up in backup_list). Call it BEFORE a risky change — a migration, a config rewrite, a bulk delete — and say so in 'label'. A job can hold folders and databases (PostgreSQL, MySQL/MariaDB, also inside a Docker container) — the archive then has a .sql dump of each. The server needs a confirmed backup job: if it has none, propose one with backup_job_create (it is a draft until the owner confirms it in the cabinet, which makes the encryption key); a draft can't be run. Uses the owner's storage quota, and keeps the job's 'keep last' count: when that many archives exist, the oldest one is removed.

Propose a new encrypted backup job for one of the user's servers: folders and/or databases, how often, how many copies to keep, where to store them. It is saved as a DRAFT in the owner's Termalin cabinet and nothing runs yet; the result has a link the owner opens to confirm it with one click — that creates the job's encryption key, which only the owner holds and which can't be made here. Give them the link and say what the job will back up. Drafts expire after 7 days and count against the plan's job limit. Databases are dumped on the server (Linux or macOS) with pg_dump / mysqldump, also inside a running Docker container, into a .sql file in the archive. No database password is passed or stored: the dump signs in through the local socket (PostgreSQL as the 'postgres' system user by default, MySQL/MariaDB as root's socket login), with a credentials file the owner keeps on the server (a .pgpass or my.cnf path), or — in a container — with the container's own settings (POSTGRES_USER, MYSQL_ROOT_PASSWORD).

The backup jobs and recent archives of one of the user's servers: what each job covers (folders and databases), when it ran, whether it succeeded, how big it is and where it is stored; drafts waiting for the owner's confirmation are marked DRAFT with their confirmation link; also the storage the owner set up (names usable as backup_job_create's destination). Use it to check that a backup exists before a risky change, or to see whether last night's backup worked.

Run a database query on one of your servers — passwordless. It executes the engine's own client on the host over Termalin's keyless tunnel, using the database's local trust (Postgres peer auth via `sudo -u postgres`, MySQL/MariaDB unix-socket via `sudo mysql`, redis-cli, mongosh, sqlite3) — so no database password is needed or stored anywhere. Read-only by default: only SELECT/SHOW-style statements run unless allowWrites is set (full-access keys only). SQL engines return CSV/TSV with a header. For MongoDB pass a shell expression, e.g. db.products.find({}).limit(20).toArray().

Describe one table of a database on one of your servers: its columns with type, whether they can be empty, default value and primary key. Call it before writing a query against a table you have not seen. Works for postgres, mysql, mariadb and sqlite.

List the tables / collections / keys of a database on one of your servers — passwordless, over the same local-client path as data_query.

List a directory on one of your servers over SFTP. Returns each entry's name, whether it's a directory, size and modified time. Runs keyless over Termalin's tunnel, like ssh_exec.

Read a text file from one of your servers over SFTP and return its contents. Files over 512 KB or non-text (binary) files are refused — use ssh_exec (e.g. sed/tail) for those.

Create or overwrite a text file on one of your servers over SFTP. 'content' is written as UTF-8. Folders on the way that don't exist yet are created (pass create_dirs: false to refuse instead), on Linux, macOS and Windows servers (C:/path/file or C:\path\file). Capped at 512 KB; for binary uploads use a terminal/scp instead.

Run a single shell command on one of your servers and return its combined output and exit code. Runs keyless over Termalin's tunnel — no SSH key, and the server needs no open inbound port. Each call is a fresh shell (cd does not persist — chain with &&). On a Windows server the command is PowerShell (PowerShell 7 when installed, else Windows PowerShell 5.1); a program's stderr comes back as plain text and the exit code is the program's own. A call waits 60 seconds by default; pass 'timeout' (seconds, up to 300) for a bit longer, e.g. a sleep plus some work. Some chat apps stop waiting sooner than that, so for anything long (installs, builds, backups) use job_start and check on it with job_status.

Run the same shell command on several of your servers at once and return each server's output and exit code. Use it to compare or check a fleet (disk space, versions, a service's state) in one call instead of one call per server. Up to 10 servers, run in parallel; the same time limit as ssh_exec (60 seconds by default, 'timeout' up to 300). Name the servers in 'hosts', or give 'tag' to run on every server that has those tags or groups (from hosts_list, e.g. ["distro:ubuntu", "prod"]). For long work use job_start on each server instead.

What Termalin's monitoring says is wrong with the user's servers right now (disk filling up, memory or load pinned, a failed service, a restarting container, a certificate about to expire, a server offline), plus what cleared in the last seven days. Start here when asked how the servers are doing. Covers servers with metrics switched on.

Generate a strong random password — handy when creating a user or setting a password on a server. Returns the password only; nothing is stored.

List the servers reachable through Termalin (your tunnel agents). Returns id, name, whether the server is online, the user commands run as, when it was last seen, its country, ip (the public address the server's Connector connects from; null until it has connected), and ownerNote — what the owner wrote about that server for you (what it is, what to leave alone); follow it. 'policy' says what you may do there: full, allowlist (only listed commands; allowedCommands holds the server's list, no file writes) or readonly (no commands, no file writes). 'tags' are the owner's labels for the server (prod, neuroshop…) and 'groups' the ones Termalin knows by itself (os:linux, distro:ubuntu, release:ubuntu-24.04, country:fr); pass 'tag' to list only the servers that have all of the given ones. Use the id (or the exact name) as 'host' in the other tools.

Numbers Termalin's monitoring collects from the user's servers every minute, without running anything now: CPU, memory, disk, load, network, the busiest processes, failed services, containers, certificates. Without `host`: one line per server with its latest numbers. With `host`: that server's latest sample in full and the average and peak over the last `hours` (default 6). Use it for 'how is the server doing' and 'what happened at night' before reaching for ssh_exec. Covers servers with metrics switched on.

What is waiting to be installed on the user's servers, from Termalin's hourly check (nothing is run or installed): how many updates and security updates, the security packages by name and target version, whether the server asks for a reboot, a newer kernel installed but not yet running, and how old the package lists are. Without arguments: every server; 'host' for one, or 'tag' for a group (from hosts_list, e.g. "distro:ubuntu" or "prod"). Also the known vulnerabilities (CVEs) in what is installed, matched daily: severity, the fixed version, and whether it is known to be exploited (CISA KEV); 'cve' answers "which servers have CVE-...". Linux servers (apt, dnf, apk). Use it before planning updates; installing is a separate step the user agrees to.