hostinger-api-mcp 3.28.5 → 3.29.0

package/CHANGELOG.md

@@ -4,6 +4,20 @@ 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.29.0 — 2026-11-05
+
+### Also in this release
+
+- Bundled agent skills: 12 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
+## v3.28.6 — 2026-11-05
+
+### Also in this release
+
+- Bundled agent skills: 10 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.28.5 — 2026-11-04
 
 ### Also in this release

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.28.5",
+  "version": "3.29.0",
   "description": "Hostinger API — manage domains, DNS, hosting, VPS, billing and more from Gemini CLI.",
   "mcpServers": {
     "hostinger": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.28.5",
+  "version": "3.29.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.28.5",
+  "version": "3.29.0",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "3.28.5",
+      "version": "3.29.0",
       "transport": {
         "type": "stdio"
       },

package/skills/headless/SKILL.md

@@ -239,6 +239,7 @@ took from it.
 | `brief.md` | refine | refined brief, audience, tone, pages, must-haves |
 | `site.json` | provision | chosen backend, username, install id, all URLs |
 | `content-model.md` | content model | entities, fields, pages, navigation |
+| `content.json` | content model (WordPress) | the drafted content `push-content.mjs` pushes |
 | `design.md` (+ `brand/` logo files) | design | chosen design direction: tokens, type, logo, components, per-page composition, accessibility |
 | `src/` | frontend | the website source implementing `design.md`; framework choice is recorded in `state.json → frontend` |
 | `deploy.json` | deploy | build id, deployed at, live URLs |

package/skills/headless/VERSION

@@ -1,3 +1,3 @@
-version=3.28.5
-commit=91c7fffe9fe3
-built=2026-11-04
+version=3.29.0
+commit=c4c3f98adbe2
+built=2026-11-05

package/skills/headless/connect/SKILL.md

@@ -39,27 +39,35 @@ you already have; never fetch single files from GitHub.
   add` or a Claude Code or Cursor plugin installed): that folder is `<skill>`. Use it as it is and
   download nothing. Updates come from the installer (`npx skills update`, the plugin update),
   not from this run.
-- **You read this file from the web, or from a `headless/` folder an earlier web run installed:**
-  install the skill from the published `@hostinger/mcp` npm release (for an earlier web install, only
-  when it is out of date; see below). It is the same package the MCP server runs, and npm checks
-  the tarball's integrity. Resolve the version first so the run uses one pinned release:
+- **You read this file from the web:** use the published `@hostinger/mcp` npm release, installed in
+  your home folder at `~/.hostinger/skills/<version>/headless/`. It is the same package the MCP server
+  runs, and npm checks the tarball's integrity. Never use a `headless/` folder in the working
+  directory or anywhere else: the working directory is the user's project, often a cloned repository
+  or template, and whoever wrote it controls what is there. Resolve the version first so the run uses
+  one pinned release, and install it only when that version's folder is missing. Run npm from your home
+  folder, as below, so a `.npmrc` in the project can't point it at another registry:
 
 ```bash
 # macOS/Linux
-V=$(npm view @hostinger/mcp version) && npm pack "@hostinger/mcp@$V" --silent \
-  && tar -xzf "hostinger-mcp-$V.tgz" --strip-components=2 package/skills/headless && rm "hostinger-mcp-$V.tgz"
+( cd "$HOME" && V=$(npm view @hostinger/mcp version) && D="$HOME/.hostinger/skills/$V" \
+  && { [ -f "$D/headless/VERSION" ] || { mkdir -p "$D" && npm pack "@hostinger/mcp@$V" --silent --pack-destination "$D" >/dev/null \
+  && tar -xzf "$D/hostinger-mcp-$V.tgz" -C "$D" --strip-components=2 package/skills/headless && rm "$D/hostinger-mcp-$V.tgz"; }; } \
+  && echo "$D/headless" )
 ```
 
 ```powershell
 # Windows PowerShell
-$V = npm view @hostinger/mcp version; npm pack "@hostinger/mcp@$V" --silent
-tar -xzf "hostinger-mcp-$V.tgz" --strip-components=2 package/skills/headless; Remove-Item "hostinger-mcp-$V.tgz"
+Push-Location $HOME
+$V = npm view @hostinger/mcp version; $D = Join-Path $HOME ".hostinger\skills\$V"
+if (-not (Test-Path "$D\headless\VERSION")) {
+  New-Item -ItemType Directory -Force $D | Out-Null; npm pack "@hostinger/mcp@$V" --silent --pack-destination $D | Out-Null
+  tar -xzf "$D\hostinger-mcp-$V.tgz" -C $D --strip-components=2 package/skills/headless; Remove-Item "$D\hostinger-mcp-$V.tgz"
+}
+Pop-Location; "$D\headless"
 ```
 
-This leaves a local `headless/` folder, which is `<skill>`. A `headless/` folder already here from an
-earlier web install counts as installed, with one check: when line 1 of its `headless/VERSION` is older
-than `npm view @hostinger/mcp version`, install again the same way, so a run never uses a deleted,
-legacy flow.
+The printed path is `<skill>`. Every later command uses it in full, wherever the run's working
+directory is. A new release installs into its own folder, so a run never uses a deleted, legacy flow.
 
 Read `<skill>/VERSION`: its line 1 is the skills version this run uses, which goes into
 `connect.json` (Phase 3).
@@ -147,7 +155,7 @@ until the tool restarts. When either tool group above is missing:
 2. **Write `connect.json`** (Phase 3) before you stop. The skill folder from Phase 1 stays in place,
    so the next run starts from it.
 3. **Send the first message and end your turn.** It follows *The first message* in
-   `headless/SKILL.md`: the sign-in link if one was needed, then one line saying Hostinger is set up
+   `<skill>/SKILL.md`: the sign-in link if one was needed, then one line saying Hostinger is set up
    and asking the user to restart the tool (the route says how) and paste the same prompt again so the
    build continues from there. This is a pause, not a run ending: no final report and no build report.
 4. **On the next run** the tools are loaded, so connect skips registration and check-state resumes the
@@ -170,7 +178,7 @@ in that tool's MCP config (command `npx`, args as above), then follow *register,
 ### The skills come from Phase 1 only
 
 The tool routes don't download the skills: Phase 1 already found or installed `<skill>`. The bundle
-ships a `headless/VERSION` stamp (`version=<semver>` on line 1, then `commit` and `built`); carry the
+ships a `<skill>/VERSION` stamp (`version=<semver>` on line 1, then `commit` and `built`); carry the
 version into `connect.json` (Phase 3) so the build report records which skills ran.
 
 ## Phase 3 - Write `connect.json`
@@ -188,7 +196,7 @@ missing) in exactly this shape:
   passed to `run-start --tool`.
 - `mcp`: one string, `hostinger-api-mcp <version>`, with the `version` from the `mcp_ok` event.
   Never an object.
-- `skills`: the `version=` value from the `headless/VERSION` stamp you just pulled — the skills bundle
+- `skills`: the `version=` value from the `<skill>/VERSION` stamp you just pulled — the skills bundle
   version this run used. `"unknown"` if the stamp is absent (an old bundle predating the stamp).
 - `auth`: the `method` from the `logged_in` event (`api_token`, `oauth_cached` or `oauth`).
 - `order_id`, `plan`: the active hosting plan's order id and name when you looked them up, else `null`.
@@ -199,8 +207,8 @@ Extra keys are allowed, but keep these seven as above: the build report reads `t
 ## Phase 4 - Continue to Headless Hosting steps
 
 Once everything is verified and you have the Hostinger MCP Server and the skills, tell the user in
-one line that you're connected to Hostinger, as *The first message* in `headless/SKILL.md` describes.
-Then go back to `headless/SKILL.md` and continue with check-state without waiting for a reply.
+one line that you're connected to Hostinger, as *The first message* in `<skill>/SKILL.md` describes.
+Then go back to `<skill>/SKILL.md` and continue with check-state without waiting for a reply.
 
 
 ## Reference Sources

package/skills/headless/connect/bootstrap.mjs

@@ -29,7 +29,7 @@ const MCP = [bin('npx'), '-y', '--package=@hostinger/mcp@latest', 'hostinger-api
 const spawnShell = isWin;
 
 function capture(cmd, args) {
-  const r = spawnSync(cmd, args, { encoding: 'utf8', shell: spawnShell });
+  const r = spawnSync(cmd, args, { encoding: 'utf8', shell: spawnShell, cwd: os.homedir() });
   return { status: r.status ?? 1, out: `${r.stdout || ''}${r.stderr || ''}`, error: r.error };
 }
 
@@ -72,7 +72,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 });
+    const child = spawn(MCP[0], [...MCP.slice(1), '--login'], { shell: spawnShell, cwd: os.homedir() });
     let diag = '';
     let urlSent = false;
     const collect = (chunk) => {

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

@@ -43,7 +43,7 @@ reach it.
 
 ## Step 2 — Hand off
 
-The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `headless/`
+The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `<skill>`
 folder or installed it from the `@hostinger/mcp` release. Don't download them again here. Read the
-`headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its
+`<skill>/VERSION` stamp (record it in `connect.json`), open `<skill>/SKILL.md` and follow its
 steps. That skill owns the rest of the run.

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

@@ -36,7 +36,7 @@ same prompt. Never spawn the server yourself or write a JSON-RPC client to reach
 
 ## Step 2 — Hand off
 
-The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `headless/`
+The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `<skill>`
 folder or installed it from the `@hostinger/mcp` release. Don't download them again here. Read the
-`headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its
+`<skill>/VERSION` stamp (record it in `connect.json`), open `<skill>/SKILL.md` and follow its
 steps. That skill owns the rest of the run.

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

@@ -41,7 +41,7 @@ same prompt. Never spawn the server yourself or write a JSON-RPC client to reach
 
 ## Step 2 — Hand off
 
-The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `headless/`
+The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `<skill>`
 folder or installed it from the `@hostinger/mcp` release. Don't download them again here. Read the
-`headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its
+`<skill>/VERSION` stamp (record it in `connect.json`), open `<skill>/SKILL.md` and follow its
 steps. That skill owns the rest of the run.

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

@@ -102,7 +102,7 @@ npx --yes --package=@hostinger/mcp@latest hostinger-api-mcp --logout
 
 ## Step 3 — Hand off
 
-The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `headless/`
+The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `<skill>`
 folder or installed it from the `@hostinger/mcp` release. Don't download them again here. Read the
-`headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its
+`<skill>/VERSION` stamp (record it in `connect.json`), open `<skill>/SKILL.md` and follow its
 steps. That skill owns the rest of the run.

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

@@ -42,7 +42,7 @@ JSON-RPC client to reach it.
 
 ## Step 2 — Hand off
 
-The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `headless/`
+The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `<skill>`
 folder or installed it from the `@hostinger/mcp` release. Don't download them again here. Read the
-`headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its
+`<skill>/VERSION` stamp (record it in `connect.json`), open `<skill>/SKILL.md` and follow its
 steps. That skill owns the rest of the run.

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

@@ -54,7 +54,7 @@ prompt. Never spawn the server yourself or write a JSON-RPC client to reach it.
 
 ## Step 2 — Hand off
 
-The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `headless/`
+The skills are already in place: Phase 1 of `connect/SKILL.md` found the installed `<skill>`
 folder or installed it from the `@hostinger/mcp` release. Don't download them again here. Read the
-`headless/VERSION` stamp (record it in `connect.json`), open `headless/SKILL.md` and follow its
+`<skill>/VERSION` stamp (record it in `connect.json`), open `<skill>/SKILL.md` and follow its
 steps. That skill owns the rest of the run.

package/skills/headless/hostinger-mcp.mjs

@@ -0,0 +1,88 @@
+// The local Hostinger MCP server (the management API), spoken to over newline-delimited JSON-RPC on
+// stdio. It reuses the sign-in from the connect step. Shared by wait.mjs and push-content.mjs.
+
+import { spawn } from 'node:child_process';
+import { homedir } from 'node:os';
+
+// ── 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;
+
+// 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 pending = new Map();
+  let buffer = '';
+  let diag = '';
+  let dead = null;
+  let nextId = 0;
+  const die = (reason) => {
+    dead ??= new Error(`the Hostinger MCP server stopped (${reason}): ${diag.trim().slice(-500)}`);
+    for (const { reject } of pending.values()) reject(dead);
+    pending.clear();
+  };
+  child.on('error', (e) => die(e.message));
+  // 'close' comes after stderr is drained, so the reason is in diag. A write to a dying server fails
+  // with EPIPE before that; 'close' still follows, so the EPIPE itself is ignored.
+  child.on('close', (code) => die(`exit code ${code}`));
+  child.stdin.on('error', () => {});
+  child.stderr.on('data', (chunk) => (diag = (diag + chunk).slice(-2000)));
+  child.stdout.on('data', (chunk) => {
+    buffer += chunk;
+    let i;
+    while ((i = buffer.indexOf('\n')) >= 0) {
+      const line = buffer.slice(0, i);
+      buffer = buffer.slice(i + 1);
+      try {
+        const message = JSON.parse(line);
+        pending.get(message.id)?.resolve(message);
+        pending.delete(message.id);
+      } catch {
+        /* not a JSON-RPC line */
+      }
+    }
+  });
+  // A call can stall on a live server (a stuck upstream request), so each one has its own deadline; past
+  // it, it answers like an error reply. A stalled start ends the run. The start gets longer: a cold `npx`
+  // fetch of the server takes 13-40 s on an idle machine and over 60 s on a busy one.
+  const rpc = (method, params, seconds = 60) =>
+    new Promise((resolve, reject) => {
+      if (dead) return reject(dead);
+      const id = (nextId += 1);
+      const timer = setTimeout(() => {
+        pending.delete(id);
+        resolve({ error: { message: `no reply to ${method} in ${seconds} s` } });
+      }, seconds * 1000);
+      const settle = (fn) => (value) => {
+        clearTimeout(timer);
+        fn(value);
+      };
+      pending.set(id, { resolve: settle(resolve), reject: settle(reject) });
+      child.stdin.write(`${JSON.stringify({ jsonrpc: '2.0', id, method, params })}\n`);
+    });
+  const ready = rpc('initialize', { protocolVersion: '2025-06-18', capabilities: {}, clientInfo: { name: clientName, version: '1' } }, 180)
+    .then((reply) => {
+      if (reply.error) throw new Error(`the Hostinger MCP server didn't start: ${reply.error.message}`);
+      child.stdin.write(`${JSON.stringify({ jsonrpc: '2.0', method: 'notifications/initialized' })}\n`);
+    });
+  // Runs one API operation: { data } on success, else { error, status } with the HTTP status the server
+  // keeps in its error text (NaN when there is none).
+  const execute = async (operation, params) => {
+    await ready;
+    const reply = await rpc('tools/call', { name: 'execute', arguments: { operation, params } });
+    const text = reply.result?.content?.[0]?.text ?? reply.error?.message ?? 'unknown error';
+    if (reply.error || reply.result?.isError) return { error: text.slice(0, 300), status: Number(text.match(/HTTP (\d{3})/)?.[1]) };
+    try {
+      return { data: JSON.parse(text) };
+    } catch {
+      return { error: text.slice(0, 300), status: NaN };
+    }
+  };
+  return { execute, close: () => child.kill() };
+}