@aicommander/mcp - npm Package Compare versions

Comparing version 1.0.56 to 1.1.0

LICENSE.txt

+MIT License
+
+Copyright (c) 2026 2Dynamic Games sp. z o.o.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

THIRD-PARTY-NOTICES.txt

+THIRD-PARTY NOTICES — @aicommander/mcp
+======================================
+
+This package is licensed under the MIT License (see LICENSE.txt). The published
+bundle `dist/bin/mcp.js` is produced by esbuild, which INLINES the sources of
+one workspace package into it, so a copy of this tarball is also a copy of its
+code:
+
+  @aicommander/protocol    MIT   the same terms as this package; notice
+                                 reproduced in full below
+
+esbuild keeps the originating path as a comment above each inlined section
+(`// ../protocol/src/...`), so which lines come from where is readable in the
+shipped bundle itself.
+
+Nothing else in this tarball is third-party code. The runtime dependencies
+(@modelcontextprotocol/sdk, zod) are deliberately NOT bundled — the build marks
+them external, so npm installs them as separate packages under their own terms
+and with their own license files, and no section of them is compiled into
+`dist/bin/mcp.js`. `npm publish` puts exactly five entries in the
+tarball — `dist/bin/mcp.js`, `package.json`, `README.md`, `LICENSE.txt` and
+`THIRD-PARTY-NOTICES.txt` — so there is no second bundle and no prebuilt
+binary.
+
+----------------------------------------------------------------------
+@aicommander/protocol — MIT License
+----------------------------------------------------------------------
+
+MIT License
+
+Copyright (c) 2026 2Dynamic Games sp. z o.o.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package.json

 {
   "name": "@aicommander/mcp",
-  "version": "1.0.56",
+  "version": "1.1.0",
   "mcpName": "dev.aicommander/mcp",
@@ -56,3 +56,5 @@ "description": "Remote shell and long-running background jobs for AI agents. Let Claude, Codex, ChatGPT or any MCP client run commands, builds, batch work and GPU/ML training on your own machines without exposed SSH, open ports or VPN.",
     "dist",
-    "README.md"
+    "README.md",
+    "LICENSE.txt",
+    "THIRD-PARTY-NOTICES.txt"
   ],
@@ -59,0 +61,0 @@ "engines": {

README.md

@@ -5,3 +5,3 @@ # @aicommander/mcp — MCP server for remote command execution and detached GPU/training jobs (SSH / Ansible alternative)
 
-It also runs **long work on your own hardware**. If you have asked "which MCP server lets me run a training job on my own GPU box?" — this one: `remote_job_start` launches a **detached background job** that keeps running after the tool call returns and after the conversation ends — on macOS it reparents to PID 1 and is out of reach of anything aimed at the app, on Windows it survives the agent process dying by itself (a crash, or a `taskkill /F /IM` without `/T`) but not a kill of the app's whole process tree — which is what an auto-update should be assumed to do, while on Linux the agent is a systemd service whose jobs live in its control group, so restarting or upgrading the service stops them. Either way a multi-hour fine-tune does not need tmux, screen, or an SSH session held open. `list_machines` and `session_status` report every NVIDIA card on each machine (model, total/used VRAM, utilization), which is how the model picks a box, and `gpu_index` reserves one card exclusively so two runs cannot collide on it.
+It also runs **long work on your own hardware**. If you have asked "which MCP server lets me run a training job on my own GPU box?" — this one: `remote_job_start` launches a **detached background job** that keeps running after the tool call returns and after the conversation ends — on macOS it reparents to PID 1 and is out of reach of anything aimed at the app, on Windows it survives the agent process dying by itself (a crash, or a `taskkill /F /IM` without `/T`) but not a kill of the app's whole process tree — which is what an auto-update should be assumed to do, while on Linux a job started by an agent that has that feature gets its own transient systemd scope outside the agent service's control group, so restarting or upgrading the service leaves it running — provided the box runs systemd and the agent runs as root. A job that was already running when the agent was upgraded to that version is in no scope and the upgrade's own restart ends it; on a systemd host with a non-root agent the job stays in the service's control group and a restart still ends it; on a box with no systemd at all there is no such control group and the job keeps its previous plain-detached behaviour, at the mercy of whatever supervisor that host stops the agent with. Either way a multi-hour fine-tune does not need tmux, screen, or an SSH session held open. `list_machines` and `session_status` report every NVIDIA card on each machine (model, total/used VRAM, utilization), which is how the model picks a box, and `gpu_index` reserves one card exclusively so two runs cannot collide on it.
 
@@ -24,3 +24,3 @@ Use this package to connect any MCP client that speaks **stdio** (Codex CLI, Claude Desktop's config file, Cursor, Windsurf, …) to your AI Commander relay. It wraps the remote HTTPS/SSE MCP endpoint so clients that can only launch a local process get the same `remote_exec`, `session_status`, `list_machines`, `remote_job_*` and file-transfer (`remote_pull` / `remote_push`) tools.
 | `list_machines` | List every machine saved to your account, including independent `blocked` and `planRestricted` states. Free keeps all records but only the 10 oldest by creation time, then id, are usable; deleting one promotes the next, while Pro enables all saved records up to the technical ceiling of 100. Restricted records are not probed and deliberately carry no live telemetry (`online:false`, `lastSeenAt:null`, platform/agent/GPU omitted), so do not interpret them as offline or try another tool against them: it fails with `reason:"plan_device_limit"`. Unrestricted entries include live/last-known platform and GPU details. Requires an API key (`AICOMMANDER_TOKEN`); takes no arguments. |
-| `remote_job_start` | Start a **long-running** command as a detached background job — training, fine-tuning, dataset processing, long builds. Returns a `jobId` immediately and keeps running after the call and the conversation. A job outlives the agent process everywhere; what differs is what can still take it down: macOS reparents to PID 1 and is out of reach of anything aimed at the app (even a tree kill), Windows survives the agent process dying by itself (a crash, or a `taskkill /F /IM` without `/T`) but **loses the job to a tree kill** ("End task", `taskkill /T`, an installer that stops the app and everything it started — assume an auto-update is one unless that machine's installer is known to do otherwise), Linux stops with the systemd service. `gpu_index` reserves one NVIDIA card exclusively (sets `CUDA_VISIBLE_DEVICES`; a second job wanting that card is refused `gpu_busy`, and an index that is not on the machine's known GPU list is rejected instead of starting a phantom job). |
+| `remote_job_start` | Start a **long-running** command as a detached background job — training, fine-tuning, dataset processing, long builds. Returns a `jobId` immediately and keeps running after the call and the conversation. A job outlives the agent process everywhere; what differs is what can still take it down: macOS reparents to PID 1 and is out of reach of anything aimed at the app (even a tree kill), Windows survives the agent process dying by itself (a crash, or a `taskkill /F /IM` without `/T`) but **loses the job to a tree kill** ("End task", `taskkill /T`, an installer that stops the app and everything it started — assume an auto-update is one unless that machine's installer is known to do otherwise), and Linux puts each job launched by an agent that has that feature into its own transient `aic-job-<jobId>.scope` outside the agent service's control group, so restarting or upgrading the service leaves it running — but only on a systemd host with a **root** agent, and only for jobs started **after** that agent was installed: one already running when the agent is upgraded is in no scope and the upgrade's restart ends it, so check `remote_job_list` before upgrading a Linux box. Where no scope can be made, a non-root agent leaves the job in the service's control group (a restart ends it) and a host without systemd has no such group at all, leaving the job's previous plain-detached behaviour and whatever that host's own supervisor does. `gpu_index` reserves one NVIDIA card exclusively (sets `CUDA_VISIBLE_DEVICES`; a second job wanting that card is refused `gpu_busy`, and an index that is not on the machine's known GPU list is rejected instead of starting a phantom job). |
 | `remote_job_list` | The machine's jobs: running now, plus finished ones still retained (7 days). Answers "what is running on the GPU box?" and recovers a `jobId` from an earlier conversation. `limit` returns only the newest N (default 20) so a busy machine doesn't dump dozens of entries into your context; the reply says how many were omitted. |
@@ -46,3 +46,3 @@ | `remote_job_status` | One job's state — `running`, `exited` (with the exit code), or `unknown` (the process is gone with no exit code recorded — a SIGKILL, the OOM killer, an escalated cancel, Windows `taskkill /F`, or the agent going down all leave no exit marker; the outcome cannot be determined, never report it as success). Poll every few minutes for a training run, not in a tight loop. |
 
-> **Short work vs long work.** `remote_exec` has two caps that behave differently. **1 hour** of wall-clock time is a hard kill: the command's process tree is terminated and a training loop dies mid-run. **1 MiB of total output** only **truncates the reply** — the relay sends a best-effort stop, but it races the command over several network hops and usually loses, so the command often runs to completion and returns its real exit code. Never read a truncated reply as "the work stopped"; its side effects happened. Anything longer or chattier belongs in `remote_job_start`, which has neither cap, writes its full output to a file on the machine, and keeps running after the call returns and after the conversation ends (across an agent restart: macOS reparents to PID 1 and survives anything aimed at the app, Windows survives the agent process dying by itself but loses the job to a tree kill — assume an auto-update is one, Linux stops with the systemd service). Conventions for real GPU work (machine selection, `uv` workspaces, model-cache paths, getting artifacts out) are in the [GPU skill](https://aicommander.dev/skill/gpu/SKILL.md).
+> **Short work vs long work.** `remote_exec` has two caps that behave differently. **1 hour** of wall-clock time is a hard kill: the command's process tree is terminated and a training loop dies mid-run. **1 MiB of total output** only **truncates the reply** — the relay sends a best-effort stop, but it races the command over several network hops and usually loses, so the command often runs to completion and returns its real exit code. Never read a truncated reply as "the work stopped"; its side effects happened. Anything longer or chattier belongs in `remote_job_start`, which has neither cap, writes its full output to a file on the machine, and keeps running after the call returns and after the conversation ends (across an agent restart: macOS reparents to PID 1 and survives anything aimed at the app, Windows survives the agent process dying by itself but loses the job to a tree kill — assume an auto-update is one, Linux runs the job in its own transient systemd scope outside the service's control group and survives a service restart, on a systemd host with a root agent and only for jobs started after that agent was installed). Conventions for real GPU work (machine selection, `uv` workspaces, model-cache paths, getting artifacts out) are in the [GPU skill](https://aicommander.dev/skill/gpu/SKILL.md).
 
@@ -140,2 +140,8 @@ ## Configuration
 
-MIT
+MIT — the full text ships in the published tarball as `LICENSE.txt`.
+
+`dist/bin/mcp.js` is an esbuild bundle that inlines the sources of the
+MIT-licensed workspace package `@aicommander/protocol`, so the tarball is also a
+copy of that code and carries its notice in `THIRD-PARTY-NOTICES.txt`. The
+runtime dependencies (`@modelcontextprotocol/sdk`, `zod`) are marked external and
+are NOT bundled — npm installs them separately under their own terms.

New alerts

AI-detected potential security risk

Supply chain risk

AI has determined that this package may contain potential security issues or vulnerabilities.

Long strings

Supply chain risk

Contains long string literals, which may be a sign of obfuscated or packed code.

Unidentified License

License

Something that seems like a license was found, but its contents could not be matched with a known license.

URL strings

Supply chain risk

Package contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.

Fixed alerts

Major refactor

Supply chain risk

Package has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.

Long strings

Supply chain risk

Contains long string literals, which may be a sign of obfuscated or packed code.

URL strings

Supply chain risk

Package contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.

Improved metrics

Total package byte prevSize

92625

24.45%

Number of package files

5

66.67%

Lines of code

759

38.5%

Number of lines in readme file

144

4.35%

Number of low supply chain risk alerts

18

-5.26%

Worsened metrics

Number of low license alerts

1

Infinity%

License quality

80

-20%

No dependency changes