hostinger-api-mcp 3.28.0 → 3.28.2

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.28.2 — 2026-11-04
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/VERSION`, `skills/headless/steps/08-deploy/SKILL.md`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
+## v3.28.1 — 2026-11-04
+
+### Also in this release
+
+- Bundled agent skills: 11 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.28.0 — 2026-11-04
 
 ### Also in this release

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.28.0",
+  "version": "3.28.2",
   "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.0",
+  "version": "3.28.2",
   "mcpName": "io.github.hostinger/hostinger-api-mcp",
   "description": "MCP server for Hostinger API",
   "repository": {

package/server.json

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

package/skills/headless/VERSION

@@ -1,3 +1,3 @@
-version=3.28.0
-commit=0b30a7c65edb
+version=3.28.2
+commit=96c74d42d44e
 built=2026-11-04

package/skills/headless/connect/SKILL.md

@@ -72,10 +72,58 @@ npx --yes --package=@hostinger/mcp@latest hostinger-api-mcp --login
 npx --yes --package=@hostinger/mcp@latest hostinger-api-mcp --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 in stdio mode; `--http` needs `HOSTINGER_API_TOKEN`.
+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`.
 
 ## Phase 2 - Route to the specific tool instructions
 
+**Use the Hostinger connector only through your tool's native MCP tools** (`mcp__hostinger__*`,
+`mcp__hostinger-*__*`, or however your tool names them). Never spawn the MCP server yourself and
+never write a JSON-RPC client to talk to it: every connector call must be a visible MCP tool call
+the user can follow and approve, not a script.
+
+### Check both tool groups, not just "some Hostinger tools"
+
+The build needs **two** groups of connector operations, and they come from different servers. Having
+one group says nothing about the other:
+
+| Group | Operations | Comes from | Needed by |
+|---|---|---|---|
+| **Hosting** | `hosting_*` (websites, deploy, build report), `wordpress_*` | `hostinger` (`npx -y @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 --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) |
+
+Check each group on its own, right here at connect, before anything else:
+
+- **Hosting:** a Hostinger search tool finds `hosting_websites_list` (e.g. search "list websites").
+- **Ecommerce:** a tool from the `hostinger-ecommerce` server is in the session (Claude Code:
+  `mcp__hostinger-ecommerce__*`), and its search finds `ecommerce_stores_list` (e.g. search "list stores").
+
+Only when **both** pass are the Hostinger tools "in this session". If either is missing, the tools
+are **not** in this session: follow *register, restart, resume* below for the missing server(s) now,
+even though other Hostinger tools respond. Don't wait for refine to choose a backend: the restart
+costs the least before the user has been asked anything, and finding the gap at provision forces a
+second restart in the middle of the build.
+
+### When the Hostinger tools aren't in this session: register, restart, resume
+
+Most coding tools load MCP servers only when they start, so a server registered mid-run isn't usable
+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 @hostinger/mcp@latest`) if the hosting group is missing, and `hostinger-ecommerce`
+   (`npx --package=@hostinger/mcp@latest 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. **Pull the skills and write `connect.json`** (the route's skills step and Phase 3) before you stop,
+   so the next run starts from them.
+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
+   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
+   domain's workspace.
+
+If a tool loads new servers without a restart (VS Code), use them right away and skip steps 3–4.
+
 | Tool        | Route                           |
 |-------------|---------------------------------|
 | Claude Code | `connect/tools/claude-code.md`  |
@@ -85,8 +133,8 @@ Credentials live in `~/.config/hostinger-mcp/credentials.json` (macOS/Linux) or
 | Antigravity | `connect/tools/antigravity.md`  |
 | Devin       | `connect/tools/devin.md`        |
 
-If the user's tool isn't listed yet, connect it the generic way (register the Hostinger MCP server
-for that tool, or drive `npx --yes --package=@hostinger/mcp@latest hostinger-api-mcp` over stdio) and continue.
+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*.
 
 ### Always pull the latest skills (never run a stale copy)
 

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

@@ -8,25 +8,18 @@ description: "Specific Antigravity Hostinger MCP Server connection instructions
 - Make Hostinger MCP tools and Skills available in Google Antigravity.
 - Don't provision hosting, create stores, install WordPress, or deploy by hand here — the skill does all of that. This entry stops at signed in and checking that Hostinger MCP and skills are reachable.
 
-## Step 1 — Make the connector callable (no restart needed)
-
-The later stages drive the Hostinger connector. If its Hostinger tools already respond in this
-session, use them and move on.
-
-If they don't, **don't rely on registering the server and restarting** — Antigravity loads MCP servers
-when the editor starts, and you can't restart it mid-run. The Hostinger MCP runs as a local **stdio**
-process and the bootstrap already signed you in, so talk to it directly for this run: spawn
-`npx -y @hostinger/mcp@latest` and speak newline-delimited JSON-RPC 2.0 over its stdin/stdout
-(`initialize` → `notifications/initialized` → `tools/call`). It reuses your cached sign-in automatically
-(`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) — no tokens to handle. It
-exposes `search`, `execute`, `multi-execute`; everything the stages need goes through `execute`, and a
-result is in `reply.result.content[0].text`. Write the little client yourself (~20 lines), keep one
-process alive for the whole run, and use it wherever a stage calls the connector.
-
-**To persist it for future Antigravity sessions** (optional), add the server to
-`~/.gemini/antigravity/mcp_config.json` (Windows: `C:\Users\<USERNAME>\.gemini\antigravity\mcp_config.json`) —
-reachable from the Agent panel's "..." → MCP Servers → Manage MCP Servers → View raw config — then fully
-quit and reopen Antigravity once so it loads:
+## Step 1 — Make the MCP tools available
+
+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.
+
+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
+"..." → MCP Servers → Manage MCP Servers → View raw config. Merge them into any existing
+`mcpServers` rather than replacing the file. 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:
 
 ```json
 {
@@ -34,11 +27,20 @@ quit and reopen Antigravity once so it loads:
     "hostinger": {
       "command": "npx",
       "args": ["-y", "@hostinger/mcp@latest"]
+    },
+    "hostinger-ecommerce": {
+      "command": "npx",
+      "args": ["--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
     }
   }
 }
 ```
 
+Antigravity loads MCP servers only when the editor starts, so follow *register, restart, resume* in
+`connect/SKILL.md`: finish Step 2 and `connect.json`, then ask the user to fully quit and reopen
+Antigravity and paste the same prompt. Never spawn the server yourself or write a JSON-RPC client to
+reach it.
+
 ## Step 2 — Install the skills and hand off
 
 Download the Hostinger skills locally **at the start of every run** so your agent then reads the files

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

@@ -9,20 +9,30 @@ description: "Specific Claude Code Hostinger MCP Server connection instructions
 - Don't provision hosting, create stores, install WordPress, or deploy by hand here — the skill does all of that. This entry stops at signed in and checking that Hostinger MCP and skills are available.
 
 
-## Step 1 — Make the MCP callable (no restart needed)
-
-Stages 2–10 drive the Hostinger connector. If its tools are already in this session
-(`mcp__hostinger__*`, or the scoped `mcp__hostinger-*__*`), use them and move on.
-
-If they aren't, **don't register the server and restart** — Claude Code only loads MCP servers at
-startup, but you don't need it to. The Hostinger MCP runs as a local **stdio** process and the
-bootstrap already signed you in, so talk to it directly: spawn `npx -y @hostinger/mcp@latest` and
-speak newline-delimited JSON-RPC 2.0 over its stdin/stdout (`initialize` →
-`notifications/initialized` → `tools/call`). It reuses your cached sign-in automatically
-(`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) — no tokens to handle. It
-exposes `search`, `execute`, `multi-execute`; everything the stages need goes through `execute`, and
-a result is in `reply.result.content[0].text`. Write the little client yourself (~20 lines), keep one
-process alive for the whole run, and use it wherever a stage calls the connector.
+## Step 1 — Make the MCP tools available
+
+Stages 2–10 drive the Hostinger connector through Claude Code's native MCP tools. Check **both** tool
+groups as *Check both tool groups* in `connect/SKILL.md` says:
+
+- **Hosting:** `mcp__hostinger__*`, or the scoped `mcp__hostinger-hosting__*`.
+- **Ecommerce:** `mcp__hostinger-ecommerce__*`. The scoped servers (`hostinger-hosting`,
+  `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
+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 @hostinger/mcp@latest                                     # hosting group missing
+claude mcp add hostinger-ecommerce --scope user -- npx --package=@hostinger/mcp@latest hostinger-ecommerce-mcp  # ecommerce group missing
+```
+
+Claude Code loads MCP servers only at startup, so follow *register, restart, resume* in
+`connect/SKILL.md`: finish Step 2 and `connect.json`, then ask the user to exit Claude Code, start it
+again in the same folder (`claude`, or `claude --continue` to keep this conversation) and paste the
+same prompt. Never spawn the server yourself or write a JSON-RPC client to reach it.
 
 ## Step 2 — Install the skills and hand off
 

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

@@ -8,31 +8,37 @@ description: "Specific Codex Hostinger MCP Server connection instructions for th
 - Make Hostinger MCP tools and Skills available in Codex.
 - Don't provision hosting, create stores, install WordPress, or deploy by hand here — the skill does all of that. This entry stops at signed in and checking that Hostinger MCP and skills are reachable.
 
-## Step 1 — Make the connector callable (no restart needed)
+## Step 1 — Make the MCP tools available
 
-The later stages drive the Hostinger connector. If its Hostinger tools already respond in this
-session, use them and move on.
+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.
 
-If they don't, **don't rely on registering the server and restarting** — Codex loads MCP servers when
-it starts, and you can't restart it mid-run. The Hostinger MCP runs as a local **stdio** process and the
-bootstrap already signed you in, so talk to it directly for this run: spawn `npx -y @hostinger/mcp@latest`
-and speak newline-delimited JSON-RPC 2.0 over its stdin/stdout (`initialize` →
-`notifications/initialized` → `tools/call`). It reuses your cached sign-in automatically
-(`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) — no tokens to handle. It
-exposes `search`, `execute`, `multi-execute`; everything the stages need goes through `execute`, and a
-result is in `reply.result.content[0].text`. Write the little client yourself (~20 lines), keep one
-process alive for the whole run, and use it wherever a stage calls the connector.
+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:
 
-**To persist it for future Codex sessions** (optional), register the server with
-`codex mcp add hostinger -- npx -y @hostinger/mcp@latest`, or add it to `~/.codex/config.toml`, then
-restart Codex so it loads:
+```bash
+codex mcp add hostinger -- npx -y @hostinger/mcp@latest
+codex mcp add hostinger-ecommerce -- npx --package=@hostinger/mcp@latest hostinger-ecommerce-mcp
+```
+
+or add them to `~/.codex/config.toml`:
 
 ```toml
 [mcp_servers.hostinger]
 command = "npx"
 args = ["-y", "@hostinger/mcp@latest"]
+
+[mcp_servers.hostinger-ecommerce]
+command = "npx"
+args = ["--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
 ```
 
+Codex loads MCP servers only when it starts, so follow *register, restart, resume* in
+`connect/SKILL.md`: finish Step 2 and `connect.json`, then ask the user to restart Codex and paste the
+same prompt. Never spawn the server yourself or write a JSON-RPC client to reach it.
+
 ## Step 2 — Install the skills and hand off
 
 Download the Hostinger skills locally **at the start of every run** so your agent then reads the files

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

@@ -32,9 +32,17 @@ npm install -g @hostinger/mcp
 hostinger-api-mcp --version
 ```
 
-### Persist for future Cursor sessions (optional)
+### Register the servers in Cursor
 
-Register the server in `.cursor/mcp.json` (project) or `~/.cursor/mcp.json` (global), then fully quit and reopen Cursor once so it loads. **Do not** put `HOSTINGER_API_TOKEN` in this file when you want OAuth — leave the token unset so stdio OAuth can run:
+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.
+
+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.
+**Do not** put `HOSTINGER_API_TOKEN` in this file when you want OAuth: leave the token unset so
+OAuth can run:
 
 ```json
 {
@@ -42,12 +50,20 @@ Register the server in `.cursor/mcp.json` (project) or `~/.cursor/mcp.json` (glo
     "hostinger": {
       "command": "npx",
       "args": ["--yes", "--package=@hostinger/mcp@latest", "hostinger-api-mcp"]
+    },
+    "hostinger-ecommerce": {
+      "command": "npx",
+      "args": ["--yes", "--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
     }
   }
 }
 ```
 
-If Hostinger MCP tools are already in this session (`mcp__hostinger__*` / `mcp__hostinger-*__*`), skip ahead to Step 2 only if you still need sign-in; otherwise go to Step 3.
+Cursor loads MCP servers only when the editor starts, so after Step 2 and Step 3 follow
+*register, restart, resume* in `connect/SKILL.md`: ask the user to fully quit and reopen Cursor
+(and, if Cursor asks, enable the two Hostinger servers under Settings → MCP), then paste the same
+prompt. Never spawn the server yourself or write a JSON-RPC client to reach it: every connector call
+must be a native MCP tool call.
 
 ## Step 2 — Authenticate with OAuth (browser opens)
 
@@ -84,17 +100,7 @@ npx --yes --package=@hostinger/mcp@latest hostinger-api-mcp --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.
 
-## Step 3 — Use the connector in this run (no Cursor restart)
-
-Cursor only loads registered MCP servers when the editor starts, so a mid-run `.cursor/mcp.json` change will not attach tools to **this** session. For the rest of this run, talk to the local stdio server directly: spawn
-
-```bash
-npx --yes --package=@hostinger/mcp@latest hostinger-api-mcp
-```
-
-and speak newline-delimited JSON-RPC 2.0 over its stdin/stdout (`initialize` → `notifications/initialized` → `tools/call`). It reuses the cached sign-in from Step 2 (or `HOSTINGER_API_TOKEN`) — no tokens to handle in chat. It exposes `search`, `execute`, and `multi-execute`; everything the stages need goes through `execute`, and a result is in `reply.result.content[0].text`. Keep one process alive for the whole run.
-
-## Step 4 — Install the skills and hand off
+## Step 3 — Install the skills and hand off
 
 Download the Hostinger skills locally **at the start of every run** so your agent then reads the files
 directly with no further network calls during the run. **Always pull the latest and overwrite any

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

@@ -8,32 +8,37 @@ description: "Specific Devin Hostinger MCP Server connection instructions for th
 - Make Hostinger MCP tools and Skills available in Devin.
 - Don't provision hosting, create stores, install WordPress, or deploy by hand here — the skill does all of that. This entry stops at signed in and checking that Hostinger MCP and skills are reachable.
 
-## Step 1 — Make the connector callable
+## Step 1 — Make the MCP tools available
 
-The later stages drive the Hostinger connector. If its Hostinger tools already respond in this
-session, use them and move on.
+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.
 
-If they don't, register the Hostinger MCP server for Devin. The local MCP runs as a **stdio** process
-and the bootstrap already signed you in, so it reuses your cached sign-in automatically
-(`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) — no tokens to handle.
+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
+tokens to handle.
 
-- **Devin CLI:** `devin mcp add hostinger -- npx -y @hostinger/mcp@latest`
-- **Devin app:** Settings → MCP Marketplace → **Add Your Own**, transport **STDIO**, with:
+- **Devin CLI:**
+
+  ```bash
+  devin mcp add hostinger -- npx -y @hostinger/mcp@latest
+  devin mcp add hostinger-ecommerce -- npx --package=@hostinger/mcp@latest hostinger-ecommerce-mcp
+  ```
+
+- **Devin app:** Settings → MCP Marketplace → **Add Your Own**, transport **STDIO**, once per server:
 
   ```json
-  {
-    "command": "npx",
-    "args": ["-y", "@hostinger/mcp@latest"]
-  }
+  { "command": "npx", "args": ["-y", "@hostinger/mcp@latest"] }
   ```
 
-On Devin Desktop, fully quit and reopen the app once after adding the server so it loads.
+  ```json
+  { "command": "npx", "args": ["--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"] }
+  ```
 
-If you can't reach the registered server from this run, drive `npx -y @hostinger/mcp@latest` directly
-over stdio instead: spawn it and speak newline-delimited JSON-RPC 2.0 over its stdin/stdout
-(`initialize` → `notifications/initialized` → `tools/call`). It exposes `search`, `execute`,
-`multi-execute`; everything the stages need goes through `execute`, and a result is in
-`reply.result.content[0].text`.
+If the tools still aren't in this session, follow *register, restart, resume* in `connect/SKILL.md`:
+finish Step 2 and `connect.json`, then ask the user to restart the Devin session (on Devin Desktop,
+fully quit and reopen the app) and paste the same prompt. Never spawn the server yourself or write a
+JSON-RPC client to reach it.
 
 ## Step 2 — Install the skills and hand off
 

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

@@ -8,15 +8,16 @@ description: "Specific VS Code Hostinger MCP Server connection instructions for
 - Make Hostinger MCP tools and Skills available in VS Code (GitHub Copilot / agent mode).
 - Don't provision hosting, create stores, install WordPress, or deploy by hand here — the skill does all of that. This entry stops at signed in and checking that Hostinger MCP and skills are reachable.
 
-## Step 1 — Make the connector callable
+## Step 1 — Make the MCP tools available
 
-The later stages drive the Hostinger connector. If its Hostinger tools already respond in this
-session, use them and move on.
+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.
 
-If they don't, register the Hostinger MCP server for VS Code. The local MCP runs as a **stdio**
-process and the bootstrap already signed you in, so it reuses your cached sign-in automatically
-(`~/.config/hostinger-mcp/credentials.json`, or `HOSTINGER_API_TOKEN`) — no tokens to handle. Add it to
-`.vscode/mcp.json` (workspace) or your user `settings.json` under `mcp`:
+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
+no tokens to handle. Add them to `.vscode/mcp.json` (workspace) or your user `settings.json` under
+`mcp`:
 
 ```json
 // .vscode/mcp.json
@@ -26,21 +27,30 @@ process and the bootstrap already signed you in, so it reuses your cached sign-i
       "type": "stdio",
       "command": "npx",
       "args": ["-y", "@hostinger/mcp@latest"]
+    },
+    "hostinger-ecommerce": {
+      "type": "stdio",
+      "command": "npx",
+      "args": ["--package=@hostinger/mcp@latest", "hostinger-ecommerce-mcp"]
     }
   }
 }
 ```
 
-Or add it in one command: `code --add-mcp '{"name":"hostinger","command":"npx","args":["-y","@hostinger/mcp@latest"]}'`.
-VS Code picks up the server and its tools become available immediately — no editor restart needed.
+Or add them in two commands:
+
+```bash
+code --add-mcp '{"name":"hostinger","command":"npx","args":["-y","@hostinger/mcp@latest"]}'
+code --add-mcp '{"name":"hostinger-ecommerce","command":"npx","args":["--package=@hostinger/mcp@latest","hostinger-ecommerce-mcp"]}'
+```
+
+VS Code picks up new servers and their tools become available right away, with no editor restart.
 (Alternatively, the official Hostinger Connector extension installs the same server:
 `code --install-extension hostinger-official.hostinger-connector`.)
 
-If you can't reach the registered server from this run, drive `npx -y @hostinger/mcp@latest` directly
-over stdio instead: spawn it and speak newline-delimited JSON-RPC 2.0 over its stdin/stdout
-(`initialize` → `notifications/initialized` → `tools/call`). It exposes `search`, `execute`,
-`multi-execute`; everything the stages need goes through `execute`, and a result is in
-`reply.result.content[0].text`.
+If the tools still don't show up, follow *register, restart, resume* in `connect/SKILL.md`: finish
+Step 2 and `connect.json`, then ask the user to run **Developer: Reload Window** and paste the same
+prompt. Never spawn the server yourself or write a JSON-RPC client to reach it.
 
 ## Step 2 — Install the skills and hand off
 

package/skills/headless/steps/03-provision/ecommerce/SKILL.md

@@ -17,26 +17,19 @@ Provision a **Hostinger Ecommerce** backend for `<domain>` and prove it is ready
 
 > ## ⚠️ Prerequisite: the `hostinger-ecommerce` MCP server must be connected
 > Store management is **not** in the `hosting`/`wordpress` MCP groups — it's the separate
-> **`hostinger-ecommerce`** group (`ecommerce_*` ops, OAuth-backed, no API token needed). If those
-> tools aren't available, add the server and **reconnect the session** before continuing:
+> **`hostinger-ecommerce`** group (`ecommerce_*` ops, OAuth-backed, no API token needed). Connect
+> registers it alongside `hostinger`, so its tools are normally already in the session. If they
+> aren't (for example, a tool connected before connect registered both servers), register it now. The
+> command for each tool is in its `connect/tools/<tool>.md`; for Claude Code:
 > ```bash
-> claude mcp add-json hostinger-ecommerce '{"command":"npx","args":["--package=@hostinger/mcp@latest","hostinger-ecommerce-mcp"],"env":{"USER_AGENT":"extension;claude-code;via-cursor;1.4.2"}}' --scope user
+> claude mcp add hostinger-ecommerce --scope user -- npx --package=@hostinger/mcp@latest hostinger-ecommerce-mcp
 > ```
-> (For other tools, enable the **Ecommerce** MCP in the Hostinger Connector.) A newly added MCP server
-> only loads on a session restart/reconnect.
+> (Or enable the **Ecommerce** MCP in the Hostinger Connector.) A newly added MCP server only loads
+> after a restart, so pause the run with *register, restart, resume* from `connect/SKILL.md`: save
+> state, ask the user to restart the tool and paste the same prompt, and end your turn. Check-state then
+> resumes at provision. Never spawn the server yourself or write a JSON-RPC client to reach it.
 >
-> **Can't restart your own session? Don't block — drive the server directly.** A coding agent usually
-> can't reconnect itself, so instead of stopping, run the stdio server yourself and speak MCP to it:
-> spawn `npx --package=@hostinger/mcp@latest hostinger-ecommerce-mcp` (same `USER_AGENT` as above) and
-> send newline-delimited JSON-RPC over its stdin/stdout — `initialize` → the `notifications/initialized`
-> notification → `tools/list` → `tools/call`, where the tools are `search` / `execute` / `multi-execute`
-> (call ops exactly as in-session: `{ "name": "execute", "arguments": { "operation": "…", "params": {…} } }`).
-> It self-authenticates with the same stored Hostinger OAuth creds as the other connected servers, so
-> there is **no token to handle** (keep any secret off the command line). Your sandbox may ask the user
-> to approve spawning it — ask once, then proceed. Only fall back to asking the user to restart if
-> driving the server directly isn't permitted.
->
-> Verify the tools work (in-session or via the direct drive) with a search — e.g. "list stores" →
+> Verify the tools work in-session with a search — e.g. "list stores" →
 > `ecommerce_stores_list` — before proceeding.
 > The authoritative, always-current build guide is `ecommerce_miscellaneous_custom-storefront-setup-instructions` — read it once per build.
 

package/skills/headless/steps/04-content-model/ecommerce/SKILL.md

@@ -12,9 +12,9 @@ OAuth). Prices are **integers in minor units** (cents) and live on **variants**.
 **In:** `content-model.md` (prepared catalog), `site.json` (`ecommerce.store_id`). **Out:** products +
 images created in the store; ids recorded back into `content-model.md`.
 
-> If the `hostinger-ecommerce` MCP tools aren't available, don't stop — see the prerequisite in
-> `../../03-provision/ecommerce/SKILL.md` (add the server, and if you can't reconnect your session,
-> drive the stdio server directly rather than blocking).
+> If the `hostinger-ecommerce` MCP tools aren't available, follow the prerequisite in
+> `../../03-provision/ecommerce/SKILL.md`: register the server, then pause with *register, restart,
+> resume* from `connect/SKILL.md`. Never drive the server yourself over stdio.
 
 ## Step 1 — Create products (idempotent)
 

package/skills/headless/steps/08-deploy/SKILL.md

@@ -97,23 +97,45 @@ Zip the project **source** with `package.json` at the archive root. **Include**
 `package.json`, `package-lock.json`, `.nvmrc`. **Exclude** `node_modules/`, the build output
 (`.next/`, `dist/`, `out/`), `.git/`, and any `.htaccess` — the server installs and builds from source.
 
+> ## ⚠️ Write the archive outside `~/.hostinger/` (the deploy refuses it there)
+> `hosting_deploy` refuses any `path` under a hidden folder at the top of the home directory
+> (`~/.hostinger`, `~/.config`, …) with *"it is, or contains, a home, system or credentials location"*:
+> a deploy publishes what it reads, so the connector protects dotfolders that can hold tokens. That
+> covers both `~/.hostinger/<domain>/app.zip` **and** the `~/.hostinger/<domain>/src/` directory
+> itself, so neither can be passed as `path`. Keep the source in the workspace as usual, but write the
+> archive to a fresh temp directory and pass that. Don't copy the archive somewhere else after a
+> refusal, and don't move `src/` out of the workspace.
+
 ```bash
+# macOS/Linux — the OS temp dir is outside the home directory
 cd ~/.hostinger/<domain>/src
-zip -r -X ../app.zip . -x 'node_modules/*' '.next/*' 'dist/*' 'out/*' '.git/*' '**/.htaccess'
+DEPLOY_DIR=$(mktemp -d)
+zip -r -X "$DEPLOY_DIR/app.zip" . -x 'node_modules/*' '.next/*' 'dist/*' 'out/*' '.git/*' '**/.htaccess'
+echo "$DEPLOY_DIR/app.zip"   # the absolute path to pass as `path` in Step 3
+```
+
+```powershell
+# Windows PowerShell — %TEMP% sits under AppData, which the deploy also refuses; use a plain folder in your
+# profile, which only you can write to (never a folder under C:\, which every local account can write into)
+cd $HOME\.hostinger\<domain>\src
+$DeployDir = Join-Path $HOME "hostinger-deploy\<domain>"; New-Item -ItemType Directory -Force $DeployDir | Out-Null
+tar -a -cf "$DeployDir\app.zip" --exclude=node_modules --exclude=.next --exclude=dist --exclude=out --exclude=.git --exclude=.htaccess .
+"$DeployDir\app.zip"        # the absolute path to pass as `path` in Step 3
 ```
 
+Delete the temp directory once the build in Step 4 is `completed`.
+
 ## Step 3 — Deploy (one shot: settings + upload + build)
 
 Pass the framework's build settings **inline** on the deploy call — there is no separate settings step.
-`path` is the archive from Step 2 (or the source directory itself; `hosting_deploy` archives a directory
-for you, skipping `node_modules/`, `.git/` and `.env`, but it does **not** read `.gitignore`, so the
-build output must already be absent).
+`path` is the absolute path of the archive from Step 2, in its temp directory. Never pass a path under
+`~/.hostinger/`, the `src/` directory included: the deploy refuses it (see Step 2).
 
 ```json
 { "operation": "hosting_deploy",
   "params": {
     "domain": "<domain>",
-    "path": "/absolute/path/to/.hostinger/<domain>/app.zip",
+    "path": "<absolute path printed in Step 2, e.g. /var/folders/…/tmp.XXXX/app.zip>",
     "type": "nodejs",
     "appType": "<framework appType, e.g. next>",
     "outputDirectory": "<framework output dir, e.g. .next>",
@@ -224,6 +246,6 @@ still deploys as `type: "nodejs"` with its `appType` — the framework's static
 that way, and `/cms` is preserved. If a flow ever tells you to deploy a headless site as `type:
 "static"`, you are on a stale/legacy skill copy — stop and re-pull the latest skills.
 
-`hosting_deploy` on the local server is the only path: give its `path` either the source **directory** (it archives it for
-you) or a local **archive** (`zip`, `tar`, `tar.gz`, `tgz`, `7z`) — there is no separate upload or build
-step to fall back to.
+`hosting_deploy` on the local server is the only path: give its `path` a local **archive** (`zip`, `tar`,
+`tar.gz`, `tgz`, `7z`) written outside `~/.hostinger/` as in Step 2. There is no separate upload or
+build step to fall back to.