hostinger-api-mcp 3.30.1 → 3.31.0

package/CHANGELOG.md

@@ -4,6 +4,29 @@ Generated at release time from the diff between the previous and current
 build. Tool changes are listed individually; everything else is summarised
 by area.
 
+## v3.31.0 — 2026-11-06
+
+### Operations
+
+- Changed the description of `horizons_websites_get`
+
+### Also in this release
+
+- Documentation: `README.md`
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Build and packaging: `types.d.ts`
+
+## v3.30.2 — 2026-11-06
+
+### Also in this release
+
+- Documentation: `README.md`
+- Distribution manifests: `gemini-extension.json`
+- Bundled agent skills: 18 files
+- OAuth sign-in flow: `src/core/oauth.js`, `src/core/oauth.ts`
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.30.1 — 2026-11-05
 
 ### Also in this release

package/README.md

@@ -133,11 +133,14 @@ hostinger-api-mcp --logout
 
 ### JSON configuration for Claude, Cursor, etc.
 
+Register Node and the server script by absolute path, never `npx` or a bare `node`/`hostinger-api-mcp`: tools start the server in your project, where `npx` puts the project's `node_modules/.bin` first on `PATH`, a version manager (asdf, mise) runs whatever Node the project's `.tool-versions` names, and Windows looks a bare name up in the project folder first. Any of these lets a cloned repository run its own code with your Hostinger credentials. After the global install, `node -p process.execPath` prints the Node path and `npm root -g` the folder that holds `@hostinger/mcp`. Run both from your home folder.
+
 ```json
 {
     "mcpServers": {
         "hostinger-api": {
-            "command": "hostinger-api-mcp",
+            "command": "/absolute/path/to/node",
+            "args": ["/absolute/path/to/global/node_modules/@hostinger/mcp/src/servers/all.js"],
             "env": {
                 "DEBUG": "false",
                 "HOSTINGER_API_TOKEN": "YOUR API TOKEN"
@@ -1907,7 +1910,9 @@ Get the link for the user to open their website in Hostinger Horizons interface.
 Use this tool when the user wants the link to an existing website, or when you need its
 website URL before or after editing it.\n
 `is_in_progress` is true while changes are being generated or the website is being published;
-wait until it is false before publishing. `published_at` is when the website was last published,
+wait until it is false before publishing. `is_generating` is true while changes are being generated,
+and `actions_in_progress` has `website_publish` while the website is being published.
+`published_at` is when the website was last published,
 `is_template` is whether its published pages show the "Use template" banner, and
 `has_ecommerce_store` is whether it has an online store.\n
 Websites can be edited with the `Edit website` tool, or by the user in Hostinger Horizons

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.30.1",
+  "version": "3.31.0",
   "description": "Hostinger API — manage domains, DNS, hosting, VPS, billing and more from Gemini CLI.",
   "mcpServers": {
     "hostinger": {
@@ -9,6 +9,7 @@
         "-y",
         "@hostinger/mcp"
       ],
+      "cwd": "${extensionPath}",
       "env": {
         "HOSTINGER_API_TOKEN": "${HOSTINGER_API_TOKEN}"
       }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.30.1",
+  "version": "3.31.0",
   "mcpName": "io.github.hostinger/hostinger-api-mcp",
   "description": "MCP server for Hostinger API",
   "repository": {

package/server.json

@@ -17,12 +17,12 @@
     "url": "https://github.com/hostinger/api-mcp-server",
     "source": "github"
   },
-  "version": "3.30.1",
+  "version": "3.31.0",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "3.30.1",
+      "version": "3.31.0",
       "transport": {
         "type": "stdio"
       },

package/skills/headless/SKILL.md

@@ -192,13 +192,15 @@ has usually outlasted the job, so it returns at once. The single rule that makes
 ### Waiting on Hostinger: `wait.mjs`
 
 `wait.mjs` (next to this file) waits for a slow Hostinger job in one command, so you don't spend a turn
-on every check:
+on every check. Run it, like `push-content.mjs`, from the home folder (`cd "$HOME" && …`): both
+start the Hostinger MCP server with the user's sign-in, and a version manager's `node` (asdf, mise)
+runs whatever Node the current project's `.tool-versions` names:
 
 ```bash
-node <skill>/wait.mjs setup <domain>              # a fresh site's setup → completed
-node <skill>/wait.mjs cms <domain> <username>     # a shell swap's WordPress install at /cms → valid
-node <skill>/wait.mjs build <domain> <buildUuid>  # the deploy build → completed, then the root serves 200
-node <skill>/wait.mjs live <domain>               # the root serves 200
+cd "$HOME" && node <skill>/wait.mjs setup <domain>              # a fresh site's setup → completed
+cd "$HOME" && node <skill>/wait.mjs cms <domain> <username>     # a shell swap's WordPress install at /cms → valid
+cd "$HOME" && node <skill>/wait.mjs build <domain> <buildUuid>  # the deploy build → completed, then the root serves 200
+cd "$HOME" && node <skill>/wait.mjs live <domain>               # the root serves 200
 ```
 
 Run it in the foreground, with a `--timeout` just under your tool's command limit (e.g. `--timeout 9m`

package/skills/headless/VERSION

@@ -1,3 +1,3 @@
-version=3.30.1
-commit=4d02050e3406
-built=2026-11-05
+version=3.31.0
+commit=27fa03d3cce1
+built=2026-11-06

package/skills/headless/connect/SKILL.md

@@ -77,10 +77,10 @@ Read `<skill>/VERSION`: its line 1 is the skills version this run uses, which go
 Run the bundled script. It verifies the MCP server and handles sign-in, emitting one JSON event per line on stdout. Run it as a background/streaming process. Show the user only the sign-in URL (`awaiting_user`) or a
 failure's `detail`, and handle the other events silently (table below).
 
-The script is safe and inspectable: it only checks the MCP server via `npx` and drives the OAuth sign-in (a browser flow with a localhost callback) — no other network calls, no filesystem writes.
+The script is safe and inspectable: it copies the launcher to `~/.hostinger/mcp/launch.mjs`, checks the MCP server through it and drives the OAuth sign-in (a browser flow with a localhost callback) — no other network calls, no other filesystem writes.
 
 ```bash
-node <skill>/connect/bootstrap.mjs
+cd "$HOME" && node <skill>/connect/bootstrap.mjs
 ```
 
 ### Relay these events
@@ -89,11 +89,12 @@ The script emits one JSON object per line:
 
 | Event | What to do                                                                                                                                                                                                                           |
 | --- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `launcher` (`command`, `args`) | How to start the MCP server: use these for every registration (Phase 2). |
 | `mcp_ok` | MCP server reachable — continue.                                                                                                                                                                                                     |
 | `logged_in` | Already authenticated (env token or a previous sign-in) — continue.                                                                                                                                                                  |
 | `awaiting_user` (`verificationUri`) | A browser window should have opened on the user's machine. Show the URL in plain prose and wait for the user to finish signing in. The OAuth callback lands on a localhost port, so the sign-in must be completed on this same machine. |
 | `success` | Bootstrap done — continue to Phase 2. |
-| `mcp_unreachable` / `login_failed` (with `detail`) | Stop and show the user the `detail`. Do not improvise a parallel setup by hand. |
+| `launcher_failed` / `mcp_unreachable` / `login_failed` (with `detail`) | Stop and show the user the `detail`. Do not improvise a parallel setup by hand. |
 
 If the environment has a `HOSTINGER_API_TOKEN` set (for example CI), the bootstrap reports `logged_in` immediately — no browser needed.
 
@@ -107,8 +108,8 @@ hostinger-api-mcp --login
 hostinger-api-mcp --logout
 
 # Without a global install:
-npx --yes --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-api-mcp --login
-npx --yes --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-api-mcp --logout
+cd "$HOME" && node "$HOME/.hostinger/mcp/launch.mjs" --login
+cd "$HOME" && node "$HOME/.hostinger/mcp/launch.mjs" --logout
 ```
 
 Credentials live in `~/.config/hostinger-mcp/credentials.json` (macOS/Linux) or `%APPDATA%\hostinger-mcp\credentials.json` (Windows) and are shared by every Hostinger MCP binary. OAuth works only when the tool runs the server over its default local (stdio) transport, which is what every registration below uses; `--http` needs `HOSTINGER_API_TOKEN`.
@@ -127,8 +128,8 @@ one group says nothing about the other:
 
 | Group | Operations | Comes from | Needed by |
 |---|---|---|---|
-| **Hosting** | `hosting_*` (websites, deploy, build report), `wordpress_*` | `hostinger` (`npx -y --prefix="$HOME" @hostinger/mcp@latest`), or the scoped servers such as `hostinger-hosting` + `hostinger-wordpress` | every build |
-| **Ecommerce** | `ecommerce_*` (stores, products, shipping, payments) | **only** `hostinger-ecommerce` (`npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp`), or the Ecommerce MCP in the Hostinger Connector. Neither `hostinger` nor the scoped hosting servers include it | Ecommerce backends (chosen later, in refine) |
+| **Hosting** | `hosting_*` (websites, deploy, build report), `wordpress_*` | `hostinger` (`<command> <launcher>`), or the scoped servers such as `hostinger-hosting` + `hostinger-wordpress` | every build |
+| **Ecommerce** | `ecommerce_*` (stores, products, shipping, payments) | **only** `hostinger-ecommerce` (`<command> <launcher> hostinger-ecommerce-mcp`), or the Ecommerce MCP in the Hostinger Connector. Neither `hostinger` nor the scoped hosting servers include it | Ecommerce backends (chosen later, in refine) |
 
 Check each group on its own, right here at connect, before anything else:
 
@@ -148,8 +149,8 @@ Most coding tools load MCP servers only when they start, so a server registered
 until the tool restarts. When either tool group above is missing:
 
 1. **Register the missing servers** in the tool's MCP config, as the tool route below shows: `hostinger`
-   (`npx -y --prefix="$HOME" @hostinger/mcp@latest`) if the hosting group is missing, and `hostinger-ecommerce`
-   (`npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp`) if the ecommerce group is missing.
+   (`<command> <launcher>`) if the hosting group is missing, and `hostinger-ecommerce`
+   (`<command> <launcher> hostinger-ecommerce-mcp`) if the ecommerce group is missing.
    Skip a server that is already registered under its name. When neither group is there, register
    both: the backend isn't chosen until refine, and one restart then covers every backend.
 2. **Write `connect.json`** (Phase 3) before you stop. The skill folder from Phase 1 stays in place,
@@ -163,12 +164,28 @@ until the tool restarts. When either tool group above is missing:
 
 If a tool loads new servers without a restart (VS Code), use them right away and skip steps 3–4.
 
-**Every `npx` command and registration keeps `--prefix` set to the user's home folder.** The tool
-starts the server, and you run commands, in the user's project, often a cloned repository or
-template. Without `--prefix`, npm reads the `.npmrc` there, and whoever wrote it can point npx at
-another registry or run their own code. In shell commands write `--prefix="$HOME"` (the shell expands
-it when you register). In JSON or TOML configs replace `<home>` with the home folder's absolute path
-(`echo $HOME`, e.g. `/Users/me` or `C:\\Users\\me`). Never drop the flag or leave `<home>` in place.
+**Every registration and every command that starts the MCP server goes through the launcher**
+(`~/.hostinger/mcp/launch.sh` and `launch.mjs`, which the bootstrap writes): never `npx` directly, with or without
+`--prefix`. The tool starts the server, and you run commands, in the user's project, often a cloned
+repository or template. npx run there puts the project's `node_modules/.bin` first on PATH and reads
+its `.npmrc`, so whoever wrote the project runs their own `node` with the user's Hostinger sign-in.
+The launcher runs npx from the home folder instead. A registration runs exactly the bootstrap's
+`launcher` event, never a bare `node`: a version manager (asdf, mise) picks the Node that the project's
+own `.tool-versions` names. On macOS and Linux the event is `/bin/sh` with `launch.sh`, which finds
+Node only after moving to the home folder, so Node upgrades don't break it; on Windows it is the
+absolute path of `node.exe` with `launch.mjs`. Replace `<command>` and `<launcher>` with that event's
+`command` and `args[0]`, in shell commands and in JSON or TOML configs alike, and never leave a
+placeholder in place. In JSON and TOML configs, double every backslash of a Windows path
+(`C:\\Program Files\\nodejs\\node.exe`); a single one is an escape there (`\n` in `\nodejs` becomes a
+newline). Commands you run yourself start in the home folder
+(`cd "$HOME" && node …`) for the same reason.
+
+**An existing Hostinger registration is "already registered" only when it runs exactly the
+bootstrap's `launcher` event** (same `command`, `args[0]` the launcher, plus `hostinger-ecommerce-mcp`
+for that server). Before you trust one (both groups present, or a name the tool lists), check its
+command (Claude Code: `claude mcp get <name>`; otherwise the tool's MCP config). Anything else, such as
+`npx`, a bare `node` or `hostinger-api-mcp`, or any other command or path than the event's:
+remove it and register it again through the launcher, then follow *register, restart, resume*.
 
 | Tool        | Route                           |
 |-------------|---------------------------------|
@@ -180,7 +197,7 @@ it when you register). In JSON or TOML configs replace `<home>` with the home fo
 | Devin       | `connect/tools/devin.md`        |
 
 If the user's tool isn't listed yet, connect it the generic way: register both Hostinger MCP servers
-in that tool's MCP config (command `npx`, args as above), then follow *register, restart, resume*.
+in that tool's MCP config (command `<command>`, args `<launcher>` as above), then follow *register, restart, resume*.
 
 ### The skills come from Phase 1 only
 

package/skills/headless/connect/bootstrap.mjs

@@ -2,10 +2,10 @@
 // Hostinger Headless — bootstrap.
 // Verifies the Hostinger MCP server is reachable and drives the OAuth sign-in,
 // emitting one JSON event per line on stdout so a coding agent can relay
-// progress to the user. No filesystem writes besides what the MCP itself
-// stores (OAuth credentials); no network calls of its own.
+// progress to the user. Its only writes are the launcher (~/.hostinger/mcp/launch.mjs, which
+// coding tools register) and what the MCP itself stores (OAuth credentials); no network calls of its own.
 import { spawn, spawnSync } from 'node:child_process';
-import { existsSync, readFileSync } from 'node:fs';
+import { copyFileSync, existsSync, mkdirSync, readFileSync } from 'node:fs';
 import path from 'node:path';
 import os from 'node:os';
 
@@ -17,19 +17,30 @@ const fail = (event, extra = {}) => {
   process.exit(1);
 };
 
-// ── platform-safe binary names (npm/npx are .cmd on Windows) ─────────────────
+// ── the MCP server, always through the launcher ──────────────────────────────
+// launch.mjs runs the latest published package via npx from the home folder (see its header for why
+// npx must never run in the project). Coding tools register the home copy, which every run refreshes,
+// so a registration keeps working when the skill folder moves to a new version.
 const isWin = process.platform === 'win32';
-const bin = (name) => (isWin ? `${name}.cmd` : name);
-// Run the MCP via npx — no global install, always the latest published version.
-// Use --package so npx resolves the published package, then invoke the unified binary.
-const MCP = [bin('npx'), '-y', '--package=@hostinger/mcp@latest', 'hostinger-api-mcp'];
-// Node >= 18.20.2 / 20.12.2 refuses to spawn a .cmd/.bat without a shell
-// (CVE-2024-27980), so npx.cmd needs shell:true on Windows. Our args are all
-// fixed literals, so enabling the shell introduces no injection risk.
-const spawnShell = isWin;
+const LAUNCHER = path.join(os.homedir(), '.hostinger', 'mcp', 'launch.mjs');
+try {
+  mkdirSync(path.dirname(LAUNCHER), { recursive: true });
+  copyFileSync(new URL('./launch.mjs', import.meta.url), LAUNCHER);
+  copyFileSync(new URL('./launch.sh', import.meta.url), LAUNCHER.replace(/\.mjs$/, '.sh'));
+} catch (e) {
+  fail('launcher_failed', { detail: String(e) });
+}
+const MCP = [process.execPath, LAUNCHER];
+// A registration never names a bare `node`: Windows looks it up in the working directory (the project)
+// first, and a version manager's shim (asdf, mise) runs the Node the project's .tool-versions names.
+// macOS/Linux register /bin/sh with launch.sh, which finds node only after moving to home, so Node
+// upgrades keep working. Windows names this Node by absolute path (this script runs from home).
+emit('launcher', isWin
+  ? { command: process.execPath, args: [LAUNCHER] }
+  : { command: '/bin/sh', args: [LAUNCHER.replace(/\.mjs$/, '.sh')] });
 
 function capture(cmd, args) {
-  const r = spawnSync(cmd, args, { encoding: 'utf8', shell: spawnShell, cwd: os.homedir() });
+  const r = spawnSync(cmd, args, { encoding: 'utf8', cwd: os.homedir() });
   return { status: r.status ?? 1, out: `${r.stdout || ''}${r.stderr || ''}`, error: r.error };
 }
 
@@ -72,7 +83,7 @@ function existingAuth() {
 // prefix — forward it so the agent can show it if the browser didn't open.
 function login() {
   return new Promise((resolve) => {
-    const child = spawn(MCP[0], [...MCP.slice(1), '--login'], { shell: spawnShell, cwd: os.homedir() });
+    const child = spawn(MCP[0], [...MCP.slice(1), '--login'], { cwd: os.homedir() });
     let diag = '';
     let urlSent = false;
     const collect = (chunk) => {

package/skills/headless/connect/launch.mjs

@@ -0,0 +1,42 @@
+#!/usr/bin/env node
+// Hostinger Headless — starts the latest Hostinger MCP server for a coding tool or a script.
+//   node launch.mjs [hostinger-<group>-mcp] [--login | --logout | --version]
+//
+// Coding tools start stdio servers in the user's project, often a cloned repository or template.
+// npx run there puts <project>/node_modules/.bin, and the same folder of every parent, first on PATH
+// (no npm flag turns that off) and reads the project's .npmrc, so the project's own `node` would run
+// the server with the user's Hostinger credentials. This launcher runs npx from the home folder, with
+// no relative or node_modules entries left on PATH, so nothing in the project is ever looked up.
+import { spawn } from 'node:child_process';
+import { homedir } from 'node:os';
+import path from 'node:path';
+
+const [PACKAGE, DEFAULT_BIN] = ['--package=@hostinger/mcp@latest', 'hostinger-api-mcp'];
+const isWin = process.platform === 'win32';
+const home = homedir();
+
+const args = process.argv.slice(2);
+// npx.cmd needs a shell on Windows (CVE-2024-27980), so every argument must be shell-inert.
+if (args.some((a) => !/^[\w@.=:/-]+$/.test(a))) {
+  process.stderr.write(`launch.mjs: unexpected argument in ${JSON.stringify(args)}\n`);
+  process.exit(2);
+}
+const bin = /^[a-z0-9-]+-mcp$/.test(args[0] ?? '') ? args.shift() : DEFAULT_BIN;
+
+// Windows may spell it Path; a relative entry or a node_modules folder can come from the project.
+// The server returns to the project once started, so relative paths in tool arguments still work
+// (launch.sh has already moved to home and names the project itself).
+const env = { ...process.env, MCP_PROJECT_DIR: process.env.MCP_PROJECT_DIR || process.cwd() };
+for (const key of Object.keys(env).filter((k) => k.toUpperCase() === 'PATH')) {
+  env[key] = env[key].split(path.delimiter)
+    .filter((p) => path.isAbsolute(p) && !p.split(/[\\/]/).includes('node_modules'))
+    .join(path.delimiter);
+}
+
+const child = spawn(isWin ? 'npx.cmd' : 'npx', ['-y', PACKAGE, bin, ...args], { cwd: home, env, stdio: 'inherit', shell: isWin });
+for (const signal of ['SIGINT', 'SIGTERM', 'SIGHUP']) process.on(signal, () => child.kill(signal));
+child.on('error', (e) => {
+  process.stderr.write(`launch.mjs: could not start npx: ${e.message}\n`);
+  process.exit(1);
+});
+child.on('exit', (code, signal) => process.exit(code ?? (signal ? 1 : 0)));

package/skills/headless/connect/launch.sh

@@ -0,0 +1,23 @@
+#!/bin/sh
+# Hostinger Headless — what coding tools register on macOS and Linux: /bin/sh <home>/.hostinger/mcp/launch.sh
+# /bin/sh never moves, and node is looked up only here, after moving to the home folder, so a Node
+# upgrade (Homebrew, nvm, asdf) keeps the registration working, and a version manager's shim picks the
+# user's own Node, never the one a project's .tool-versions names. Relative and node_modules entries
+# are dropped from PATH first: either could hold a node the project put there.
+# The server returns to the project once started (relative paths in tool arguments), so name it first.
+MCP_PROJECT_DIR=$(pwd)
+export MCP_PROJECT_DIR
+cd || exit 1
+set -f
+safe=
+IFS=:
+for dir in $PATH; do
+  case $dir in
+    /*node_modules*) ;;
+    /*) safe=${safe:+$safe:}$dir ;;
+  esac
+done
+unset IFS
+PATH=$safe
+export PATH
+exec node "${0%/*}/launch.mjs" "$@"

package/skills/headless/connect/tools/antigravity.md

@@ -12,7 +12,7 @@ description: "Specific Antigravity Hostinger MCP Server connection instructions
 
 The later stages drive the Hostinger connector through Antigravity's native MCP tools. Check **both** tool groups (hosting and ecommerce), as *Check both tool groups* in `connect/SKILL.md`
 says: other Hostinger tools responding doesn't mean the `hostinger-ecommerce` ones are there. Both
-respond → use them and move on.
+respond and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → use them and move on.
 
 If either is missing, add the missing server(s) to `~/.gemini/antigravity/mcp_config.json` (Windows:
 `C:\Users\<USERNAME>\.gemini\antigravity\mcp_config.json`), which you can reach from the Agent panel's
@@ -25,12 +25,12 @@ no tokens to handle:
 {
   "mcpServers": {
     "hostinger": {
-      "command": "npx",
-      "args": ["-y", "--prefix=<home>", "@hostinger/mcp@latest"]
+      "command": "<command>",
+      "args": ["<launcher>"]
     },
     "hostinger-ecommerce": {
-      "command": "npx",
-      "args": ["--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
+      "command": "<command>",
+      "args": ["<launcher>", "hostinger-ecommerce-mcp"]
     }
   }
 }

package/skills/headless/connect/tools/claude-code.md

@@ -19,14 +19,14 @@ groups as *Check both tool groups* in `connect/SKILL.md` says:
   `hostinger-wordpress`, `hostinger-domains`, …) never include it, so a session full of
   `mcp__hostinger-*__*` tools can still be missing it.
 
-Both present → use them and move on. Either missing → register the missing server(s) at user scope
+Both present and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → use them and move on. Either missing → register the missing server(s) at user scope
 now (`claude mcp list` shows what's already registered; skip those). The bootstrap already signed you
 in, so they reuse the cached sign-in (`~/.config/hostinger-mcp/credentials.json`, or
 `HOSTINGER_API_TOKEN`) and there are no tokens to handle:
 
 ```bash
-claude mcp add hostinger --scope user -- npx -y --prefix="$HOME" @hostinger/mcp@latest                                     # hosting group missing
-claude mcp add hostinger-ecommerce --scope user -- npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp  # ecommerce group missing
+claude mcp add hostinger --scope user -- "<command>" "<launcher>"                                     # hosting group missing
+claude mcp add hostinger-ecommerce --scope user -- "<command>" "<launcher>" hostinger-ecommerce-mcp  # ecommerce group missing
 ```
 
 Claude Code loads MCP servers only at startup, so follow *register, restart, resume* in

package/skills/headless/connect/tools/codex.md

@@ -12,27 +12,27 @@ description: "Specific Codex Hostinger MCP Server connection instructions for th
 
 The later stages drive the Hostinger connector through Codex's native MCP tools. Check **both** tool groups (hosting and ecommerce), as *Check both tool groups* in `connect/SKILL.md`
 says: other Hostinger tools responding doesn't mean the `hostinger-ecommerce` ones are there. Both
-respond → use them and move on.
+respond and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → use them and move on.
 
 If either is missing, register the missing server(s); skip one already registered. The bootstrap already signed you in, so they reuse the cached
 sign-in (`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) and there are no tokens
 to handle:
 
 ```bash
-codex mcp add hostinger -- npx -y --prefix="$HOME" @hostinger/mcp@latest
-codex mcp add hostinger-ecommerce -- npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp
+codex mcp add hostinger -- "<command>" "<launcher>"
+codex mcp add hostinger-ecommerce -- "<command>" "<launcher>" hostinger-ecommerce-mcp
 ```
 
 or add them to `~/.codex/config.toml`:
 
 ```toml
 [mcp_servers.hostinger]
-command = "npx"
-args = ["-y", "--prefix=<home>", "@hostinger/mcp@latest"]
+command = "<command>"
+args = ["<launcher>"]
 
 [mcp_servers.hostinger-ecommerce]
-command = "npx"
-args = ["--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
+command = "<command>"
+args = ["<launcher>", "hostinger-ecommerce-mcp"]
 ```
 
 Codex loads MCP servers only when it starts, so follow *register, restart, resume* in

package/skills/headless/connect/tools/cursor.md

@@ -13,13 +13,13 @@ description: "Specific Cursor Hostinger MCP Server connection instructions for t
 
 **Prerequisite:** Node.js 20 or newer on `PATH` (`node -v`). The published package engines require `>=20`; use Node 24 if you follow the package README.
 
-The Hostinger MCP is the npm package `@hostinger/mcp`. You do **not** need a global install — Cursor (and this session) can run it through `npx`. Prefer the unified binary `hostinger-api-mcp` (every operation). Scoped binaries such as `hostinger-hosting-mcp` are optional.
+The Hostinger MCP is the npm package `@hostinger/mcp`. You do **not** need a global install — Cursor (and this session) run it through the launcher (`~/.hostinger/mcp/`, written by the connect bootstrap), which starts the latest release with `npx` from your home folder. Never run `npx` for it directly: from the project, npx would run the project's own `node`. `<command>` and `<launcher>` below come from the bootstrap's `launcher` event (see `connect/SKILL.md`). Prefer the unified binary `hostinger-api-mcp` (every operation). Scoped binaries such as `hostinger-hosting-mcp` are optional.
 
 ### Option A — no global install (recommended)
 
 ```bash
 # Verify the package/binary is reachable
-npx --yes --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-api-mcp --version
+cd "$HOME" && node "$HOME/.hostinger/mcp/launch.mjs" --version
 ```
 
 ### Option B — global install
@@ -37,7 +37,7 @@ hostinger-api-mcp --version
 Check **both** tool groups, as *Check both tool groups* in `connect/SKILL.md` says: hosting
 (`mcp__hostinger__*` or `mcp__hostinger-hosting__*`) **and** ecommerce (`mcp__hostinger-ecommerce__*`).
 The scoped `mcp__hostinger-*__*` servers never include ecommerce, so they alone don't count. Both
-present → skip registration: go to Step 2 only if you still need sign-in, otherwise go to Step 3.
+present and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → skip registration: go to Step 2 only if you still need sign-in, otherwise go to Step 3.
 
 If either is missing, register the missing server(s) in `~/.cursor/mcp.json` (global, so every project and every
 later run has them). Merge them into any existing `mcpServers` rather than replacing the file.
@@ -48,12 +48,12 @@ OAuth can run:
 {
   "mcpServers": {
     "hostinger": {
-      "command": "npx",
-      "args": ["--yes", "--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-api-mcp"]
+      "command": "<command>",
+      "args": ["<launcher>"]
     },
     "hostinger-ecommerce": {
-      "command": "npx",
-      "args": ["--yes", "--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
+      "command": "<command>",
+      "args": ["<launcher>", "hostinger-ecommerce-mcp"]
     }
   }
 }
@@ -74,7 +74,7 @@ If the connect bootstrap already emitted `logged_in` / `success`, credentials ar
 Otherwise run the login command. It registers a dynamic OAuth client (once per machine), **opens the user's browser** to Hostinger's authorization page, listens on a localhost callback, stores tokens, and exits:
 
 ```bash
-npx --yes --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-api-mcp --login
+cd "$HOME" && node "$HOME/.hostinger/mcp/launch.mjs" --login
 ```
 
 (With a global install: `hostinger-api-mcp --login`.)
@@ -95,7 +95,7 @@ They are shared across every Hostinger MCP binary. Expired access tokens refresh
 To sign out later:
 
 ```bash
-npx --yes --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-api-mcp --logout
+cd "$HOME" && node "$HOME/.hostinger/mcp/launch.mjs" --logout
 ```
 
 **API token (optional, CI / scripts):** set `HOSTINGER_API_TOKEN` in the environment before launching Cursor. When present it always wins and no OAuth code runs. Do not commit the token.

package/skills/headless/connect/tools/devin.md

@@ -12,7 +12,7 @@ description: "Specific Devin Hostinger MCP Server connection instructions for th
 
 The later stages drive the Hostinger connector through Devin's native MCP tools. Check **both** tool groups (hosting and ecommerce), as *Check both tool groups* in `connect/SKILL.md`
 says: other Hostinger tools responding doesn't mean the `hostinger-ecommerce` ones are there. Both
-respond → use them and move on.
+respond and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → use them and move on.
 
 If either is missing, register the missing server(s) for Devin; skip one already registered. The bootstrap already signed you in, so they reuse the
 cached sign-in (`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) and there are no
@@ -21,18 +21,18 @@ tokens to handle.
 - **Devin CLI:**
 
   ```bash
-  devin mcp add hostinger -- npx -y --prefix="$HOME" @hostinger/mcp@latest
-  devin mcp add hostinger-ecommerce -- npx --prefix="$HOME" --package=@hostinger/mcp@latest hostinger-ecommerce-mcp
+  devin mcp add hostinger -- "<command>" "<launcher>"
+  devin mcp add hostinger-ecommerce -- "<command>" "<launcher>" hostinger-ecommerce-mcp
   ```
 
 - **Devin app:** Settings → MCP Marketplace → **Add Your Own**, transport **STDIO**, once per server:
 
   ```json
-  { "command": "npx", "args": ["-y", "--prefix=<home>", "@hostinger/mcp@latest"] }
+  { "command": "<command>", "args": ["<launcher>"] }
   ```
 
   ```json
-  { "command": "npx", "args": ["--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"] }
+  { "command": "<command>", "args": ["<launcher>", "hostinger-ecommerce-mcp"] }
   ```
 
 If the tools still aren't in this session, follow *register, restart, resume* in `connect/SKILL.md`:

package/skills/headless/connect/tools/vscode.md

@@ -12,7 +12,7 @@ description: "Specific VS Code Hostinger MCP Server connection instructions for
 
 The later stages drive the Hostinger connector through VS Code's native MCP tools. Check **both** tool groups (hosting and ecommerce), as *Check both tool groups* in `connect/SKILL.md`
 says: other Hostinger tools responding doesn't mean the `hostinger-ecommerce` ones are there. Both
-respond → use them and move on.
+respond and both registrations run the launcher (*An existing Hostinger registration* in `connect/SKILL.md`) → use them and move on.
 
 If either is missing, register the missing server(s) for VS Code; skip one already registered. The bootstrap already signed you in, so they reuse
 the cached sign-in (`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) and there are
@@ -25,13 +25,13 @@ no tokens to handle. Add them to `.vscode/mcp.json` (workspace) or your user `se
   "servers": {
     "hostinger": {
       "type": "stdio",
-      "command": "npx",
-      "args": ["-y", "--prefix=<home>", "@hostinger/mcp@latest"]
+      "command": "<command>",
+      "args": ["<launcher>"]
     },
     "hostinger-ecommerce": {
       "type": "stdio",
-      "command": "npx",
-      "args": ["--prefix=<home>", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
+      "command": "<command>",
+      "args": ["<launcher>", "hostinger-ecommerce-mcp"]
     }
   }
 }
@@ -40,8 +40,8 @@ no tokens to handle. Add them to `.vscode/mcp.json` (workspace) or your user `se
 Or add them in two commands:
 
 ```bash
-code --add-mcp '{"name":"hostinger","command":"npx","args":["-y","--prefix=<home>","@hostinger/mcp@latest"]}'
-code --add-mcp '{"name":"hostinger-ecommerce","command":"npx","args":["--prefix=<home>","--package=@hostinger/mcp@latest","hostinger-ecommerce-mcp"]}'
+code --add-mcp '{"name":"hostinger","command":"<command>","args":["<launcher>"]}'
+code --add-mcp '{"name":"hostinger-ecommerce","command":"<command>","args":["<launcher>","hostinger-ecommerce-mcp"]}'
 ```
 
 VS Code picks up new servers and their tools become available right away, with no editor restart.

package/skills/headless/hostinger-mcp.mjs

@@ -3,20 +3,15 @@
 
 import { spawn } from 'node:child_process';
 import { homedir } from 'node:os';
+import { fileURLToPath } from 'node:url';
 
-// ── platform-safe binary names (npm/npx are .cmd on Windows), as in connect/bootstrap.mjs ──────────
-const isWin = process.platform === 'win32';
-const bin = (name) => (isWin ? `${name}.cmd` : name);
-const MCP = [bin('npx'), '-y', '--package=@hostinger/mcp@latest', 'hostinger-api-mcp'];
-// Node >= 18.20.2 / 20.12.2 refuses to spawn a .cmd/.bat without a shell
-// (CVE-2024-27980), so npx.cmd needs shell:true on Windows. Our args are all
-// fixed literals, so enabling the shell introduces no injection risk.
-const spawnShell = isWin;
+// ── always through the launcher, which runs npx from the home folder, never in the project ─────────
+const MCP = [process.execPath, fileURLToPath(new URL('./connect/launch.mjs', import.meta.url))];
 
 // One server per script run. Once it dies every pending and later call rejects, so the caller ends with
 // exit 2 rather than hanging.
 export function connect(clientName) {
-  const child = spawn(MCP[0], MCP.slice(1), { stdio: ['pipe', 'pipe', 'pipe'], shell: spawnShell, cwd: homedir() });
+  const child = spawn(MCP[0], MCP.slice(1), { stdio: ['pipe', 'pipe', 'pipe'], cwd: homedir() });
   const pending = new Map();
   let buffer = '';
   let diag = '';