hostinger-api-mcp 3.15.1 → 3.16.0

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.16.0 — 2026-10-27
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/steps/02-refine/SKILL.md`, `skills/headless/steps/05-design/SKILL.md`, `skills/headless/steps/06-frontend/SKILL.md`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
+## v3.15.2 — 2026-10-27
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/steps/04-content-model/SKILL.md`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.15.1 — 2026-10-27
 
 ### Also in this release

package/gemini-extension.json

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

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

@@ -150,10 +150,15 @@ app's look:
   existing project in the current folder as the source**, collaborates on design/code at the user's
   direction, and wires it to the provisioned backend. There is **no agent-generated design** — the
   design step defers to the user (see the Build mode box at the top of the design step), and the
-  frontend step builds on their project rather than scaffolding a new one. Write "Keep the look we
-  have: the app in this folder" in **Design direction**.
-- **Agent designs and builds it — a new design** — the design step proposes directions and the
-  frontend step scaffolds and implements them.
+  frontend step builds on their project rather than scaffolding a new one. Build mode is **Bring your
+  own frontend**; write "Keep the look we have: the app in this folder" in **Design direction**.
+- **Agent rebuilds it — keep my app's look** — the design step reads the look (colours, fonts, logo)
+  from their project, and the frontend step starts from the project's source, keeping its screens and
+  features, and rebuilds its UI to that look. Build mode is **Agent designs and builds**; write "Keep
+  the look we have: the app in this folder" in **Design direction**.
+- **Agent rebuilds it — a new design** — the design step proposes directions and the frontend step
+  rebuilds the app from them. Build mode is **Agent designs and builds**; take **Design direction**
+  from Round 3.
 
 A skipped tool result is not a pick: re-ask in plain text, and use the default only when the user
 says so (see *When you ask the user* in the top-level `SKILL.md`).
@@ -162,9 +167,10 @@ Otherwise don't ask: Build mode is **Agent designs and builds**. When the user s
 own code elsewhere, ask for its path, inspect it as in Step 2, and from then on treat it as a project
 found in the folder.
 
-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.
+Record the Build mode the chosen option names in the brief's **Build mode**, and its look in **Design
+direction**. 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.
 
 ## Step 4 — Decide the backend (your call, from the brief — not a question)
 
@@ -297,7 +303,8 @@ the app reads — names only, never values>
 ## Build mode
 **<Bring your own frontend | Agent designs and builds>** — <one line>. <When "Bring your own frontend":
 how they want to drive design/code; the project's path is under **Existing project**. When "Agent designs and builds": leave the design + frontend steps to run as
-normal.> The design step and the frontend step both read this: **Bring your own frontend** → design
+normal; with **Existing project** filled, the frontend starts from that app's source and rebuilds its UI
+to design.md.> The design step and the frontend step both read this: **Bring your own frontend** → design
 defers to the user and frontend builds on their project; **Agent designs and builds** → both run as normal.
 
 ## Rendering

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

@@ -96,7 +96,7 @@ not an answer, see *When you ask the user* in the top-level `SKILL.md`):
 | Option | Tool | Backends | Needs the live instance? |
 |---|---|---|---|
 | **A — Hostinger AI image generation** *(default for WordPress / WooCommerce)* | `wordpress_ai-content_generate-images` | WordPress, WordPress + WooCommerce | **yes** — runs at the instance barrier |
-| **B — Unsplash stock photos** *(default for Ecommerce / Webapp; the fallback everywhere)* | Unsplash API / web search | any | no — pure prepare work |
+| **B — Unsplash stock photos** *(default for Ecommerce / Webapp; the fallback everywhere)* | Unsplash API, or web search + web fetch | any | no — pure prepare work |
 
 > **Do not silently fall back to stock on a WordPress site.** On WordPress / WooCommerce the default is
 > **Hostinger AI (Option A)** — on-brand, generated from `design.md`. Using Unsplash on a WordPress build
@@ -105,8 +105,9 @@ not an answer, see *When you ask the user* in the top-level `SKILL.md`):
 > shortcut: the async start → poll → upload-before-expiry flow (Option A below) is the expected work, not
 > an optional extra. If you are tempted to skip it "for speed", stop and offer the user the choice instead.
 
-If you can generate images yourself (some agents can), that's a third path: put the files in `media/`
-and record alt text — no tool needed. **Record alt text for every image whichever source you use.**
+If you can generate images yourself (some agents can), offer that as a third option; only if the user
+picks it, put the files in `media/` (no tool needed). **Record alt text for every image whichever source
+you use.**
 
 **During the prepare wait, write an image brief for each image** into `content-model.md` no matter the
 option (subject, `image_type`, aspect, and the alt text you expect). Option B can also *fetch* the
@@ -171,14 +172,21 @@ and the push phase uploads them.
    - Without a key, use web search limited to `unsplash.com` (e.g. "unsplash photo Lisbon tram") and
      take the photo id from the result URL: the last segment of `unsplash.com/photos/<slug>-<id>`, or
      the whole segment for `unsplash.com/photos/<id>`.
-   - Don't call `unsplash.com/napi/…`. It sits behind a bot challenge and returns 401.
-2. **Resolve a direct file URL.** `GET https://unsplash.com/photos/<id>/download?force=true` (don't
-   follow the redirect) answers `302` with `Location: https://images.unsplash.com/photo-<…>?…`. The
-   `dl=` parameter in it also carries the photographer's name. Drop the query string and request a
-   web size: `https://images.unsplash.com/photo-<…>?w=1600&q=80&fm=jpg&fit=max`. The upload ability
-   needs this direct file URL, which returns 200 with `image/jpeg`. A photo *page* URL won't work.
-3. **Look before you keep it.** Download a small preview (`?w=500`) and view it. Search snippets
-   only show captions, and a photo often isn't quite what its title says. Reject anything off-topic.
+2. **Resolve a direct file URL.** With the API, the result's `urls.raw` is the file and `user.name`
+   the photographer; for each photo you keep, also `GET` its `links.download_location` (same header),
+   as the API terms require. Without a key, open the photo page (`https://unsplash.com/photos/<…>`)
+   with your **web-fetch tool** and ask it for the main photo's `images.unsplash.com/photo-<…>` URL,
+   quoted exactly, and the photographer's name. Either way, drop the query string and request a web
+   size: `https://images.unsplash.com/photo-<…>?w=1600&q=80&fm=jpg&fit=max`. Check that it returns
+   200 with `image/jpeg`: the upload ability needs this direct file URL, not the photo page.
+   - Every other `unsplash.com` request (curl on the page, `/photos/<id>/download`, `/napi/…`,
+     `/oembed`) hits a bot challenge: a `307` to `/.within.website` (Anubis) or a 401. If your fetch
+     tool gets the challenge page too, stop: no user-agent spoofing or other workarounds. On a
+     WordPress backend where Option A hasn't already failed, offer it; otherwise ask the user for an
+     `UNSPLASH_ACCESS_KEY` or record the gap (step 5).
+3. **Look before you keep it.** Download a small preview (`?w=500`) and view it. Search snippets and
+   fetch summaries only describe the page, and can hand you a related photo's thumbnail instead of
+   the main one; a photo also often isn't quite what its title says. Reject anything off-topic.
    If nothing fits exactly, take the closest real photo and note the gap rather than mislabel it.
 4. **Write alt text from what the photo shows**, not from the article's image brief. For example,
    use "Shopfronts and parked scooters on a Hanoi street" even if the article is about rain.
@@ -191,6 +199,9 @@ and the push phase uploads them.
    Image file: <site>-<subject>.jpg
    ```
 
+   If you can't get a real photo, write `Image gap: <reason>` in place of these lines and tell the
+   user. Never substitute drawn or generated images without saying so.
+
 Unsplash photos are free to use under the Unsplash License. Still credit the photographer: the push
 phase stores "Photo by <Photographer> on Unsplash" as the image caption.
 

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

@@ -17,10 +17,12 @@ user gave. **Out:** `~/.hostinger/<domain>/design.md` and the logo files in
 > Read `brief.md` → **Build mode** first. When it is **Bring your own frontend**, the user drives the
 > design — **do not generate three directions or write a prescriptive `design.md` over their project.**
 > The frontend already exists (or the user vibe-codes it with you); your job is to follow *their*
-> direction, not impose one. Skip Steps 1–7 below: either write nothing, or capture only what the user
-> explicitly asks for (a short note of their stated colours/vibe) so the frontend step has it. The logo
-> and token work here apply only when **Build mode is "Agent designs and builds"**. (This mirrors the
-> frontend step's existing "existing app the user brought" handling, now generalised to any backend.)
+> direction, not impose one. Skip Steps 1–7 below, *Keep the current look* included, even when
+> **Design direction** keeps the look of the app in this folder: their own code already carries it.
+> Either write nothing, or capture only what the user explicitly asks for (a short note of their
+> stated colours/vibe) so the frontend step has it, then do Step 7's `state.json` update so the flow
+> moves on to frontend. The logo and token work here apply only when **Build mode is "Agent designs
+> and builds"**.
 
 This is **prepare work**: it runs while provision settles (see *Background provision & the instance
 barrier* in the top-level `SKILL.md`). Nothing here calls the Hostinger connector or the backend.
@@ -73,7 +75,19 @@ Read `brief.md`, `state.json`, and `content-model.md` if it exists.
    logo file as it is (the header `<img>` or inline `<svg>`, plus its favicon if it has one) and save
    it unchanged in `brand/`. Screenshots or a brand guide: read the colours and lettering from them;
    a logo seen only in a screenshot counts as no logo file, so list "logo file needed" under gaps in
-   the final report. Files or exact colours and fonts the owner supplied win over anything you read.
+   the final report. The app in this folder (the path under `brief.md` → **Existing project**):
+   read its source; no build or browser needed.
+   - *Colours:* the theme tokens (Tailwind v4 `@theme`, v3 `tailwind.config.*` `theme`/`theme.extend`,
+     `:root` custom properties), ranked by how often the code uses them (class names, `var()`), with
+     the page background and body text taken from the root layout or `body`.
+   - *Fonts:* theme font tokens, `@fontsource` imports or dependencies, Google Fonts `<link>` or
+     `@import`, and the `font-family` on `body` and headings.
+   - *Logo:* files named `logo*` in `public/`, `static/`, `src/assets/` or `assets/`;
+     `favicon*`, `icon*` or `apple-icon*` in `public/`, `static/`, `app/` or `src/app/`; or the icon
+     declared by `<link rel="icon">` in `index.html` or the root layout's `metadata.icons`. Copy them
+     unchanged into `brand/`.
+
+   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"). A skipped tool result is not Keep; see

package/skills/headless/steps/06-frontend/SKILL.md

@@ -28,7 +28,7 @@ workspace `~/.hostinger/<domain>/src/`.
 > API, or the MySQL database recorded in `site.json → database`). It comes in two shapes, decided back in
 > **refine**:
 >
-> - **An existing app the user brought to deploy** (refine routes "deploy my app" here). **Use their
+> - **An existing app under Build mode "Bring your own frontend"** (refine routes "deploy my app" here). **Use their
 >   project as the source** — copy/point `~/.hostinger/<domain>/src/` at it and keep its own framework and
 >   UI. **Do not scaffold a new project, and do not re-implement `design.md` over it** (so **the design
 >   step does not apply** to an app that brings its own UI). Your job is only to make it deployable: set
@@ -36,7 +36,10 @@ workspace `~/.hostinger/<domain>/src/`.
 >   Step 2 design pass**, and ignore the `content-model.md` requirement in Step 3.
 > - **A new app built from the brief.** Scaffold and build it from `brief.md` (and `design.md` if the
 >   design step produced one — design *does* run for a from-scratch app). Its data is owned by the app, so
->   there is still **no `content-model.md`** to bind against.
+>   there is still **no `content-model.md`** to bind against. An existing app under **Build mode "Agent
+>   designs and builds"** takes this shape too, but starts from its source: copy the project at
+>   `brief.md` → **Existing project** into `~/.hostinger/<domain>/src/`, keep its framework, screens,
+>   features and data wiring, and rebuild its UI to `design.md` instead of scaffolding a new project.
 >
 > Framework choice (Step 1), the build, and hand-off (Step 4) apply to both. The per-backend bullets in
 > Step 3 are **WordPress / WooCommerce / Ecommerce only** — for a webapp follow the Webapp bullet there.
@@ -50,7 +53,8 @@ it, and the backend constraint:
   Next.js is the default, not a requirement (Express, Nuxt, SvelteKit, etc. are all fine).
 - **WordPress + WooCommerce → SSR required** (same reason — cart/checkout need per-request rendering).
 - **WordPress → SSG (Astro)** when the brief says SSG, otherwise **SSR (Next.js default)**.
-- **Webapp → the app's own stack.** An **existing app** keeps its current framework (don't impose one); a
+- **Webapp → the app's own stack.** An **existing app** keeps its current framework (don't impose one), including
+  one rebuilt under **Agent designs and builds**; a
   **new app** uses whatever fits the brief (SSR or SPA). Either way it deploys as a Node.js app (Step 8) —
   an SSR app runs a server, a SPA builds to static output.
 - Map rendering → framework: **`ssr` → Next.js**, **`ssg` → Astro** — unless the brief/prompt explicitly