hostinger-api-mcp 3.28.4 → 3.28.6

package/CHANGELOG.md

@@ -4,6 +4,21 @@ 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.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
+
+- Distribution manifests: `server.json`
+- Bundled agent skills: `skills/headless/VERSION`
+- Other files: `logo.svg`
+
 ## v3.28.4 — 2026-11-04
 
 ### Also in this release

package/gemini-extension.json

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

package/logo.svg

@@ -0,0 +1,3 @@
+<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path fill-rule="evenodd" clip-rule="evenodd" d="M3.75016 11.3869V2.35969L8.30628 4.78911V8.8563L14.3377 8.85921L18.9677 11.3869H3.75016ZM15.571 8.11201V2.35938L20.25 4.72834V10.8301L15.571 8.11201ZM15.571 19.1455V15.1134L9.49311 15.1092C9.49879 15.136 4.78624 12.5411 4.78624 12.5411L20.25 12.6136V21.6407L15.571 19.1455ZM3.75 19.1455L3.75016 13.2464L8.30628 15.9002V21.5143L3.75 19.1455Z" fill="#673DE6"/>
+</svg>

package/package.json

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

package/server.json

@@ -1,17 +1,28 @@
 {
   "$schema": "https://static.modelcontextprotocol.io/schemas/2025-10-17/server.schema.json",
   "name": "io.github.hostinger/hostinger-api-mcp",
+  "title": "Hostinger",
   "description": "MCP server for Hostinger API",
+  "websiteUrl": "https://www.hostinger.com/connector",
+  "icons": [
+    {
+      "src": "https://raw.githubusercontent.com/hostinger/api-mcp-server/main/logo.svg",
+      "mimeType": "image/svg+xml",
+      "sizes": [
+        "any"
+      ]
+    }
+  ],
   "repository": {
     "url": "https://github.com/hostinger/api-mcp-server",
     "source": "github"
   },
-  "version": "3.28.4",
+  "version": "3.28.6",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "3.28.4",
+      "version": "3.28.6",
       "transport": {
         "type": "stdio"
       },

package/skills/headless/VERSION

@@ -1,3 +1,3 @@
-version=3.28.4
-commit=01ad176fa140
-built=2026-11-04
+version=3.28.6
+commit=3ecd304d96fb
+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/wait.mjs

@@ -14,6 +14,7 @@
 // operation to poll by hand instead).
 
 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';
@@ -55,7 +56,7 @@ function duration(text) {
 // One MCP server for the whole wait, spoken to over newline-delimited JSON-RPC on stdio. Once the
 // server dies every pending and later call rejects, so the wait ends with exit 2 rather than hanging.
 function connect() {
-  const child = spawn(MCP[0], MCP.slice(1), { stdio: ['pipe', 'pipe', 'pipe'], shell: spawnShell });
+  const child = spawn(MCP[0], MCP.slice(1), { stdio: ['pipe', 'pipe', 'pipe'], shell: spawnShell, cwd: homedir() });
   const pending = new Map();
   let buffer = '';
   let diag = '';