hostinger-api-mcp 3.10.1 → 3.10.2

package/CHANGELOG.md

@@ -4,6 +4,13 @@ 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.10.2 — 2026-10-26
+
+### Also in this release
+
+- Bundled agent skills: 5 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.10.1 — 2026-10-26
 
 ### Also in this release

package/gemini-extension.json

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

package/skills/headless/SKILL.md

@@ -102,6 +102,17 @@ user is offered the choice to continue, switch domains, or start over — before
 Refinement before provisioning, because the backend cannot be chosen until the brief exists.
 Validation before deploy, always — nothing reaches the live domain unseen.
 
+### When you ask the user
+
+A question tool's result is the user's answer only when it carries their choice or their words. When
+it comes back skipped, rejected, empty or as an error (a *skipped* result), nobody has answered yet:
+Cursor's `AskQuestion`, for one, returns "Questions skipped by the user" when no one touched it. Ask
+the same questions again as plain text in your reply, end your turn, and continue from what the user
+types. One plain-text re-ask is enough: it can't come back skipped. Fill a question you asked with a
+default only when the user says so in their own words ("you decide", "just build it", "skip that"),
+or when they said up front that no one will be there to answer; then list those defaults under gaps
+in the final report. Every step that asks the user something follows this.
+
 ### Background provision & the instance barrier
 
 **Provision always runs — what it does depends on what the domain already has.** Often onboarding on

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

@@ -187,7 +187,8 @@ connect-only files are *not* something to resume.
 - **Buy a domain** — they want a custom domain instead of the temporary one. Route to the domain
   purchase / `connect-domain` flow, then continue with the chosen domain.
 
-When the intent is ambiguous, **ask** — don't guess.
+When the intent is ambiguous, **ask** — don't guess. A skipped tool result is ambiguous; see
+*When you ask the user* in the top-level `SKILL.md`.
 
 ---
 

package/skills/headless/steps/02-refine/SKILL.md

@@ -10,8 +10,10 @@ Find out what the user wants to build, guess which backend fits, and write it do
 the site comes from talking to the user.
 
 **Keep it short.** The only thing you must know is *what they are building* — enough to guess the
-backend. Every other question is skippable: the more the user gives, the better the site, but never
-hold the build hostage to refinement. Fill gaps with sensible defaults and say so in the brief.
+backend. Every other question is optional: the more the user gives, the better the site, but never
+hold the build hostage to refinement. Fill gaps with sensible defaults and say so in the brief. A
+skipped question tool is not the user passing on a question; see *When you ask the user* in the
+top-level `SKILL.md`.
 
 > **Never ask the user to choose a backend or a technology.** Don't ask "WordPress or Ecommerce?",
 > don't present WordPress/Ecommerce/WooCommerce/Webapp as options, and don't surface the backend in a
@@ -34,8 +36,9 @@ Read everything already in `~/.hostinger/<domain>/` (`state.json`, `connect.json
 or files the user dropped there) — it all counts as input.
 
 If `brief.md` already exists for this domain, **don't overwrite it**. Show the user a three-line
-summary (what the site is, its pages, the suggested backend) and ask: *keep it, or change something?*
-Keep → go to Step 6. Change → edit only what they asked for, then re-confirm (Step 5).
+summary (what the site is, its pages, the suggested backend) and ask: *keep it, or change
+something?* Keep → go to Step 6. Change → edit only what they asked for, then re-confirm (Step 5). A
+skipped tool result is not Keep; see *When you ask the user* in the top-level `SKILL.md`.
 
 If the site is already provisioned (`site.json` exists), the backend is **fixed** — never change the
 Suggested backend on a provisioned site. Explain that switching backends means a new domain.
@@ -75,9 +78,11 @@ sentence is enough. Links, screenshots or files help too. Skip anything you don'
 Ask in **short rounds of 2–3 questions**, and adapt each round to the previous answers. If your tool
 has a structured question UI (multiple choice with an "other" field), use it for the choice-shaped
 follow-up questions (pages, selling yes/no, tone) — **never for the opening "what do you want to
-build?" and never for the backend** (that's your decision, not theirs). **At most 3 rounds**, and stop early as soon as you can guess the backend and the user
-seems done — "just build it", "you decide", or a skipped question means *use defaults*, not *ask
-again*.
+build?" and never for the backend** (that's your decision, not theirs). **At most 3 rounds**, and
+stop early as soon as you can guess the backend and the user seems done — "just build it" or "you
+decide" means *use defaults*, not *ask again*. A skipped tool result is not their answer: re-ask
+that round in plain text, as *When you ask the user* in the top-level `SKILL.md` says. The re-ask
+repeats the round; it doesn't count toward the 3.
 
 **Round 1 — what it is (the only required round):**
 
@@ -85,7 +90,7 @@ again*.
 2. **Will you sell anything on it?** Physical products, digital products, services with checkout —
    or nothing. *This decides the backend.* Skip it only when the answer is already unmistakable
    ("an online shop for my candles", "my personal blog"); when in doubt, ask.
-3. **Who is it for?** The audience, and how they'll find the site. *(skippable)*
+3. **Who is it for?** The audience, and how they'll find the site. *(optional)*
 
 **Round 2 — what goes on it (optional, adapt to Round 1):**
 
@@ -133,6 +138,9 @@ the default from what you found:
   — you design and code it." Today's flow: the design step proposes directions and the frontend step
   scaffolds and implements them.
 
+A skipped tool result is not a pick: re-ask in plain text, and use the seeded default only when the
+user says so (see *When you ask the user* in the top-level `SKILL.md`).
+
 Record the answer as the brief's **Build mode**. This is the one frontend/technology question you *do*
 put to the user; everything else about the stack (framework, SSR/SSG) is still inferred. The deliverable
 is the same either way — a working site on the backend; only *who drives the frontend* changes.
@@ -192,9 +200,10 @@ site, not the backend:
   WordPress admin"), **not** as a choice you're asking them to make. Don't ask "is WordPress OK?" or
   offer alternatives unless it was a genuine close call *and* the difference matters to the user.
 
-End with *"Good to go, or anything to change?"* A yes (or silence-equivalent like "go") → write
-`brief.md`. Changes → apply them and write it; don't loop back into questions. If the user
-*volunteers* a different backend, use theirs and note it in the brief.
+End with *"Good to go, or anything to change?"* A yes (or "go") → write `brief.md`. A skipped tool
+result is not a yes (see *When you ask the user* in the top-level `SKILL.md`). Changes → apply them
+and write it; don't loop back into questions. If the user *volunteers* a different backend, use
+theirs and note it in the brief.
 
 ## Step 6 — Write `brief.md` and hand off
 

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

@@ -90,7 +90,8 @@ Guidance:
 
 Every article (and every product) needs an image. There are two sources, and **you MUST offer the user
 both and let them choose — never pick silently.** State the default for this backend in one line, name
-the other option, and proceed on their answer (a skipped answer / "you decide" = use the default):
+the other option, and proceed on their answer ("you decide" = use the default; a skipped tool result is
+not an answer, see *When you ask the user* in the top-level `SKILL.md`):
 
 | Option | Tool | Backends | Needs the live instance? |
 |---|---|---|---|

package/skills/headless/steps/05-design/SKILL.md

@@ -76,7 +76,8 @@ Read `brief.md`, `state.json`, and `content-model.md` if it exists.
    the final report. Files or exact colours and fonts the owner supplied win over anything you read.
 2. **Confirm in one question.** Describe the kept look in two plain sentences and ask: *keep it, or
    change something?* "Keep the look we have" still gets this question; skip it only when the brief
-   says to change nothing at all ("keep it exactly as it is"). Change →
+   says to change nothing at all ("keep it exactly as it is"). A skipped tool result is not Keep; see
+   *When you ask the user* in the top-level `SKILL.md`. Change →
    apply only what they asked for; a request for a new logo runs Step 6 for the logo alone.
 3. **Check it** as in Step 5. The kept colours are fixed like brand colours: a pair that fails gets a
    shade of the same hue in that role only. Spacing moves to the nearest grid value, and a font
@@ -188,7 +189,9 @@ never suggest one or give an example: that idea would end up in the logo.
 Then:
 
 - **Pick** → use it as written, and confirm the look in one line.
-- **"You decide" / skipped** → use A, and tell them in one line which look you went with.
+- **"You decide"** → use A, and tell them in one line which look you went with.
+- **Skipped tool result** → not an answer: write the three directions as plain lines
+  and wait for the reply (see *When you ask the user* in the top-level `SKILL.md`).
 - **A mix** ("A's colours with C's fonts") → merge them. Don't ask again.
 - **Something else** → build a direction from what they said, run Step 5, and use it. Don't send
   three new options.