hostinger-api-mcp 3.19.1 → 3.19.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.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

package/gemini-extension.json

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

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

package/src/core/skills.js

@@ -253,10 +253,10 @@ export default [
       },
       {
         "uri": "skill://hostinger-headless/steps/09-done/SKILL.md",
-        "digest": "sha256:62da301dbc366d1c2c7e051e2b124e7eb59b19e6c2517e7cb2eb3420b3f8bbd5",
-        "size": 10482,
+        "digest": "sha256:abd326c5bfb891bdc98b6d0137b7fadd9e8e6c949f59251c03c7a524653a3574",
+        "size": 11207,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-done\ndescription: \"Step 9 (done) of the Hostinger Headless flow. Verifies the live site, then hands over the URLs (hPanel success page, main site, WordPress/store admin, dashboard), opens the success page in the browser on a successful run, and gives a summary of what was built and what the user can do next. Its final report format is also used whenever a run stops early.\"\n---\n\n# headless-step-done\n\nVerify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a\nsummary of what was built, and what the user can do next. **On a successful run, open the success page\nfor the user** (see *Open the success page*).\n\n## Verify the live site (brief)\n\nOn a run that deployed this session, re-confirm what you're about to hand over actually works (deploy\nalready checked this — this is a quick re-confirm, not a full re-run):\n\n- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static\n  HTML with real content).\n- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.\n- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store\n  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the\n  storefront API for the sales channel → 200 (Ecommerce).\n- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so\n  don't send another here. In the handover, tell the owner the contact page is live and enquiries email\n  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address\n  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead\n  of claiming the form sends.\n\nIf a check fails, say so in the outcome paragraph and don't claim the site is live.\n\n## Final report\n\nEvery run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or\nmissing step, a failed provision, the user pausing). Build it from `state.json`, `site.json`,\n`deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't\nclaim a stage passed if you didn't check it.\n\nWrite it in this order:\n\n1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped\n   early, name the stage it stopped at, why, and what the user will see right now (e.g. \"the site\n   root returns 403 until the frontend is deployed\").\n\n2. **Steps completed** — a table with one row per stage that ran:\n\n   | Stage | Result |\n   |---|---|\n   | connect | How the connector was reached, MCP version, how sign-in happened. |\n   | 1 check state | New build / resumed at `<stage>` / adopted an existing site. |\n   | 2 refine | What the brief is and which backend it chose (say if a sample brief was used). |\n   | 3 provision | Plan and order used, how long setup took, which verification checks passed. |\n   | 4 content model | What was created (counts of pages, posts, terms, menus, media, SEO) and how it was verified. |\n   | … | One row for each further stage that ran (design, frontend, validate, deploy, done). |\n\n   Stages that didn't run are left out of the table and named in the outcome paragraph instead.\n   Use the stage numbers and names from the orchestrator's flow table.\n\n3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`\n   (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /\n   `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin\n   and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success\n   page*), so printing its URL in the report is just noise — the only exception is when a browser\n   can't be opened (handled in that section):\n\n   - **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.\n   - **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the\n     auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json\n     wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give\n     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password. Also\n     note the plain `urls.wp_admin` as a fallback. **Never print or store a password.** For a\n     **WordPress + WooCommerce** store, this *same* wp-admin login is the store admin (wp-admin →\n     WooCommerce → Products/Orders) — do **not** use the Ecommerce `store_admin` path. **Call out the one\n     setup step under *Gaps / follow-ups*:** when `site.json → woocommerce.payment_enabled` is `false`,\n     the owner must enable a payment method + a shipping zone in WooCommerce → Settings before checkout\n     works (the catalog and cart already work). For a Hostinger **Ecommerce** store, link the store admin\n     from `urls.store_admin` instead.\n   - **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website\n     is installed by now).\n   - **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`\n   - **REST API** (for developers): `urls.rest_api`.\n\n   > URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel\n   > release. If a built URL 404s, retry the same path without the `/<username>` segment before\n   > reporting it as broken.\n\n4. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a\n   resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.\n\n5. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or\n   left for the user (e.g. no images generated, default WordPress content left in place).\n\nNever include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and\noffer a one-click login link (`wordpress_login_create-links`), not credentials.\n\n## Open the success page\n\nOn a **successful** run (the deploy succeeded and the live checks passed), open the success page in the\nuser's **main / system browser** right after presenting the report, so they land on the hPanel\ncelebration/next-steps screen for their new site. This is a side effect only — **don't print the\nsuccess URL in the report output** (it just opens); the one exception is the can't-open-a-browser\nfallback below. Build the URL with `<tool>` as the running tool's onboarding slug (see *State and\nartifacts* in the top-level `SKILL.md`):\n\n```bash\n# Build the URL first, then open it with the OS default (main) browser — not an embedded one.\n# <tool> = the onboarding slug\nURL=\"https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/success/<domain>/<tool>\"\nopen \"$URL\"        # macOS\n# xdg-open \"$URL\"  # Linux\n# start \"\" \"$URL\"  # Windows\n```\n\n- **Main browser only.** Use the OS opener above (`open` / `xdg-open` / `start`) so the page lands in\n  Chrome, Safari, Edge, or whatever the user actually uses. **Do not** open it in an embedded or\n  sandboxed browser (Cursor IDE browser / `cursor-ide-browser`, Playwright, Puppeteer, WebView, or\n  any in-agent browser tab). Those stay inside the tool session and the user won't see the\n  celebration page where they expect it.\n- Open it **once**, and only on a successful run — never on an early stop or a failed deploy.\n- If your tool can't open a browser (the command isn't available, or `open`/`xdg-open`/`start`\n  fails), don't treat it as a failure and **don't fall back to an embedded browser**. This is the\n  **one** case where you print the success URL — show it once in the report and tell the user to\n  open it themselves in their main browser.\n\n## Build report\n\nRight after the final report, save the build report for this run. It turns the run log (stage times\nfrom `state.json`, events from `events.jsonl`) into `reports/<run>.json` and `.html`, and copies the\nHTML to `report.html` in the workspace:\n\n```bash\nnode <skill>/run-log.mjs <domain> event good '{\"text\":\"<something that went well>\"}'   # one per thing, if not logged yet\nnode <skill>/run-log.mjs <domain> stage-end done ok\nnode <skill>/run-log.mjs <domain> report --outcome <live|stopped|failed> [--tokens '<json>']\n```\n\nThen send it to Hostinger: pass `reports/<run>.json` unchanged to `hosting_headless_submit-build-report`\nand run `report-sent <run>` (or `report-rejected <run>` on a 422). The `report` command prints the\nexact path and run id. Don't ask first; see *Run log and build report* in the top-level `SKILL.md`\nfor failures. Then tell the user in one line: \"Sent the build report to Hostinger to help improve\nthe flow.\" On a 422 say it's saved locally only; on any other failure say it'll be sent next session.\n\nIf the user asks for more changes after this report in the same session, call\n`run-log.mjs <domain> run-resume --reason \"<what they asked for>\"` before the work. Then log as\nusual and run `report` again when it's done. It updates this run's report in place, and the report\nlists the follow-up. Send the updated report the same way.\n\n- **Outcome:** `live` when the deploy succeeded this run, `failed` when a stage failed and you\n  couldn't recover, `stopped` for everything else (the user paused, a dummy or missing step). Leave\n  `--outcome` out and the script decides from the log.\n- **Before you write it,** check that every issue, correction and skill gap from this run is in\n  `events.jsonl`. Log any that are missing now; the report only shows what was logged.\n- **After you write it,** read the `warning:` lines `report` prints. They list logging gaps: a stage\n  that never ended, a start that was estimated, a stage logged with no duration, or (on a live build)\n  a stage that was never logged. Fix what you can: `stage-end` an open stage, or correct a start with\n  `stage-fix <stage> --started-ago <time>`, then run `report` again. What you can't fix stays in the report's\n  *Logging gaps* section.\n- **Tokens:** only what your tool tells you about your own usage (see *Run log and build report* in\n  the top-level `SKILL.md`).\n- In the final report's *Where state lives*, add the path to `report.html` so the user can open it.\n\nDo this on every run, including the early stops: those reports are the most useful ones.\n"
+        "text": "---\nname: headless-step-done\ndescription: \"Step 9 (done) of the Hostinger Headless flow. Verifies the live site, then hands over the URLs (hPanel success page, main site, WordPress/store admin, dashboard), opens the success page in the browser on a successful run, and gives a summary of what was built and what the user can do next. Its final report format is also used whenever a run stops early.\"\n---\n\n# headless-step-done\n\nVerify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a\nsummary of what was built, and what the user can do next. **On a successful run, open the success page\nfor the user** (see *Open the success page*).\n\n## Final report\n\nEvery run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or\nmissing step, a failed provision, the user pausing). On a run that deployed this session, run the\nchecks in *Verify the live site* below first. Build the report from `state.json`, `site.json`,\n`deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't\nclaim a stage passed if you didn't check it.\n\nWrite it in this order:\n\n1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped\n   early, name the stage it stopped at, why, and what the user will see right now (e.g. \"the site\n   root returns 403 until the frontend is deployed\").\n\n2. **Steps completed.** This table is required on every run, including early stops: never replace\n   it with prose. Give one row per stage that ran, using the stage numbers and names from the\n   orchestrator's flow table. Leave out stages that didn't run and name them in the outcome\n   paragraph instead. A finished WordPress blog build looks like this:\n\n   | Stage | Result |\n   |---|---|\n   | connect | Hostinger connector reached over MCP (`@hostinger/mcp` 1.9.2); signed in through the browser login. |\n   | 1 check state | New build for `harbourlight.blog`; no earlier workspace. |\n   | 2 refine | Personal travel blog about coastal towns in the UK; backend: WordPress. |\n   | 3 provision | Business plan, order 41875230; setup took 6 min; domain, SSL and WordPress checks passed. |\n   | 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. |\n   | 5 design | \"Salt & Ink\" direction: serif headings, sea-blue accents; `design.md` and logo written, logo check passed. |\n   | 6 frontend | Next.js SSR with home, blog, post, category and contact pages wired to the REST API; local build passed. |\n   | 7 validate | Instance setup completed; REST API returned the 8 pushed posts; no preview (nobody signing off). |\n   | 8 deploy | Source uploaded, build finished in 3 min; site root returns 200. |\n   | 9 done | Main site, wp-admin and REST API re-checked live: all returned 200. |\n\n3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`\n   (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /\n   `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin\n   and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success\n   page*), so printing its URL in the report is just noise — the only exception is when a browser\n   can't be opened (handled in that section):\n\n   - **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.\n   - **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the\n     auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json\n     wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give\n     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password. Also\n     note the plain `urls.wp_admin` as a fallback. **Never print or store a password.** For a\n     **WordPress + WooCommerce** store, this *same* wp-admin login is the store admin (wp-admin →\n     WooCommerce → Products/Orders) — do **not** use the Ecommerce `store_admin` path. **Call out the one\n     setup step under *Gaps / follow-ups*:** when `site.json → woocommerce.payment_enabled` is `false`,\n     the owner must enable a payment method + a shipping zone in WooCommerce → Settings before checkout\n     works (the catalog and cart already work). For a Hostinger **Ecommerce** store, link the store admin\n     from `urls.store_admin` instead.\n   - **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website\n     is installed by now).\n   - **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`\n   - **REST API** (for developers): `urls.rest_api`.\n\n   > URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel\n   > release. If a built URL 404s, retry the same path without the `/<username>` segment before\n   > reporting it as broken.\n\n4. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a\n   resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.\n\n5. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or\n   left for the user (e.g. no images generated, default WordPress content left in place).\n\nNever include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and\noffer a one-click login link (`wordpress_login_create-links`), not credentials.\n\n## Verify the live site (brief)\n\nOn a run that deployed this session, re-confirm what you're about to hand over actually works (deploy\nalready checked this — this is a quick re-confirm, not a full re-run):\n\n- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static\n  HTML with real content).\n- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.\n- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store\n  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the\n  storefront API for the sales channel → 200 (Ecommerce).\n- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so\n  don't send another here. In the handover, tell the owner the contact page is live and enquiries email\n  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address\n  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead\n  of claiming the form sends.\n\nIf a check fails, say so in the outcome paragraph and don't claim the site is live.\n\n## Open the success page\n\nOn a **successful** run (the deploy succeeded and the live checks passed), open the success page in the\nuser's **main / system browser** right after presenting the report, so they land on the hPanel\ncelebration/next-steps screen for their new site. This is a side effect only — **don't print the\nsuccess URL in the report output** (it just opens); the one exception is the can't-open-a-browser\nfallback below. Build the URL with `<tool>` as the running tool's onboarding slug (see *State and\nartifacts* in the top-level `SKILL.md`):\n\n```bash\n# Build the URL first, then open it with the OS default (main) browser — not an embedded one.\n# <tool> = the onboarding slug\nURL=\"https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/success/<domain>/<tool>\"\nopen \"$URL\"        # macOS\n# xdg-open \"$URL\"  # Linux\n# start \"\" \"$URL\"  # Windows\n```\n\n- **Main browser only.** Use the OS opener above (`open` / `xdg-open` / `start`) so the page lands in\n  Chrome, Safari, Edge, or whatever the user actually uses. **Do not** open it in an embedded or\n  sandboxed browser (Cursor IDE browser / `cursor-ide-browser`, Playwright, Puppeteer, WebView, or\n  any in-agent browser tab). Those stay inside the tool session and the user won't see the\n  celebration page where they expect it.\n- Open it **once**, and only on a successful run — never on an early stop or a failed deploy.\n- If your tool can't open a browser (the command isn't available, or `open`/`xdg-open`/`start`\n  fails), don't treat it as a failure and **don't fall back to an embedded browser**. This is the\n  **one** case where you print the success URL — show it once in the report and tell the user to\n  open it themselves in their main browser.\n\n## Build report\n\nRight after the final report, save the build report for this run. It turns the run log (stage times\nfrom `state.json`, events from `events.jsonl`) into `reports/<run>.json` and `.html`, and copies the\nHTML to `report.html` in the workspace:\n\n```bash\nnode <skill>/run-log.mjs <domain> event good '{\"text\":\"<something that went well>\"}'   # one per thing, if not logged yet\nnode <skill>/run-log.mjs <domain> stage-end done ok\nnode <skill>/run-log.mjs <domain> report --outcome <live|stopped|failed> [--tokens '<json>']\n```\n\nThen send it to Hostinger: pass `reports/<run>.json` unchanged to `hosting_headless_submit-build-report`\nand run `report-sent <run>` (or `report-rejected <run>` on a 422). The `report` command prints the\nexact path and run id. Don't ask first; see *Run log and build report* in the top-level `SKILL.md`\nfor failures. Then tell the user in one line: \"Sent the build report to Hostinger to help improve\nthe flow.\" On a 422 say it's saved locally only; on any other failure say it'll be sent next session.\n\nIf the user asks for more changes after this report in the same session, call\n`run-log.mjs <domain> run-resume --reason \"<what they asked for>\"` before the work. Then log as\nusual and run `report` again when it's done. It updates this run's report in place, and the report\nlists the follow-up. Send the updated report the same way.\n\n- **Outcome:** `live` when the deploy succeeded this run, `failed` when a stage failed and you\n  couldn't recover, `stopped` for everything else (the user paused, a dummy or missing step). Leave\n  `--outcome` out and the script decides from the log.\n- **Before you write it,** check that every issue, correction and skill gap from this run is in\n  `events.jsonl`. Log any that are missing now; the report only shows what was logged.\n- **After you write it,** read the `warning:` lines `report` prints. They list logging gaps: a stage\n  that never ended, a start that was estimated, a stage logged with no duration, or (on a live build)\n  a stage that was never logged. Fix what you can: `stage-end` an open stage, or correct a start with\n  `stage-fix <stage> --started-ago <time>`, then run `report` again. What you can't fix stays in the report's\n  *Logging gaps* section.\n- **Tokens:** only what your tool tells you about your own usage (see *Run log and build report* in\n  the top-level `SKILL.md`).\n- In the final report's *Where state lives*, add the path to `report.html` so the user can open it.\n\nDo this on every run, including the early stops: those reports are the most useful ones.\n"
       }
     ]
   },

package/src/core/skills.ts

@@ -267,10 +267,10 @@ const skills: Skill[] = [
       },
       {
         "uri": "skill://hostinger-headless/steps/09-done/SKILL.md",
-        "digest": "sha256:62da301dbc366d1c2c7e051e2b124e7eb59b19e6c2517e7cb2eb3420b3f8bbd5",
-        "size": 10482,
+        "digest": "sha256:abd326c5bfb891bdc98b6d0137b7fadd9e8e6c949f59251c03c7a524653a3574",
+        "size": 11207,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-done\ndescription: \"Step 9 (done) of the Hostinger Headless flow. Verifies the live site, then hands over the URLs (hPanel success page, main site, WordPress/store admin, dashboard), opens the success page in the browser on a successful run, and gives a summary of what was built and what the user can do next. Its final report format is also used whenever a run stops early.\"\n---\n\n# headless-step-done\n\nVerify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a\nsummary of what was built, and what the user can do next. **On a successful run, open the success page\nfor the user** (see *Open the success page*).\n\n## Verify the live site (brief)\n\nOn a run that deployed this session, re-confirm what you're about to hand over actually works (deploy\nalready checked this — this is a quick re-confirm, not a full re-run):\n\n- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static\n  HTML with real content).\n- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.\n- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store\n  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the\n  storefront API for the sales channel → 200 (Ecommerce).\n- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so\n  don't send another here. In the handover, tell the owner the contact page is live and enquiries email\n  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address\n  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead\n  of claiming the form sends.\n\nIf a check fails, say so in the outcome paragraph and don't claim the site is live.\n\n## Final report\n\nEvery run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or\nmissing step, a failed provision, the user pausing). Build it from `state.json`, `site.json`,\n`deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't\nclaim a stage passed if you didn't check it.\n\nWrite it in this order:\n\n1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped\n   early, name the stage it stopped at, why, and what the user will see right now (e.g. \"the site\n   root returns 403 until the frontend is deployed\").\n\n2. **Steps completed** — a table with one row per stage that ran:\n\n   | Stage | Result |\n   |---|---|\n   | connect | How the connector was reached, MCP version, how sign-in happened. |\n   | 1 check state | New build / resumed at `<stage>` / adopted an existing site. |\n   | 2 refine | What the brief is and which backend it chose (say if a sample brief was used). |\n   | 3 provision | Plan and order used, how long setup took, which verification checks passed. |\n   | 4 content model | What was created (counts of pages, posts, terms, menus, media, SEO) and how it was verified. |\n   | … | One row for each further stage that ran (design, frontend, validate, deploy, done). |\n\n   Stages that didn't run are left out of the table and named in the outcome paragraph instead.\n   Use the stage numbers and names from the orchestrator's flow table.\n\n3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`\n   (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /\n   `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin\n   and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success\n   page*), so printing its URL in the report is just noise — the only exception is when a browser\n   can't be opened (handled in that section):\n\n   - **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.\n   - **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the\n     auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json\n     wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give\n     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password. Also\n     note the plain `urls.wp_admin` as a fallback. **Never print or store a password.** For a\n     **WordPress + WooCommerce** store, this *same* wp-admin login is the store admin (wp-admin →\n     WooCommerce → Products/Orders) — do **not** use the Ecommerce `store_admin` path. **Call out the one\n     setup step under *Gaps / follow-ups*:** when `site.json → woocommerce.payment_enabled` is `false`,\n     the owner must enable a payment method + a shipping zone in WooCommerce → Settings before checkout\n     works (the catalog and cart already work). For a Hostinger **Ecommerce** store, link the store admin\n     from `urls.store_admin` instead.\n   - **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website\n     is installed by now).\n   - **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`\n   - **REST API** (for developers): `urls.rest_api`.\n\n   > URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel\n   > release. If a built URL 404s, retry the same path without the `/<username>` segment before\n   > reporting it as broken.\n\n4. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a\n   resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.\n\n5. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or\n   left for the user (e.g. no images generated, default WordPress content left in place).\n\nNever include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and\noffer a one-click login link (`wordpress_login_create-links`), not credentials.\n\n## Open the success page\n\nOn a **successful** run (the deploy succeeded and the live checks passed), open the success page in the\nuser's **main / system browser** right after presenting the report, so they land on the hPanel\ncelebration/next-steps screen for their new site. This is a side effect only — **don't print the\nsuccess URL in the report output** (it just opens); the one exception is the can't-open-a-browser\nfallback below. Build the URL with `<tool>` as the running tool's onboarding slug (see *State and\nartifacts* in the top-level `SKILL.md`):\n\n```bash\n# Build the URL first, then open it with the OS default (main) browser — not an embedded one.\n# <tool> = the onboarding slug\nURL=\"https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/success/<domain>/<tool>\"\nopen \"$URL\"        # macOS\n# xdg-open \"$URL\"  # Linux\n# start \"\" \"$URL\"  # Windows\n```\n\n- **Main browser only.** Use the OS opener above (`open` / `xdg-open` / `start`) so the page lands in\n  Chrome, Safari, Edge, or whatever the user actually uses. **Do not** open it in an embedded or\n  sandboxed browser (Cursor IDE browser / `cursor-ide-browser`, Playwright, Puppeteer, WebView, or\n  any in-agent browser tab). Those stay inside the tool session and the user won't see the\n  celebration page where they expect it.\n- Open it **once**, and only on a successful run — never on an early stop or a failed deploy.\n- If your tool can't open a browser (the command isn't available, or `open`/`xdg-open`/`start`\n  fails), don't treat it as a failure and **don't fall back to an embedded browser**. This is the\n  **one** case where you print the success URL — show it once in the report and tell the user to\n  open it themselves in their main browser.\n\n## Build report\n\nRight after the final report, save the build report for this run. It turns the run log (stage times\nfrom `state.json`, events from `events.jsonl`) into `reports/<run>.json` and `.html`, and copies the\nHTML to `report.html` in the workspace:\n\n```bash\nnode <skill>/run-log.mjs <domain> event good '{\"text\":\"<something that went well>\"}'   # one per thing, if not logged yet\nnode <skill>/run-log.mjs <domain> stage-end done ok\nnode <skill>/run-log.mjs <domain> report --outcome <live|stopped|failed> [--tokens '<json>']\n```\n\nThen send it to Hostinger: pass `reports/<run>.json` unchanged to `hosting_headless_submit-build-report`\nand run `report-sent <run>` (or `report-rejected <run>` on a 422). The `report` command prints the\nexact path and run id. Don't ask first; see *Run log and build report* in the top-level `SKILL.md`\nfor failures. Then tell the user in one line: \"Sent the build report to Hostinger to help improve\nthe flow.\" On a 422 say it's saved locally only; on any other failure say it'll be sent next session.\n\nIf the user asks for more changes after this report in the same session, call\n`run-log.mjs <domain> run-resume --reason \"<what they asked for>\"` before the work. Then log as\nusual and run `report` again when it's done. It updates this run's report in place, and the report\nlists the follow-up. Send the updated report the same way.\n\n- **Outcome:** `live` when the deploy succeeded this run, `failed` when a stage failed and you\n  couldn't recover, `stopped` for everything else (the user paused, a dummy or missing step). Leave\n  `--outcome` out and the script decides from the log.\n- **Before you write it,** check that every issue, correction and skill gap from this run is in\n  `events.jsonl`. Log any that are missing now; the report only shows what was logged.\n- **After you write it,** read the `warning:` lines `report` prints. They list logging gaps: a stage\n  that never ended, a start that was estimated, a stage logged with no duration, or (on a live build)\n  a stage that was never logged. Fix what you can: `stage-end` an open stage, or correct a start with\n  `stage-fix <stage> --started-ago <time>`, then run `report` again. What you can't fix stays in the report's\n  *Logging gaps* section.\n- **Tokens:** only what your tool tells you about your own usage (see *Run log and build report* in\n  the top-level `SKILL.md`).\n- In the final report's *Where state lives*, add the path to `report.html` so the user can open it.\n\nDo this on every run, including the early stops: those reports are the most useful ones.\n"
+        "text": "---\nname: headless-step-done\ndescription: \"Step 9 (done) of the Hostinger Headless flow. Verifies the live site, then hands over the URLs (hPanel success page, main site, WordPress/store admin, dashboard), opens the success page in the browser on a successful run, and gives a summary of what was built and what the user can do next. Its final report format is also used whenever a run stops early.\"\n---\n\n# headless-step-done\n\nVerify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a\nsummary of what was built, and what the user can do next. **On a successful run, open the success page\nfor the user** (see *Open the success page*).\n\n## Final report\n\nEvery run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or\nmissing step, a failed provision, the user pausing). On a run that deployed this session, run the\nchecks in *Verify the live site* below first. Build the report from `state.json`, `site.json`,\n`deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't\nclaim a stage passed if you didn't check it.\n\nWrite it in this order:\n\n1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped\n   early, name the stage it stopped at, why, and what the user will see right now (e.g. \"the site\n   root returns 403 until the frontend is deployed\").\n\n2. **Steps completed.** This table is required on every run, including early stops: never replace\n   it with prose. Give one row per stage that ran, using the stage numbers and names from the\n   orchestrator's flow table. Leave out stages that didn't run and name them in the outcome\n   paragraph instead. A finished WordPress blog build looks like this:\n\n   | Stage | Result |\n   |---|---|\n   | connect | Hostinger connector reached over MCP (`@hostinger/mcp` 1.9.2); signed in through the browser login. |\n   | 1 check state | New build for `harbourlight.blog`; no earlier workspace. |\n   | 2 refine | Personal travel blog about coastal towns in the UK; backend: WordPress. |\n   | 3 provision | Business plan, order 41875230; setup took 6 min; domain, SSL and WordPress checks passed. |\n   | 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. |\n   | 5 design | \"Salt & Ink\" direction: serif headings, sea-blue accents; `design.md` and logo written, logo check passed. |\n   | 6 frontend | Next.js SSR with home, blog, post, category and contact pages wired to the REST API; local build passed. |\n   | 7 validate | Instance setup completed; REST API returned the 8 pushed posts; no preview (nobody signing off). |\n   | 8 deploy | Source uploaded, build finished in 3 min; site root returns 200. |\n   | 9 done | Main site, wp-admin and REST API re-checked live: all returned 200. |\n\n3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`\n   (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /\n   `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin\n   and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success\n   page*), so printing its URL in the report is just noise — the only exception is when a browser\n   can't be opened (handled in that section):\n\n   - **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.\n   - **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the\n     auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json\n     wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give\n     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password. Also\n     note the plain `urls.wp_admin` as a fallback. **Never print or store a password.** For a\n     **WordPress + WooCommerce** store, this *same* wp-admin login is the store admin (wp-admin →\n     WooCommerce → Products/Orders) — do **not** use the Ecommerce `store_admin` path. **Call out the one\n     setup step under *Gaps / follow-ups*:** when `site.json → woocommerce.payment_enabled` is `false`,\n     the owner must enable a payment method + a shipping zone in WooCommerce → Settings before checkout\n     works (the catalog and cart already work). For a Hostinger **Ecommerce** store, link the store admin\n     from `urls.store_admin` instead.\n   - **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website\n     is installed by now).\n   - **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`\n   - **REST API** (for developers): `urls.rest_api`.\n\n   > URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel\n   > release. If a built URL 404s, retry the same path without the `/<username>` segment before\n   > reporting it as broken.\n\n4. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a\n   resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.\n\n5. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or\n   left for the user (e.g. no images generated, default WordPress content left in place).\n\nNever include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and\noffer a one-click login link (`wordpress_login_create-links`), not credentials.\n\n## Verify the live site (brief)\n\nOn a run that deployed this session, re-confirm what you're about to hand over actually works (deploy\nalready checked this — this is a quick re-confirm, not a full re-run):\n\n- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static\n  HTML with real content).\n- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.\n- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store\n  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the\n  storefront API for the sales channel → 200 (Ecommerce).\n- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so\n  don't send another here. In the handover, tell the owner the contact page is live and enquiries email\n  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address\n  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead\n  of claiming the form sends.\n\nIf a check fails, say so in the outcome paragraph and don't claim the site is live.\n\n## Open the success page\n\nOn a **successful** run (the deploy succeeded and the live checks passed), open the success page in the\nuser's **main / system browser** right after presenting the report, so they land on the hPanel\ncelebration/next-steps screen for their new site. This is a side effect only — **don't print the\nsuccess URL in the report output** (it just opens); the one exception is the can't-open-a-browser\nfallback below. Build the URL with `<tool>` as the running tool's onboarding slug (see *State and\nartifacts* in the top-level `SKILL.md`):\n\n```bash\n# Build the URL first, then open it with the OS default (main) browser — not an embedded one.\n# <tool> = the onboarding slug\nURL=\"https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/success/<domain>/<tool>\"\nopen \"$URL\"        # macOS\n# xdg-open \"$URL\"  # Linux\n# start \"\" \"$URL\"  # Windows\n```\n\n- **Main browser only.** Use the OS opener above (`open` / `xdg-open` / `start`) so the page lands in\n  Chrome, Safari, Edge, or whatever the user actually uses. **Do not** open it in an embedded or\n  sandboxed browser (Cursor IDE browser / `cursor-ide-browser`, Playwright, Puppeteer, WebView, or\n  any in-agent browser tab). Those stay inside the tool session and the user won't see the\n  celebration page where they expect it.\n- Open it **once**, and only on a successful run — never on an early stop or a failed deploy.\n- If your tool can't open a browser (the command isn't available, or `open`/`xdg-open`/`start`\n  fails), don't treat it as a failure and **don't fall back to an embedded browser**. This is the\n  **one** case where you print the success URL — show it once in the report and tell the user to\n  open it themselves in their main browser.\n\n## Build report\n\nRight after the final report, save the build report for this run. It turns the run log (stage times\nfrom `state.json`, events from `events.jsonl`) into `reports/<run>.json` and `.html`, and copies the\nHTML to `report.html` in the workspace:\n\n```bash\nnode <skill>/run-log.mjs <domain> event good '{\"text\":\"<something that went well>\"}'   # one per thing, if not logged yet\nnode <skill>/run-log.mjs <domain> stage-end done ok\nnode <skill>/run-log.mjs <domain> report --outcome <live|stopped|failed> [--tokens '<json>']\n```\n\nThen send it to Hostinger: pass `reports/<run>.json` unchanged to `hosting_headless_submit-build-report`\nand run `report-sent <run>` (or `report-rejected <run>` on a 422). The `report` command prints the\nexact path and run id. Don't ask first; see *Run log and build report* in the top-level `SKILL.md`\nfor failures. Then tell the user in one line: \"Sent the build report to Hostinger to help improve\nthe flow.\" On a 422 say it's saved locally only; on any other failure say it'll be sent next session.\n\nIf the user asks for more changes after this report in the same session, call\n`run-log.mjs <domain> run-resume --reason \"<what they asked for>\"` before the work. Then log as\nusual and run `report` again when it's done. It updates this run's report in place, and the report\nlists the follow-up. Send the updated report the same way.\n\n- **Outcome:** `live` when the deploy succeeded this run, `failed` when a stage failed and you\n  couldn't recover, `stopped` for everything else (the user paused, a dummy or missing step). Leave\n  `--outcome` out and the script decides from the log.\n- **Before you write it,** check that every issue, correction and skill gap from this run is in\n  `events.jsonl`. Log any that are missing now; the report only shows what was logged.\n- **After you write it,** read the `warning:` lines `report` prints. They list logging gaps: a stage\n  that never ended, a start that was estimated, a stage logged with no duration, or (on a live build)\n  a stage that was never logged. Fix what you can: `stage-end` an open stage, or correct a start with\n  `stage-fix <stage> --started-ago <time>`, then run `report` again. What you can't fix stays in the report's\n  *Logging gaps* section.\n- **Tokens:** only what your tool tells you about your own usage (see *Run log and build report* in\n  the top-level `SKILL.md`).\n- In the final report's *Where state lives*, add the path to `report.html` so the user can open it.\n\nDo this on every run, including the early stops: those reports are the most useful ones.\n"
       }
     ]
   },

package/src/servers/agency-hosting.js

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agency-hosting.js';
 import instructions from '../core/instructions.agency-hosting.js';
 
-startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.19.1', tools, instructions });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.19.2', tools, instructions });

package/src/servers/agency-hosting.ts

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agency-hosting.js';
 import instructions from '../core/instructions.agency-hosting.js';
 
-startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.19.1', tools, instructions });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.19.2', tools, instructions });

package/src/servers/agent-readiness.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agent-readiness.js';
 
-startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.19.2', tools });

package/src/servers/agent-readiness.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agent-readiness.js';
 
-startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.19.2', tools });

package/src/servers/all.js

@@ -5,4 +5,4 @@ import tools from '../core/tools/all.js';
 import instructions from '../core/instructions.js';
 import skills from '../core/skills.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '3.19.1', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.19.2', tools, instructions, skills });

package/src/servers/all.ts

@@ -5,4 +5,4 @@ import tools from '../core/tools/all.js';
 import instructions from '../core/instructions.js';
 import skills from '../core/skills.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '3.19.1', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.19.2', tools, instructions, skills });

package/src/servers/billing.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/billing.js';
 
-startServer({ name: 'hostinger-billing-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.19.2', tools });

package/src/servers/billing.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/billing.js';
 
-startServer({ name: 'hostinger-billing-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.19.2', tools });

package/src/servers/dns.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/dns.js';
 
-startServer({ name: 'hostinger-dns-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.19.2', tools });

package/src/servers/dns.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/dns.js';
 
-startServer({ name: 'hostinger-dns-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.19.2', tools });

package/src/servers/domains.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/domains.js';
 
-startServer({ name: 'hostinger-domains-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.19.2', tools });

package/src/servers/domains.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/domains.js';
 
-startServer({ name: 'hostinger-domains-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.19.2', tools });

package/src/servers/ecommerce.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/ecommerce.js';
 
-startServer({ name: 'hostinger-ecommerce-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.19.2', tools });

package/src/servers/ecommerce.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/ecommerce.js';
 
-startServer({ name: 'hostinger-ecommerce-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.19.2', tools });

package/src/servers/horizons.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/horizons.js';
 
-startServer({ name: 'hostinger-horizons-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.19.2', tools });

package/src/servers/horizons.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/horizons.js';
 
-startServer({ name: 'hostinger-horizons-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.19.2', tools });

package/src/servers/hosting.js

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/hosting.js';
 import instructions from '../core/instructions.js';
 
-startServer({ name: 'hostinger-hosting-mcp', version: '3.19.1', tools, instructions });
+startServer({ name: 'hostinger-hosting-mcp', version: '3.19.2', tools, instructions });

package/src/servers/hosting.ts

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/hosting.js';
 import instructions from '../core/instructions.js';
 
-startServer({ name: 'hostinger-hosting-mcp', version: '3.19.1', tools, instructions });
+startServer({ name: 'hostinger-hosting-mcp', version: '3.19.2', tools, instructions });

package/src/servers/mail.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/mail.js';
 
-startServer({ name: 'hostinger-mail-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.19.2', tools });

package/src/servers/mail.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/mail.js';
 
-startServer({ name: 'hostinger-mail-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.19.2', tools });

package/src/servers/reach.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/reach.js';
 
-startServer({ name: 'hostinger-reach-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.19.2', tools });

package/src/servers/reach.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/reach.js';
 
-startServer({ name: 'hostinger-reach-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.19.2', tools });

package/src/servers/vps.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/vps.js';
 
-startServer({ name: 'hostinger-vps-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.19.2', tools });

package/src/servers/vps.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/vps.js';
 
-startServer({ name: 'hostinger-vps-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.19.2', tools });

package/src/servers/wordpress.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/wordpress.js';
 
-startServer({ name: 'hostinger-wordpress-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.19.2', tools });

package/src/servers/wordpress.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/wordpress.js';
 
-startServer({ name: 'hostinger-wordpress-mcp', version: '3.19.1', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.19.2', tools });