hostinger-api-mcp 3.27.4 → 3.28.1

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.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
+
+- Dependencies: `package-lock.json`
+- Bundled agent skills: 14 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.27.4 — 2026-11-03
 
 ### Also in this release

package/gemini-extension.json

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

package/skills/headless/SKILL.md

@@ -58,7 +58,7 @@ The order is sequencial run and check the whole headless flow:
 | — | **connect** — connect the Hostinger connector, auth, get active plan                                               | `connect/SKILL.md` → `connect/tools/<tool>.md` | `connect.json` | no |
 | 1 | **check state** — where does this domain stand? resume / switch / start over                                       | `steps/01-check-state/SKILL.md`                                       | `state.json` | no |
 | 2 | **refine** — discover what the user wants, in conversation                                                         | `steps/02-refine/SKILL.md`                                            | `brief.md` | no |
-| 3 | **provision** — choose the backend from the brief, then provision it                                               | `steps/03-provision/<backend>/SKILL.md`                               | `site.json` | **bg** — fire, then poll in the background |
+| 3 | **provision** — choose the backend from the brief, then provision it                                               | `steps/03-provision/<backend>/SKILL.md`                               | `site.json` | **bg** — fire, then wait at the join |
 | 4 | **content model** — define + create content/images, then push to the backend                                       | `steps/04-content-model/<backend>/SKILL.md`                           | `content-model.md` | prepare: no · **push: yes** |
 | 5 | **design** — derive design directions from the brief, pick one, write the `design.md` contract + logo              | `steps/05-design/SKILL.md`                                            | `design.md`, `brand/` | no |
 | 6 | **frontend** — pick/confirm the framework (default Next.js SSR), implement `design.md` against the backend         | `steps/06-frontend/SKILL.md`                                          | source in `<workspace>/src/` | shell: no · **data: yes** |
@@ -89,7 +89,7 @@ the user rather than improvising the stage from its description.
 The **Instance?** column says whether a stage touches the live backend:
 `no` = pure prepare work that can run during the provision wait;
 `push`/`data`/`yes` = a commit phase that joins the instance barrier;
-`bg` = provision itself, the background task.
+`bg` = provision itself: Hostinger runs the job while you do the prepare work.
 
 **Always end with the final report.** Whenever a run ends, give the user the final report defined
 in `steps/09-done/SKILL.md`: an outcome paragraph, a *Steps completed* table (one row per stage that
@@ -99,8 +99,8 @@ missing step, a failed provision, or a user pause. Every run also saves a **buil
 Waiting for the user's answer to a question is not a run ending: end your turn with the question
 alone, with no final report and no build report.
 
-**Log the run as you go.** Wrap every stage (and each phase of a split stage) in
-`run-log.mjs stage-start` / `stage-end`, and log an event the moment something goes wrong, the user
+**Log the run as you go.** Wrap every stage (and each phase of a split stage) in the run log —
+`run-log.mjs next <stage>` at each boundary — and log an event the moment something goes wrong, the user
 corrects you, or a skill is missing or wrong — before you continue. See *Run log and build report*.
 
 **Why this order.** connect first, so account/plan failures surface before the user spends time
@@ -178,17 +178,37 @@ which of these cases applies and records it, then provision takes the matching p
 3. **User wants a webapp.** Provision is a plain Node.js app host, not headless — `webapp` ignores
    headless shells entirely and is only reached by experimental actions, never the onboarding flow.
 
-Either way the create/install is asynchronous and returns `queued` immediately, then it's polled
-every ~15 s for a few minutes — **what you poll depends on the path**: a fresh
-`hosting_websites_create` is polled with `hosting_websites_list-setups` until `completed`, while a
-shell swap (`wordpress_installations_install`) creates no new setup, so it's polled with
-`wordpress_installations_list` until the `/cms` row is `is_valid`. Don't block on that poll. The
-single rule that makes the overlap safe:
+Either way the create/install is asynchronous and returns `queued` immediately, then it takes a few
+minutes — **what to wait on depends on the path**: a fresh `hosting_websites_create` is `wait.mjs setup`
+(until `hosting_websites_list-setups` says `completed`), while a shell swap
+(`wordpress_installations_install`) creates no new setup, so it's `wait.mjs cms` (until the `/cms` row of
+`wordpress_installations_list` is valid). Run it at the join, not at the fire: by then the prepare work
+has usually outlasted the job, so it returns at once. The single rule that makes the overlap safe:
 
-> **Fire provision as a background task, then do every stage's prepare work while it settles. The
+> **Fire provision (Hostinger runs it asynchronously), then do every stage's prepare work while it settles. The
 > moment a step must write to the live instance, it waits for provision to report ready (via the
 > backend step's readiness poll — see above). That wait is the *instance barrier*.**
 
+### 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:
+
+```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
+```
+
+Run it in the foreground, with a `--timeout` just under your tool's command limit (e.g. `--timeout 9m`
+when commands may run 10 minutes); on `timed_out`, run the same command again: it picks the job up
+where it is. It prints one JSON line and
+exits 0 with `ok: true` and what it waited for; 1 with `ok: false` when the job failed, timed out
+(`timed_out`, `last_status`) or hit an error that waiting won't fix (`error`); 2 when it couldn't start
+the local Hostinger MCP, with `fallback` naming the connector operation to poll yourself, every ~15 s.
+Never write your own `sleep` loops.
+
 ---
 
 ## State and artifacts
@@ -243,14 +263,15 @@ provision runs in the background, its status lives in its own `provision` field
 }
 ```
 
-- `provision` is **absent** until provision fires, `{"status":"in_progress", …}` while the
-  background poll runs, and `{"status":"completed", …}` once `hosting_websites_list-setups` confirms
-  it. `domain` is the poll target.
+- `provision` is **absent** until provision fires, `{"status":"in_progress", …}` from the fire until
+  the join's `wait.mjs` returns `ok: true`, then `{"status":"completed", …}`. `domain` is the wait's
+  target.
 - Any **instance-barrier** step (content-model push, frontend data, deploy) must read
-  `provision.status == "completed"` — and re-verify it against the connector — before it runs. A
-  prepare step ignores `provision` entirely.
-- On **resume**, `provision.status` is a hint only: re-poll `hosting_websites_list-setups` to learn
-  the truth, then update the field.
+  `provision.status == "completed"` before it runs. The connector is asked twice per run: at
+  check-state (or the provision join that sets `completed`), and in deploy's pre-flight, because deploy
+  overwrites the site. Steps in between trust `state.json`. A prepare step ignores `provision` entirely.
+- On **resume**, `provision.status` is a hint only: check-state re-polls `hosting_websites_list-setups`
+  to learn the truth, then updates the field.
 - Write `state.json` however is easiest, rewriting the whole file included: the run log lives in
   `run-log.json`, which only `run-log.mjs` writes.
 - The **onboarding slug** is how hPanel names the coding tool: `claude` for Claude Code, else
@@ -269,9 +290,10 @@ in. Write it out in full each time (a shell variable holding the command breaks
 ```bash
 node <skill>/run-log.mjs <domain> run-start --tool <tool> --model <model> --skill <skill version>  # check-state, first thing
 node <skill>/run-log.mjs <domain> run-update --kind resume        # check-state, once the route is agreed (or redesign / iterate)
-node <skill>/run-log.mjs <domain> stage-start frontend            # before a stage
-node <skill>/run-log.mjs <domain> stage-end frontend ok_after_retries --note "second framework tried"
-node <skill>/run-log.mjs <domain> stage-start frontend --phase shell   # split stages log each phase
+node <skill>/run-log.mjs <domain> next frontend                  # at a stage boundary: ends the open stage as ok, starts this one
+node <skill>/run-log.mjs <domain> next frontend --phase shell     # split stages log each phase
+node <skill>/run-log.mjs <domain> stage-end frontend ok_after_retries --note "second framework tried"   # any other result, or a note
+node <skill>/run-log.mjs <domain> stage-start frontend            # start without ending anything
 node <skill>/run-log.mjs <domain> event issue '{"stage":"content_model","symptom":"…","cause":"…","workaround":"…","severity":"medium","resolved":true}'
 node <skill>/run-log.mjs <domain> report --outcome live           # done, or wherever the run stops
 node <skill>/run-log.mjs <domain> report-sent <run>               # after the report was sent (see below)
@@ -280,6 +302,12 @@ node <skill>/run-log.mjs <domain> unsent                          # check-state:
 node <skill>/run-log.mjs <domain> run-resume --reason "about/contact layout fix"   # follow-up in the same session
 ```
 
+**Don't spend a turn on the log.** Put each run-log call in the same shell command as the work next
+to it, joined with `&&` (e.g. `node <skill>/run-log.mjs <domain> next deploy && cd … && zip …`), and use
+`next` at a boundary rather than a `stage-end` plus a `stage-start`. When the stage ending wasn't plain
+`ok` or needs a note, put its `stage-end` first in the same command. `next` refuses when two stages are
+open and names them; end them with `stage-end`.
+
 **Follow-ups continue the run.** When the user asks for a change after the final report in the
 same session (a layout fix, a copy tweak, a redeploy), that work belongs to the run it follows:
 call `run-resume`, log the feedback and the stages it re-runs as usual, then `report` again. That

package/skills/headless/VERSION

@@ -1,3 +1,3 @@
-version=3.27.4
-commit=10d66593f943
-built=2026-11-03
+version=3.28.1
+commit=4609383f23a0
+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