hostinger-api-mcp 3.19.0 → 3.19.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.19.2 — 2026-10-28
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/steps/09-done/SKILL.md`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
+## v3.19.1 — 2026-10-28
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/SKILL.md`, `skills/headless/connect/SKILL.md`, `skills/headless/run-log.mjs`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.19.0 — 2026-10-28
 
 No changes to the published artifact.

package/gemini-extension.json

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

package/skills/headless/SKILL.md

@@ -170,7 +170,7 @@ took from it.
 | File (under `~/.hostinger/<domain>/`) | Written by | Contains |
 |---|---|---|
 | `state.json` | every stage | tool, next stage, Hostinger connector version, timestamps |
-| `connect.json` | connect | tool, account/plan readiness |
+| `connect.json` | connect | tool, MCP version, sign-in method, plan; shape in `connect/SKILL.md` |
 | `brief.md` | refine | refined brief, audience, tone, pages, must-haves |
 | `site.json` | provision | chosen backend, username, install id, all URLs |
 | `content-model.md` | content model | entities, fields, pages, navigation |

package/skills/headless/connect/SKILL.md

@@ -87,7 +87,28 @@ Credentials live in `~/.config/hostinger-mcp/credentials.json` (macOS/Linux) or
 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.
 
-## Phase 3 - Continue to Headless Hosting steps
+## Phase 3 - Write `connect.json`
+
+Once the tool is connected, write `~/.hostinger/<domain>/connect.json` (create the folder if it is
+missing) in exactly this shape:
+
+```json
+{ "tool": "claude-code", "mcp": "hostinger-api-mcp 3.8.0", "auth": "oauth_cached",
+  "order_id": null, "plan": null, "connected_at": "2026-10-28T10:46:12Z" }
+```
+
+- `tool`: the `<tool>` from the Phase 2 route (`claude-code`, `codex`, `cursor`, `vscode`,
+  `antigravity`, `devin`, or a short lowercase name for an unlisted tool), the same value later
+  passed to `run-start --tool`.
+- `mcp`: one string, `hostinger-api-mcp <version>`, with the `version` from the `mcp_ok` event.
+  Never an object.
+- `auth`: the `method` from the `logged_in` event (`api_token`, `oauth_cached` or `oauth`).
+- `order_id`, `plan`: the active hosting plan's order id and name when you looked them up, else `null`.
+- `connected_at`: the current time in UTC, ISO 8601 to the second.
+
+Extra keys are allowed, but keep these six as above: the build report reads `tool` and `mcp`.
+
+## Phase 4 - Continue to Headless Hosting steps
 
 After evrything is verified and you have access to the Hostinger MCP Server and the skills then you can go back to `headless/SKILL.md` and follow the steps section to start the process.
 

package/skills/headless/run-log.mjs

@@ -100,6 +100,15 @@ function readEvents(ws) {
     .map((line) => JSON.parse(line));
 }
 
+// connect.json from older runs may hold mcp as an object or only mcp_version; the report needs strings.
+function readConnect(ws) {
+  const connect = readJson(join(ws.dir, 'connect.json'), {});
+  const mcp = connect.mcp ?? connect.mcp_version ?? null;
+  let version = mcp;
+  if (mcp !== null && typeof mcp !== 'string') version = mcp.name || mcp.version ? [mcp.name, mcp.version].filter(Boolean).join(' ') : JSON.stringify(mcp);
+  return { tool: typeof connect.tool === 'string' ? connect.tool : null, mcp: version };
+}
+
 function runStart(ws, flags) {
   const state = loadState(ws);
   // A previous run that never reached its report (closed window, crash) is closed out first, so
@@ -111,7 +120,7 @@ function runStart(ws, flags) {
   const fresh = loadState(ws);
   const previous = fresh.run ?? {};
   const startedAt = now();
-  const connect = readJson(join(ws.dir, 'connect.json'), {});
+  const connect = readConnect(ws);
   // Run ids are the start time; a second run in the same second gets a suffix.
   const taken = new Set([
     ...(fresh.history ?? []).map((h) => h.run),
@@ -268,7 +277,7 @@ function buildReport(ws, { outcome, tokens } = {}) {
   const run = currentRun(ws, state);
   const site = readJson(join(ws.dir, 'site.json'), {});
   const deploy = readJson(join(ws.dir, 'deploy.json'), {});
-  const connect = readJson(join(ws.dir, 'connect.json'), {});
+  const connect = readConnect(ws);
   const history = (state.history ?? []).filter((h) => h.run === run.id);
   // Lines logged before events were checked on write may not match the schema.
   const dropped = [];
@@ -291,7 +300,7 @@ function buildReport(ws, { outcome, tokens } = {}) {
   const stillOpen = resolvedOutcome !== 'abandoned' && history.some((h) => !h.ended_at);
   const endedAt = stillOpen ? now() : lastActivity;
   const stages = history.map((h) => ({ ...h, minutes: minutesBetween(h.started_at, h.ended_at ?? endedAt) }));
-  const gaps = [...loggingGaps(stages, run, resolvedOutcome), ...dropped];
+  const gaps = [...loggingGaps(stages, run, resolvedOutcome, site.backend), ...dropped];
   const strip = ({ ts, run: _run, type: _type, ...rest }) => ({ ...rest, logged_at: ts });
   const liveStage = stages.find((s) => s.stage === 'deploy' && s.result?.startsWith('ok'));
   if (!OUTCOMES.includes(resolvedOutcome)) fail(`unknown outcome "${resolvedOutcome}"; one of ${OUTCOMES.join(', ')}`);
@@ -316,7 +325,7 @@ function buildReport(ws, { outcome, tokens } = {}) {
       model: run.model ?? null,
       os: process.platform,
       node: process.version,
-      mcp: connect.mcp ?? null,
+      mcp: connect.mcp,
       backend: site.backend ?? null,
       frontend: frontendStack(ws.dir),
       outcome: resolvedOutcome,
@@ -400,15 +409,21 @@ function reportRejected(ws, [runId]) {
 
 // Gaps are printed as warnings by `report`, so guesses never pass as measurements.
 const EXPECTED_FOR_BUILD = ['check_state', 'refine', 'provision', 'content_model', 'design', 'frontend', 'validate', 'deploy'];
-function loggingGaps(stages, run, outcome) {
+// Stages a backend skips on purpose: webapp has no CMS, so no content model.
+const SKIPPED_BY_BACKEND = { webapp: ['content_model'] };
+function loggingGaps(stages, run, outcome, backend) {
   const gaps = [];
   for (const s of stages) {
-    if (!s.ended_at) gaps.push({ stage: s.stage, phase: s.phase, problem: 'started but never ended' });
-    else if (s.start_estimated) gaps.push({ stage: s.stage, phase: s.phase, problem: 'start time estimated, not measured' });
-    else if (Date.parse(s.ended_at) - Date.parse(s.started_at) < 5000) gaps.push({ stage: s.stage, phase: s.phase, problem: 'logged with no duration; probably started and ended in one go after the work' });
+    // A skipped stage did no work, so it has no duration to measure.
+    const problem = s.result === 'skipped' ? null
+      : !s.ended_at ? 'started but never ended'
+      : s.start_estimated ? 'start time estimated, not measured'
+      : Date.parse(s.ended_at) === Date.parse(s.started_at) ? 'logged with no duration; probably started and ended in one go after the work'
+      : null;
+    if (problem) gaps.push({ stage: s.stage, phase: s.phase, problem });
   }
   if (run.kind === 'build' && outcome === 'live') {
-    for (const stage of EXPECTED_FOR_BUILD) {
+    for (const stage of EXPECTED_FOR_BUILD.filter((name) => !SKIPPED_BY_BACKEND[backend]?.includes(name))) {
       if (!stages.some((s) => s.stage === stage)) gaps.push({ stage, phase: null, problem: 'never logged, though the site went live' });
     }
   }

package/skills/headless/steps/09-done/SKILL.md

@@ -9,29 +9,11 @@ Verify the live site, then hand over the URLs (success page, main site, WordPres
 summary of what was built, and what the user can do next. **On a successful run, open the success page
 for the user** (see *Open the success page*).
 
-## Verify the live site (brief)
-
-On a run that deployed this session, re-confirm what you're about to hand over actually works (deploy
-already checked this — this is a quick re-confirm, not a full re-run):
-
-- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static
-  HTML with real content).
-- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.
-- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store
-  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the
-  storefront API for the sales channel → 200 (Ecommerce).
-- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so
-  don't send another here. In the handover, tell the owner the contact page is live and enquiries email
-  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address
-  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead
-  of claiming the form sends.
-
-If a check fails, say so in the outcome paragraph and don't claim the site is live.
-
 ## Final report
 
 Every run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or
-missing step, a failed provision, the user pausing). Build it from `state.json`, `site.json`,
+missing step, a failed provision, the user pausing). On a run that deployed this session, run the
+checks in *Verify the live site* below first. Build the report from `state.json`, `site.json`,
 `deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't
 claim a stage passed if you didn't check it.
 
@@ -41,19 +23,23 @@ Write it in this order:
    early, name the stage it stopped at, why, and what the user will see right now (e.g. "the site
    root returns 403 until the frontend is deployed").
 
-2. **Steps completed** — a table with one row per stage that ran:
+2. **Steps completed.** This table is required on every run, including early stops: never replace
+   it with prose. Give one row per stage that ran, using the stage numbers and names from the
+   orchestrator's flow table. Leave out stages that didn't run and name them in the outcome
+   paragraph instead. A finished WordPress blog build looks like this:
 
    | Stage | Result |
    |---|---|
-   | connect | How the connector was reached, MCP version, how sign-in happened. |
-   | 1 check state | New build / resumed at `<stage>` / adopted an existing site. |
-   | 2 refine | What the brief is and which backend it chose (say if a sample brief was used). |
-   | 3 provision | Plan and order used, how long setup took, which verification checks passed. |
-   | 4 content model | What was created (counts of pages, posts, terms, menus, media, SEO) and how it was verified. |
-   | … | One row for each further stage that ran (design, frontend, validate, deploy, done). |
-
-   Stages that didn't run are left out of the table and named in the outcome paragraph instead.
-   Use the stage numbers and names from the orchestrator's flow table.
+   | connect | Hostinger connector reached over MCP (`@hostinger/mcp` 1.9.2); signed in through the browser login. |
+   | 1 check state | New build for `harbourlight.blog`; no earlier workspace. |
+   | 2 refine | Personal travel blog about coastal towns in the UK; backend: WordPress. |
+   | 3 provision | Business plan, order 41875230; setup took 6 min; domain, SSL and WordPress checks passed. |
+   | 4 content model | 5 pages, 8 posts, 6 categories, 1 menu, 14 images (Hostinger AI), SEO titles on every page; counts re-read from the REST API. |
+   | 5 design | "Salt & Ink" direction: serif headings, sea-blue accents; `design.md` and logo written, logo check passed. |
+   | 6 frontend | Next.js SSR with home, blog, post, category and contact pages wired to the REST API; local build passed. |
+   | 7 validate | Instance setup completed; REST API returned the 8 pushed posts; no preview (nobody signing off). |
+   | 8 deploy | Source uploaded, build finished in 3 min; site root returns 200. |
+   | 9 done | Main site, wp-admin and REST API re-checked live: all returned 200. |
 
 3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`
    (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /
@@ -92,6 +78,25 @@ Write it in this order:
 Never include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and
 offer a one-click login link (`wordpress_login_create-links`), not credentials.
 
+## Verify the live site (brief)
+
+On a run that deployed this session, re-confirm what you're about to hand over actually works (deploy
+already checked this — this is a quick re-confirm, not a full re-run):
+
+- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static
+  HTML with real content).
+- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.
+- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store
+  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the
+  storefront API for the sales channel → 200 (Ecommerce).
+- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so
+  don't send another here. In the handover, tell the owner the contact page is live and enquiries email
+  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address
+  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead
+  of claiming the form sends.
+
+If a check fails, say so in the outcome paragraph and don't claim the site is live.
+
 ## Open the success page
 
 On a **successful** run (the deploy succeeded and the live checks passed), open the success page in the