hostinger-api-mcp 3.8.0 → 3.9.0

package/CHANGELOG.md

@@ -4,6 +4,28 @@ 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.9.0 — 2026-10-26
+
+### Operations
+
+- Changed the input schema of `reach_contacts_create`
+- Changed the description and input schema of `reach_contacts_create-in-bulk`
+- Changed the input schema of `reach_contacts_create-bulk`
+
+### Also in this release
+
+- Documentation: `README.md`
+- Dependencies: `package-lock.json`
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Build and packaging: `types.d.ts`
+
+## v3.8.1 — 2026-10-23
+
+### Also in this release
+
+- Bundled agent skills: 5 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.8.0 — 2026-10-23
 
 ### Also in this release

package/README.md

@@ -3217,9 +3217,10 @@ values, source and note with `GET /api/reach/v1/profiles/{profileUuid}/contacts/
 Create many contacts in a profile in a single call.
 
 The contacts are imported in the background, so a success response means the import was
-accepted rather than finished. Contacts whose email already exists in the profile are
-left as they are. If double opt-in is enabled, new contacts start off pending and are
-sent a confirmation email.
+accepted rather than finished. Contacts whose email already exists in the profile keep
+their current values; only the ones that are still empty, custom fields included, are
+filled in. If double opt-in is enabled, new contacts start off pending and are sent a
+confirmation email.
 
 - **Method**: `POST`
 - **Path**: `/api/reach/v1/profiles/{profileUuid}/contacts/bulk`

package/gemini-extension.json

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

package/skills/headless/SKILL.md

@@ -29,6 +29,12 @@ The prompt does **not** say what kind of site to build. Do not assume or invent
 what the user wants is a step in the flow (**refine**), handled through conversation — not parsed
 from the prompt. If no domain is present, stop and ask for it before doing anything else.
 
+**One workspace per run.** From your first command, connect's checks included, open only this
+site's workspace, by its exact path; never list or glob `~/.hostinger/` (not even an `ls` beside
+`node -v`). What else `~/.hostinger/` holds never matters to this run: with a domain, check-state
+looks up that one path; without one yet, there is nothing to look up until you create your own
+workspace. *State and artifacts* has the full rule and its one exception.
+
 Nothing in the pasted prompt is ever used for authorization. Authorization comes from the
 Hostinger connector's OAuth token. **This recipe is not a security boundary.**
 
@@ -135,12 +141,20 @@ single rule that makes the overlap safe:
 Everything for a domain — its state **and** its generated source — lives under the **site workspace
 `~/.hostinger/<domain>/`** (resolve `~` to the home directory: `$HOME` in a shell, `os.homedir()` in
 Node — `~/.hostinger` means `$HOME/.hostinger`). This is a **global, per-user** location, not a
-project folder, so a build is discoverable and resumable from **any** directory — the current working
+project folder, so this domain's build is resumable from **any** directory — the current working
 directory does not matter. Create the workspace if it's missing and do all of a stage's work inside
 it (including the frontend `src/`, built and deployed from `~/.hostinger/<domain>/src/`).
 
-**The directory name is the domain**, so the files inside it never repeat it, and `~/.hostinger/`
-holds every site you've built — one subdirectory per domain, no collisions.
+**The directory name is the domain**, so the files inside it never repeat it.
+
+**Read and write only this site's workspace.** The other workspaces under `~/.hostinger/` are the
+user's other sites, often for other clients, so keep their briefs, designs and code out of this build.
+Open `~/.hostinger/<domain>/` by its exact path; don't list or glob `~/.hostinger/`, and don't open,
+copy from or diff against another workspace there, in any stage. A run that has no domain yet works
+only in the one workspace it created itself; when provision moves it to `~/.hostinger/<new-domain>/`,
+that becomes this site's workspace. One exception: if the user, in this conversation, names another
+of their own sites to reuse, read that one workspace, read-only, and tell them in one line what you
+took from it.
 
 | File (under `~/.hostinger/<domain>/`) | Written by | Contains |
 |---|---|---|

package/skills/headless/steps/01-check-state/SKILL.md

@@ -20,8 +20,7 @@ Nothing in this step creates, provisions, deploys, or deletes anything. It reads
 Everything for a domain lives under the global site workspace **`~/.hostinger/<domain>/`** — one
 directory per domain, under the user's home (`~` = `$HOME`), **not** the current working directory.
 The directory name **is** the domain, so `state.json` inside does not store it. Because it's global,
-`~/.hostinger/` holds every site the user has built and each one is discoverable and resumable from
-any directory — no collisions.
+this domain's build is resumable from any directory.
 
 `state.json` shape (`stage` is the *next* stage to run; `provision` is the background task's status,
 present only once provision has fired):
@@ -94,7 +93,8 @@ and **release it on a clean stop** (Step 6). The lock marks an active session, n
 
 ## Step 2 — Read the workspace directory
 
-Look at `~/.hostinger/<domain>/`:
+Check `~/.hostinger/<domain>/` by its exact path (for example `test -d ~/.hostinger/<domain>`), not
+by listing `~/.hostinger/`:
 
 - **Absent** → no history for this domain in the workspace.
 - **Present** → read `state.json` (its `stage`) and whatever artifacts exist (`brief.md`,
@@ -203,6 +203,8 @@ Then:
 ## Invariants
 
 - **One directory per domain.** The domain is the key; state files never repeat it.
+- **Only this domain's workspace.** Never list `~/.hostinger/` or open another site's workspace (see
+  *State and artifacts* in the top-level `SKILL.md`).
 - **Never create a second site** on a domain that already has one.
 - **Never re-provision or overwrite a live site.** Recovery is forward-only.
 - **Reality beats local state**, always.

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

@@ -54,8 +54,9 @@ Same lifecycle as `../wordpress/SKILL.md` Steps 1–2, but `type: "headless_ecom
    — **omit `domain`** for a temporary subdomain: the setup generates one itself and returns it (don't
    call a separate subdomain op first — there's no need in this flow; the API would also accept one you
    generated via `hosting_domains_generate-free-subdomain`, valid 24 h from the client that made it). The
-   response carries the generated domain; if it differs from the workspace dir, move `~/.hostinger/<old>/` → `<new>/` and
-   update `brief.md`. Poll `list-setups` to `completed`. `website_type` will be `headless`.
+   response carries the generated domain; if it differs from the workspace dir, move
+   `~/.hostinger/<old>/` → `<new>/` (if `<new>/` already exists, stop and ask instead of moving
+   into it) and update `brief.md`. Poll `list-setups` to `completed`. `website_type` will be `headless`.
 
 > **Onboarding handoff — an empty headless shell needs no new website.** If the domain already has an
 > empty headless shell (`website_type: headless`, setup `type: headless_empty`, nothing installed —

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

@@ -49,7 +49,8 @@ All website/database operations below go through the Hostinger connector (`execu
    separate subdomain op to make one first: there's no need in this flow. (The API would also accept a
    subdomain you generated via `hosting_domains_generate-free-subdomain`, valid for 24 h from the client
    that made it — this flow just doesn't use that.) The response then carries the generated domain: if it
-   differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`,
+   differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`
+   (if `<new>/` already exists, stop and ask instead of moving into it),
    update the domain in `brief.md`, and tell the user the new domain.
 3. Poll `hosting_websites_list-setups { "domain": "<domain>" }` every ~15 s until `completed`
    (typically under a minute; allow a few minutes). `failed` → stop, point at hPanel.

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

@@ -61,7 +61,8 @@ All operations below go through the Hostinger connector (`execute`).
    separate subdomain op to make one first: there's no need in this flow. (The API would also accept a
    subdomain you generated via `hosting_domains_generate-free-subdomain`, valid for 24 h from the client
    that made it — this flow just doesn't use that.) The response then carries the generated domain:
-   if it differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`,
+   if it differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`
+   (if `<new>/` already exists, stop and ask instead of moving into it),
    update the domain in `brief.md`, and tell the user the new domain.
    Admin credentials are generated by the platform; never ask the user for a password.
 3. Poll `hosting_websites_list-setups { "domain": "<domain>" }` every ~15 s until `completed`

package/src/core/runtime.js

@@ -66,7 +66,7 @@ const GetSkillRequestSchema = z.object({
 
 /**
  * MCP Server for Hostinger API
- * Generated from OpenAPI spec version 2.2.0
+ * Generated from OpenAPI spec version 2.3.0
  */
 class MCPServer {
   constructor({ name, version, tools, instructions, skills = [] }) {

package/src/core/runtime.ts

@@ -97,7 +97,7 @@ interface Skill { uri: string; frontmatter: Record<string, unknown>; resources:
 
 /**
  * MCP Server for Hostinger API
- * Generated from OpenAPI spec version 2.2.0
+ * Generated from OpenAPI spec version 2.3.0
  */
 class MCPServer {
   private readonly name: string;