hostinger-api-mcp 3.12.2 → 3.14.0

package/CHANGELOG.md

@@ -4,6 +4,21 @@ 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.14.0 — 2026-10-27
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/steps/02-refine/SKILL.md`, `skills/headless/steps/03-provision/webapp/SKILL.md`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
+## v3.13.0 — 2026-10-27
+
+### Also in this release
+
+- Bundled agent skills: `skills/deploy-to-hosting/SKILL.md`, `skills/headless/steps/08-deploy/SKILL.md`
+- Server instructions: 4 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.12.2 — 2026-10-27
 
 ### Also in this release

package/gemini-extension.json

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

package/skills/deploy-to-hosting/SKILL.md

@@ -13,9 +13,23 @@ Ship a project that already exists — on disk or in a Git repository — to a H
 - Batch reads with `multi-execute`; values pass between steps as `$steps.<i>.<path>`. Batches chain operations from one server only — the Hostinger Connector runs `hosting`, `wordpress` and `agency-hosting` as separate servers.
 - Every deploy overwrites the website's current contents. Confirm the target domain with the user before the first deploy to a site that already has content.
 
+## 0. If a shell and the Hostinger CLI are available
+
+`hostinger up` does steps 1 to 3 in one call and is the shortest path when you can run commands and the `hostinger` CLI is installed (`brew install hostinger/tap/hostinger`), signed in and has `hostinger up`: it finds or creates the website, detects the type, packs the directory (honouring `.gitignore`; skipping `node_modules`, `.git`, `.env` files, credentials and private keys, and listing symlinks it does not follow), uploads, deploys or builds, waits for the build and links the directory in `.hostinger/site.json`, the same file this skill uses. Nothing is asked without a terminal.
+
+```
+hostinger up <dir> --domain <domain> --yes --format json     # existing website; --yes only after the user agreed to replace its content
+hostinger up <dir> --create --format json                    # new website on the only plan, free subdomain
+hostinger up <dir> --domain <domain> --dry-run                # the plan as JSON, changes nothing: show it to the user before a first deploy (overwritesContent: the real run needs --yes)
+hostinger up <dir> --domain <domain> --type nodejs --app-type next --output-directory .next --build-script build --node-version 22 --yes --format json
+hostinger up <dir> --domain <domain> --no-wait --format json  # returns buildUuid at once; poll with `hostinger hosting nodejs build <domain> <uuid>`
+```
+
+Run it from the project directory: the link is written in the current directory, with `path` naming `<dir>`. The JSON result has `url`, `data.type`, `data.buildUuid`, `data.buildState`, `data.skippedFiles` and, on failure, `error`. Shared and Cloud plans only; for Agency plans, archives and WordPress plugins or themes, use the operations below. The MCP's `hosting_deploy` does the same work when there is no shell.
+
 ## 1. Pick the target website
 
-- `.hostinger/site.json` in the project: reuse its `domain` and `username` (or `website_uid`).
+- `.hostinger/site.json` in the project: reuse its `domain` and `username` (or `website_uid`). The CLI's `hostinger up` and `hostinger link` write the same file and keep any fields you add while it names the same website (linking another website starts it afresh); its `type` may be `static`, `nodejs` or `php`.
 - Otherwise look the domain up with `hosting_websites_list` (Shared and Cloud; substring match — take the exact entry) and `agency-hosting_websites_list-plan` (Agency; keep `details.uid`).
 - No website yet:
   - Shared and Cloud: take a domain (the user's own, or `hosting_domains_generate-free-subdomain`) and an `order_id` from `hosting_orders_list`, then `hosting_websites_create`. `datacenter_code` is needed only for the first website on a new plan (first entry of `hosting_datacenters_list`). Poll `hosting_websites_list-setups` with `domain` every 10–15 s until `status: completed` — uploads and deploys return 404 or 409 before that.

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

@@ -9,8 +9,9 @@ Find out what the user wants to build, guess which backend fits, and write it do
 **conversation, not a form**: the pasted prompt names a domain and nothing else, so everything about
 the site comes from talking to the user.
 
-**Keep it short.** The only thing you must know is *what they are building* — enough to guess the
-backend. Every other question is optional: the more the user gives, the better the site, but never
+**Keep it short.** You must know what they are building, whether they sell and whether they'll
+publish content over time — enough to guess the backend — plus, when Step 2 found a project in the folder, the
+**Existing project** confirms. Every other question is optional: the more the user gives, the better the site, but never
 hold the build hostage to refinement. Fill gaps with sensible defaults and say so in the brief. A
 skipped question tool is not the user passing on a question; see *When you ask the user* in the
 top-level `SKILL.md`.
@@ -52,8 +53,8 @@ Before asking anything, collect what the user has already given you, so you don'
   framework config (`next.config.*`, `astro.config.*`, `vite.config.*`, `svelte.config.*`, `nuxt.*`),
   a `src/` or `app/` tree, `index.html`, a storefront/cart, etc. A real project here usually means the
   user **already has their own frontend** and mainly needs a Hostinger backend to wire it to — lean
-  toward "bring your own frontend" in Step 3. If the folder has nothing site-like, assume they don't
-  and lean toward "agent builds it".
+  toward "bring your own frontend" in Step 3. That is what *Step 2 found a project in the folder*
+  means everywhere below.
 - Anything in the pasted prompt beyond the domain (a sentence, a link, a screenshot).
 - Files in the current project that look like site material (copy, logos, product lists, images).
 - What the agent already knows about the user from local memory or this conversation (a prior build,
@@ -62,10 +63,13 @@ Before asking anything, collect what the user has already given you, so you don'
 
 ## Step 3 — Ask
 
-If Step 2 already answers *what are you building* and *will they sell*, skip the Round 1–3 questions
-below, but still ask **Build mode** before moving on.
+When Step 2 found a project in the folder, ask **Build mode** and the **Existing project** confirms
+below in your first message, after Round 1 when Round 1 still needs asking; they don't count toward
+the 3 rounds, and code that answers Round 1 never skips them. Otherwise don't ask Build mode: it
+defaults (see *Build mode* below).
 
-Otherwise open with one line and **wait for the user's answer**: *"Tell me what you want to build — a
+If Step 2 already answers the three Round 1 questions, skip the Round 1–3 questions below. Otherwise
+open with one line and **wait for the user's answer**: *"Tell me what you want to build — a
 sentence is enough. Links, screenshots or files help too. Skip anything you don't want to answer."*
 
 > **"What do you want to build?" is an OPEN question — ask it in plain prose and wait.** Never turn it
@@ -84,18 +88,19 @@ decide" means *use defaults*, not *ask again*. A skipped tool result is not thei
 that round in plain text, as *When you ask the user* in the top-level `SKILL.md` says. The re-ask
 repeats the round; it doesn't count toward the 3.
 
-**Round 1 — what it is (the only required round):**
+**Round 1 — what it is (required; these three decide the backend):**
 
 1. **What are you building?** The business or project, and what the site is for.
 2. **Will you sell anything on it?** Physical products, digital products, services with checkout —
-   or nothing. *This decides the backend.* Skip it only when the answer is already unmistakable
-   ("an online shop for my candles", "my personal blog"); when in doubt, ask.
-3. **Who is it for?** The audience, and how they'll find the site. *(optional)*
+   or nothing. Skip it only when the answer is already unmistakable ("an online shop for my
+   candles", "my personal blog"); when in doubt, ask.
+3. **Will you publish content over time?** Blog posts, articles, news, recipes, portfolio pieces,
+   case studies, and how often — or a handful of pages that rarely change. Skip it only when the
+   answer is already unmistakable ("my personal blog", an app the user is deploying).
 
 **Round 2 — what goes on it (optional, adapt to Round 1):**
 
-- **Content they'll publish over time** — blog posts, articles, news, recipes, portfolio pieces,
-  case studies? How often? Or is it a handful of pages that rarely change?
+- **Who is it for?** The audience, and how they'll find the site.
 - **Pages** — propose a page list from what you know and ask them to add or remove.
 - If they sell: **what and how many** — a rough product count, categories, whether products have
   variants (size, colour), and the shipping regions.
@@ -110,6 +115,20 @@ the design directions, so it is **not** asked again later; gather it here:
 - **Colours & brand** — brand/accent colours, logo, fonts, existing copy, photos. Note where they live.
 - **Must-haves and no-gos** — contact form, newsletter, bookings, languages, things to avoid.
 
+**Existing project — when Step 2 found a project in the folder (required, in the Build mode message):**
+
+Build mode answers the look. The code shows the rest, but the user knows what has to survive the
+move, so ask each as a confirm of what you found, naming it, so the user only says yes or corrects you:
+
+1. **Routes that open directly** — the client-side routes you found (name them, e.g. `/stats`,
+   `/settings`) must open from a typed link and survive a refresh? Ask only when the code routes in
+   the browser (React Router, Vue Router, a history or hash router); a server-routed app has none.
+2. **Data** — the database and environment variable names you found (or "none"): is that all the
+   app needs? Hostinger gives the app MySQL only: a different database (Postgres, MongoDB, a SQLite
+   file) goes under **Out of scope** as a migration the user owns, not as `Database: MySQL`.
+
+Record the routes and data in **Existing project**.
+
 If the user asks for something outside the scope (user accounts, member areas, bookings with a
 calendar backend, user-generated content), say plainly that the headless flow doesn't support it yet
 and record it under **Out of scope** — don't promise it.
@@ -121,25 +140,27 @@ and record it under **Out of scope** — don't promise it.
 > for it. (A form that needs accounts, payments or a booking calendar is still out of scope — this is a
 > plain name/email/message enquiry form.)
 
-### Build mode — ask once (this one *is* a user choice)
+### Build mode — a user choice when the folder holds a project
 
-The backend is your call, but **how the frontend gets built is the user's** — because most of the time
-the user already has their own frontend and just needs a Hostinger backend to wire it to. After the
-folder + memory inspection (Step 2), ask **one** question (a structured choice is ideal here), seeding
-the default from what you found:
+The backend is your call, but **how the frontend gets built is the user's**. When Step 2 found a
+project in the folder, ask **one** question (a structured choice is ideal here); it also settles the
+app's look:
 
-- **Bring your own frontend** *(default when Step 2 found a real project in the folder)* — "I already
-  have a frontend / I'll drive the design and we vibe-code it together." The agent **uses the user's
+- **Bring your own frontend — keep my app's look** *(the default)* — the agent **uses the user's
   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.
-- **Agent designs and builds it** *(default when the folder has nothing site-like)* — "Give me ideas
-  — you design and code it." Today's flow: the design step proposes directions and the frontend step
-  scaffolds and implements them.
+  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.
+
+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`).
 
-A skipped tool result is not a pick: re-ask in plain text, and use the seeded default only when the
-user says so (see *When you ask the user* in the top-level `SKILL.md`).
+Otherwise don't ask: Build mode is **Agent designs and builds**. When the user says they have their
+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
@@ -195,6 +216,8 @@ site, not the backend:
 
 - **The plan** — what it is, audience, pages, products (if any), tone. Mark anything you defaulted
   (*"assumed: warm, minimal look"*) so the user sees what they skipped.
+- **Your app** *(when Step 2 found a project in the folder)* — one line: keeps its look or gets a new
+  one, the routes that must open directly, and whether a database is created.
 - **How it's built** — state the backend as a *consequence* in one plain line, focused on what it
   means for them day to day ("I'll build this on WordPress, so you edit pages and posts in a normal
   WordPress admin"), **not** as a choice you're asking them to make. Don't ask "is WordPress OK?" or
@@ -208,8 +231,9 @@ theirs and note it in the brief.
 ## Step 6 — Write `brief.md` and hand off
 
 Write `brief.md` from the template below. Fill every section from the conversation, defaulting what
-the user skipped and tagging it `(assumed)`; leave out **Products** when nothing is sold. Use the
-user's own words where you can. Then update `state.json`:
+the user skipped and tagging it `(assumed)`; leave out **Products** when nothing is sold and
+**Existing project** unless Step 2 found a project in the folder. Use the user's own words where you
+can. Then update `state.json`:
 `"stage": "provision"`, fresh `updated_at`.
 
 The **Suggested backend** section is the contract with `03-provision/SKILL.md`, which routes on it.
@@ -239,7 +263,7 @@ routes it to the `wordpress` subfolder with the store enabled (it is **not** a s
 (layout, structure, mood); colours / brand palette; any screenshots. This is where ALL design questions
 land — the frontend step reads this and does not re-ask. Write "Agent's choice: <short style>" when the
 user didn't specify. Record in the user's own words a request to keep their current look ("Keep the look
-we have: <site URL | screenshots | brand guide>") and any logo idea they describe; the design step acts
+we have: <site URL | screenshots | brand guide | the app in this folder>") and any logo idea they describe; the design step acts
 on both.>
 
 ## Pages
@@ -261,14 +285,18 @@ on both.>
 ## Assets
 <logo, colours, photos, copy the user provided and where they are; "None yet" if none>
 
+## Existing project
+<only when Step 2 found a project in the folder: its path; the framework; the client-side
+routes that must open directly and on refresh (or "None"); Database: none | MySQL; the env var names
+the app reads — names only, never values>
+
 ## Suggested backend
 **<WordPress | Ecommerce | WordPress + Ecommerce | WordPress + WooCommerce | Webapp>** — <one-line reason>.
 <"Confirmed by the user." or "User chose this over the recommended <X> because <reason>.">
 
 ## Build mode
 **<Bring your own frontend | Agent designs and builds>** — <one line>. <When "Bring your own frontend":
-the path to the user's existing project in the current folder (the frontend source), and how they want
-to drive design/code. When "Agent designs and builds": leave the design + frontend steps to run as
+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
 defers to the user and frontend builds on their project; **Agent designs and builds** → both run as normal.
 

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

@@ -58,6 +58,8 @@ All website/database operations below go through the Hostinger connector (`execu
 ## Step 3 — Database (only if the app needs one)
 
 Skip this step entirely for an app with no database (static SPA, an app that talks to an external API).
+The app needs one when `brief.md` → **Existing project** says **Database: MySQL**, or, for a new app,
+when the brief describes data the app stores itself.
 This is **join-half** work — it needs the live website, so run it once `provision.status == "completed"`.
 
 **Preferred — let the platform create the database and inject the credentials:**

package/skills/headless/steps/08-deploy/SKILL.md

@@ -17,6 +17,13 @@ This is an **instance-barrier** step: run it only after `provision.status == "co
 > `hostinger-api-mcp` server instead (see the connect step:
 > `npx --yes --package=@hostinger/mcp@latest hostinger-api-mcp`).
 
+> **With a shell and the Hostinger CLI installed**, the same deploy is one command, with the build
+> settings passed exactly as the table below says. Run it from the project, since it links the current directory:
+> `cd ~/.hostinger/<domain>/src && hostinger up --domain <domain> --type nodejs --app-type <appType> --output-directory <dir> --build-script build --node-version 22 --package-manager npm --yes --format json`.
+> It uploads, builds, waits and returns `data.buildUuid` and `data.buildState`; add `--no-wait` to
+> return at once and poll with `hostinger hosting nodejs build <domain> <uuid>`. Then continue at
+> "Verify" below.
+
 **In:** the project in `~/.hostinger/<domain>/src/`, `site.json` (`username`, `urls`), `state.json`
 (`frontend.framework`, `frontend.rendering`).
 

package/src/core/instructions.agency-hosting.js

@@ -1,2 +1,2 @@
 // Auto-generated server instructions
-export default "Hostinger API notes for agents. Find operations with search; the inputSchema it returns is authoritative for request shapes. Run one with execute, or chain several with multi-execute.\n\nDatabases (web hosting, hosting_* operations)\n- MySQL runs on the same server as the website. From the deployed app connect to host 127.0.0.1, port 3306. PHP may also use localhost (Unix socket). Node.js should use 127.0.0.1: localhost can resolve to IPv6 (::1) and not every database user has that grant.\n- The `host` from hosting_databases_list (srvNNNN.hstgr.io) is only for connections from outside Hostinger, after hosting_databases_create-remote-connection. Never use it from the app.\n- Agency Plan (agency-hosting_* operations) database users are created for localhost; the PHP app connects there.\n\nAsynchronous operations\n- A success response often means \"queued\", not \"done\". Poll the matching read operation with backoff (seconds, then minutes). Never re-send the write.\n- hosting_websites_create -> poll hosting_websites_list-setups with the domain until status is completed (a few minutes); file, deploy and database calls return 404/409 before that.\n- A Node.js deploy or hosting_nodejs_start-build -> poll hosting_get-deployment with the domain until the build state is completed or failed; a failed build comes back with its logs and failure analysis.\n- wordpress_installations_install and WordPress plugin/theme/core jobs -> poll wordpress_installations_list.\n- agency-hosting_website-setups_create -> poll agency-hosting_website-setups_status with setup_uuid; other Agency Plan jobs -> agency-hosting_websites_list-processes.\n- Website deletion, database repair and domain contact changes finish in the background.\n\nCredentials\n- Never write database passwords or API tokens into source code, client-side JavaScript or committed .env files.\n- Node.js apps read them from environment variables: set the full set with hosting_nodejs_replace-environment-variables (full replace; values are masked on read). Build-time variables (Next.js) need a new build afterwards.\n- PHP apps read them from a config file on the server, outside the repository.\n- Generate strong passwords and do not echo them back once stored.\n\nFor end-to-end site builds install the headless skill: npx skills add hostinger/api-mcp-server";
+export default "Hostinger API notes for agents. Find operations with search; the inputSchema it returns is authoritative for request shapes. Run one with execute, or chain several with multi-execute.\n\nDatabases (web hosting, hosting_* operations)\n- MySQL runs on the same server as the website. From the deployed app connect to host 127.0.0.1, port 3306. PHP may also use localhost (Unix socket). Node.js should use 127.0.0.1: localhost can resolve to IPv6 (::1) and not every database user has that grant.\n- The `host` from hosting_databases_list (srvNNNN.hstgr.io) is only for connections from outside Hostinger, after hosting_databases_create-remote-connection. Never use it from the app.\n- Agency Plan (agency-hosting_* operations) database users are created for localhost; the PHP app connects there.\n\nAsynchronous operations\n- A success response often means \"queued\", not \"done\". Poll the matching read operation with backoff (seconds, then minutes). Never re-send the write.\n- hosting_websites_create -> poll hosting_websites_list-setups with the domain until status is completed (a few minutes); file, deploy and database calls return 404/409 before that.\n- A Node.js deploy or hosting_nodejs_start-build -> poll hosting_get-deployment with the domain until the build state is completed or failed; a failed build comes back with its logs and failure analysis.\n- wordpress_installations_install and WordPress plugin/theme/core jobs -> poll wordpress_installations_list.\n- agency-hosting_website-setups_create -> poll agency-hosting_website-setups_status with setup_uuid; other Agency Plan jobs -> agency-hosting_websites_list-processes.\n- Website deletion, database repair and domain contact changes finish in the background.\n\nCredentials\n- Never write database passwords or API tokens into source code, client-side JavaScript or committed .env files.\n- Node.js apps read them from environment variables: set the full set with hosting_nodejs_replace-environment-variables (full replace; values are masked on read). Build-time variables (Next.js) need a new build afterwards.\n- PHP apps read them from a config file on the server, outside the repository.\n- Generate strong passwords and do not echo them back once stored.\n\nDeploying from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\n\nFor end-to-end site builds install the headless skill: npx skills add hostinger/api-mcp-server";

package/src/core/instructions.agency-hosting.ts

@@ -1,3 +1,3 @@
 // Auto-generated server instructions
-const instructions: string = "Hostinger API notes for agents. Find operations with search; the inputSchema it returns is authoritative for request shapes. Run one with execute, or chain several with multi-execute.\n\nDatabases (web hosting, hosting_* operations)\n- MySQL runs on the same server as the website. From the deployed app connect to host 127.0.0.1, port 3306. PHP may also use localhost (Unix socket). Node.js should use 127.0.0.1: localhost can resolve to IPv6 (::1) and not every database user has that grant.\n- The `host` from hosting_databases_list (srvNNNN.hstgr.io) is only for connections from outside Hostinger, after hosting_databases_create-remote-connection. Never use it from the app.\n- Agency Plan (agency-hosting_* operations) database users are created for localhost; the PHP app connects there.\n\nAsynchronous operations\n- A success response often means \"queued\", not \"done\". Poll the matching read operation with backoff (seconds, then minutes). Never re-send the write.\n- hosting_websites_create -> poll hosting_websites_list-setups with the domain until status is completed (a few minutes); file, deploy and database calls return 404/409 before that.\n- A Node.js deploy or hosting_nodejs_start-build -> poll hosting_get-deployment with the domain until the build state is completed or failed; a failed build comes back with its logs and failure analysis.\n- wordpress_installations_install and WordPress plugin/theme/core jobs -> poll wordpress_installations_list.\n- agency-hosting_website-setups_create -> poll agency-hosting_website-setups_status with setup_uuid; other Agency Plan jobs -> agency-hosting_websites_list-processes.\n- Website deletion, database repair and domain contact changes finish in the background.\n\nCredentials\n- Never write database passwords or API tokens into source code, client-side JavaScript or committed .env files.\n- Node.js apps read them from environment variables: set the full set with hosting_nodejs_replace-environment-variables (full replace; values are masked on read). Build-time variables (Next.js) need a new build afterwards.\n- PHP apps read them from a config file on the server, outside the repository.\n- Generate strong passwords and do not echo them back once stored.\n\nFor end-to-end site builds install the headless skill: npx skills add hostinger/api-mcp-server";
+const instructions: string = "Hostinger API notes for agents. Find operations with search; the inputSchema it returns is authoritative for request shapes. Run one with execute, or chain several with multi-execute.\n\nDatabases (web hosting, hosting_* operations)\n- MySQL runs on the same server as the website. From the deployed app connect to host 127.0.0.1, port 3306. PHP may also use localhost (Unix socket). Node.js should use 127.0.0.1: localhost can resolve to IPv6 (::1) and not every database user has that grant.\n- The `host` from hosting_databases_list (srvNNNN.hstgr.io) is only for connections from outside Hostinger, after hosting_databases_create-remote-connection. Never use it from the app.\n- Agency Plan (agency-hosting_* operations) database users are created for localhost; the PHP app connects there.\n\nAsynchronous operations\n- A success response often means \"queued\", not \"done\". Poll the matching read operation with backoff (seconds, then minutes). Never re-send the write.\n- hosting_websites_create -> poll hosting_websites_list-setups with the domain until status is completed (a few minutes); file, deploy and database calls return 404/409 before that.\n- A Node.js deploy or hosting_nodejs_start-build -> poll hosting_get-deployment with the domain until the build state is completed or failed; a failed build comes back with its logs and failure analysis.\n- wordpress_installations_install and WordPress plugin/theme/core jobs -> poll wordpress_installations_list.\n- agency-hosting_website-setups_create -> poll agency-hosting_website-setups_status with setup_uuid; other Agency Plan jobs -> agency-hosting_websites_list-processes.\n- Website deletion, database repair and domain contact changes finish in the background.\n\nCredentials\n- Never write database passwords or API tokens into source code, client-side JavaScript or committed .env files.\n- Node.js apps read them from environment variables: set the full set with hosting_nodejs_replace-environment-variables (full replace; values are masked on read). Build-time variables (Next.js) need a new build afterwards.\n- PHP apps read them from a config file on the server, outside the repository.\n- Generate strong passwords and do not echo them back once stored.\n\nDeploying from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\n\nFor end-to-end site builds install the headless skill: npx skills add hostinger/api-mcp-server";
 export default instructions;

package/src/core/instructions.js

@@ -1,2 +1,2 @@
 // Auto-generated server instructions
-export default "Hostinger API notes for agents. Find operations with search; the inputSchema it returns is authoritative for request shapes. Run one with execute, or chain several with multi-execute.\n\nDatabases (web hosting, hosting_* operations)\n- MySQL runs on the same server as the website. From the deployed app connect to host 127.0.0.1, port 3306. PHP may also use localhost (Unix socket). Node.js should use 127.0.0.1: localhost can resolve to IPv6 (::1) and not every database user has that grant.\n- The `host` from hosting_databases_list (srvNNNN.hstgr.io) is only for connections from outside Hostinger, after hosting_databases_create-remote-connection. Never use it from the app.\n- Agency Plan (agency-hosting_* operations) database users are created for localhost; the PHP app connects there.\n\nAsynchronous operations\n- A success response often means \"queued\", not \"done\". Poll the matching read operation with backoff (seconds, then minutes). Never re-send the write.\n- hosting_websites_create -> poll hosting_websites_list-setups with the domain until status is completed (a few minutes); file, deploy and database calls return 404/409 before that.\n- A Node.js deploy or hosting_nodejs_start-build -> poll hosting_get-deployment with the domain until the build state is completed or failed; a failed build comes back with its logs and failure analysis.\n- wordpress_installations_install and WordPress plugin/theme/core jobs -> poll wordpress_installations_list.\n- agency-hosting_website-setups_create -> poll agency-hosting_website-setups_status with setup_uuid; other Agency Plan jobs -> agency-hosting_websites_list-processes.\n- Website deletion, database repair and domain contact changes finish in the background.\n\nCredentials\n- Never write database passwords or API tokens into source code, client-side JavaScript or committed .env files.\n- Node.js apps read them from environment variables: set the full set with hosting_nodejs_replace-environment-variables (full replace; values are masked on read). Build-time variables (Next.js) need a new build afterwards.\n- PHP apps read them from a config file on the server, outside the repository.\n- Generate strong passwords and do not echo them back once stored.\n\nDeploying a website (this server only)\n- hosting_deploy replaces the upload, archive-deploy, build, WordPress import/plugin/theme and Git operations named above. Give it a local directory (it detects static/PHP, Node.js, a WordPress site, plugin or theme and packs it itself), a local archive with `type`, or `git: { repository, branch }`. Do not run those operations by hand.\n- A Node.js deploy returns a buildUuid at once and builds on the server. Poll hosting_get-deployment with the domain, pausing longer each time, until the build state is completed or failed. A failed build comes back with its logs and analysis: fix the cause and deploy again. It replaces the build, log and settings operations.\n- Static, PHP, plugin and theme deploys are complete when hosting_deploy returns. A WordPress site import only starts: its files are extracted and the site is ready a few minutes later.\n- Every deploy overwrites the site's contents: confirm the domain with the user before the first deploy to a site that already has content.\n\nFor end-to-end site builds install the headless skill: npx skills add hostinger/api-mcp-server";
+export default "Hostinger API notes for agents. Find operations with search; the inputSchema it returns is authoritative for request shapes. Run one with execute, or chain several with multi-execute.\n\nDatabases (web hosting, hosting_* operations)\n- MySQL runs on the same server as the website. From the deployed app connect to host 127.0.0.1, port 3306. PHP may also use localhost (Unix socket). Node.js should use 127.0.0.1: localhost can resolve to IPv6 (::1) and not every database user has that grant.\n- The `host` from hosting_databases_list (srvNNNN.hstgr.io) is only for connections from outside Hostinger, after hosting_databases_create-remote-connection. Never use it from the app.\n- Agency Plan (agency-hosting_* operations) database users are created for localhost; the PHP app connects there.\n\nAsynchronous operations\n- A success response often means \"queued\", not \"done\". Poll the matching read operation with backoff (seconds, then minutes). Never re-send the write.\n- hosting_websites_create -> poll hosting_websites_list-setups with the domain until status is completed (a few minutes); file, deploy and database calls return 404/409 before that.\n- A Node.js deploy or hosting_nodejs_start-build -> poll hosting_get-deployment with the domain until the build state is completed or failed; a failed build comes back with its logs and failure analysis.\n- wordpress_installations_install and WordPress plugin/theme/core jobs -> poll wordpress_installations_list.\n- agency-hosting_website-setups_create -> poll agency-hosting_website-setups_status with setup_uuid; other Agency Plan jobs -> agency-hosting_websites_list-processes.\n- Website deletion, database repair and domain contact changes finish in the background.\n\nCredentials\n- Never write database passwords or API tokens into source code, client-side JavaScript or committed .env files.\n- Node.js apps read them from environment variables: set the full set with hosting_nodejs_replace-environment-variables (full replace; values are masked on read). Build-time variables (Next.js) need a new build afterwards.\n- PHP apps read them from a config file on the server, outside the repository.\n- Generate strong passwords and do not echo them back once stored.\n\nDeploying from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\n\nDeploying a website (this server only)\n- hosting_deploy replaces the upload, archive-deploy, build, WordPress import/plugin/theme and Git operations named above. Give it a local directory (it detects static/PHP, Node.js, a WordPress site, plugin or theme and packs it itself), a local archive with `type`, or `git: { repository, branch }`. Do not run those operations by hand.\n- A Node.js deploy returns a buildUuid at once and builds on the server. Poll hosting_get-deployment with the domain, pausing longer each time, until the build state is completed or failed. A failed build comes back with its logs and analysis: fix the cause and deploy again. It replaces the build, log and settings operations.\n- Static, PHP, plugin and theme deploys are complete when hosting_deploy returns. A WordPress site import only starts: its files are extracted and the site is ready a few minutes later.\n- Every deploy overwrites the site's contents: confirm the domain with the user before the first deploy to a site that already has content.\n\nFor end-to-end site builds install the headless skill: npx skills add hostinger/api-mcp-server";

package/src/core/instructions.ts

@@ -1,3 +1,3 @@
 // Auto-generated server instructions
-const instructions: string = "Hostinger API notes for agents. Find operations with search; the inputSchema it returns is authoritative for request shapes. Run one with execute, or chain several with multi-execute.\n\nDatabases (web hosting, hosting_* operations)\n- MySQL runs on the same server as the website. From the deployed app connect to host 127.0.0.1, port 3306. PHP may also use localhost (Unix socket). Node.js should use 127.0.0.1: localhost can resolve to IPv6 (::1) and not every database user has that grant.\n- The `host` from hosting_databases_list (srvNNNN.hstgr.io) is only for connections from outside Hostinger, after hosting_databases_create-remote-connection. Never use it from the app.\n- Agency Plan (agency-hosting_* operations) database users are created for localhost; the PHP app connects there.\n\nAsynchronous operations\n- A success response often means \"queued\", not \"done\". Poll the matching read operation with backoff (seconds, then minutes). Never re-send the write.\n- hosting_websites_create -> poll hosting_websites_list-setups with the domain until status is completed (a few minutes); file, deploy and database calls return 404/409 before that.\n- A Node.js deploy or hosting_nodejs_start-build -> poll hosting_get-deployment with the domain until the build state is completed or failed; a failed build comes back with its logs and failure analysis.\n- wordpress_installations_install and WordPress plugin/theme/core jobs -> poll wordpress_installations_list.\n- agency-hosting_website-setups_create -> poll agency-hosting_website-setups_status with setup_uuid; other Agency Plan jobs -> agency-hosting_websites_list-processes.\n- Website deletion, database repair and domain contact changes finish in the background.\n\nCredentials\n- Never write database passwords or API tokens into source code, client-side JavaScript or committed .env files.\n- Node.js apps read them from environment variables: set the full set with hosting_nodejs_replace-environment-variables (full replace; values are masked on read). Build-time variables (Next.js) need a new build afterwards.\n- PHP apps read them from a config file on the server, outside the repository.\n- Generate strong passwords and do not echo them back once stored.\n\nDeploying a website (this server only)\n- hosting_deploy replaces the upload, archive-deploy, build, WordPress import/plugin/theme and Git operations named above. Give it a local directory (it detects static/PHP, Node.js, a WordPress site, plugin or theme and packs it itself), a local archive with `type`, or `git: { repository, branch }`. Do not run those operations by hand.\n- A Node.js deploy returns a buildUuid at once and builds on the server. Poll hosting_get-deployment with the domain, pausing longer each time, until the build state is completed or failed. A failed build comes back with its logs and analysis: fix the cause and deploy again. It replaces the build, log and settings operations.\n- Static, PHP, plugin and theme deploys are complete when hosting_deploy returns. A WordPress site import only starts: its files are extracted and the site is ready a few minutes later.\n- Every deploy overwrites the site's contents: confirm the domain with the user before the first deploy to a site that already has content.\n\nFor end-to-end site builds install the headless skill: npx skills add hostinger/api-mcp-server";
+const instructions: string = "Hostinger API notes for agents. Find operations with search; the inputSchema it returns is authoritative for request shapes. Run one with execute, or chain several with multi-execute.\n\nDatabases (web hosting, hosting_* operations)\n- MySQL runs on the same server as the website. From the deployed app connect to host 127.0.0.1, port 3306. PHP may also use localhost (Unix socket). Node.js should use 127.0.0.1: localhost can resolve to IPv6 (::1) and not every database user has that grant.\n- The `host` from hosting_databases_list (srvNNNN.hstgr.io) is only for connections from outside Hostinger, after hosting_databases_create-remote-connection. Never use it from the app.\n- Agency Plan (agency-hosting_* operations) database users are created for localhost; the PHP app connects there.\n\nAsynchronous operations\n- A success response often means \"queued\", not \"done\". Poll the matching read operation with backoff (seconds, then minutes). Never re-send the write.\n- hosting_websites_create -> poll hosting_websites_list-setups with the domain until status is completed (a few minutes); file, deploy and database calls return 404/409 before that.\n- A Node.js deploy or hosting_nodejs_start-build -> poll hosting_get-deployment with the domain until the build state is completed or failed; a failed build comes back with its logs and failure analysis.\n- wordpress_installations_install and WordPress plugin/theme/core jobs -> poll wordpress_installations_list.\n- agency-hosting_website-setups_create -> poll agency-hosting_website-setups_status with setup_uuid; other Agency Plan jobs -> agency-hosting_websites_list-processes.\n- Website deletion, database repair and domain contact changes finish in the background.\n\nCredentials\n- Never write database passwords or API tokens into source code, client-side JavaScript or committed .env files.\n- Node.js apps read them from environment variables: set the full set with hosting_nodejs_replace-environment-variables (full replace; values are masked on read). Build-time variables (Next.js) need a new build afterwards.\n- PHP apps read them from a config file on the server, outside the repository.\n- Generate strong passwords and do not echo them back once stored.\n\nDeploying from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\n\nDeploying a website (this server only)\n- hosting_deploy replaces the upload, archive-deploy, build, WordPress import/plugin/theme and Git operations named above. Give it a local directory (it detects static/PHP, Node.js, a WordPress site, plugin or theme and packs it itself), a local archive with `type`, or `git: { repository, branch }`. Do not run those operations by hand.\n- A Node.js deploy returns a buildUuid at once and builds on the server. Poll hosting_get-deployment with the domain, pausing longer each time, until the build state is completed or failed. A failed build comes back with its logs and analysis: fix the cause and deploy again. It replaces the build, log and settings operations.\n- Static, PHP, plugin and theme deploys are complete when hosting_deploy returns. A WordPress site import only starts: its files are extracted and the site is ready a few minutes later.\n- Every deploy overwrites the site's contents: confirm the domain with the user before the first deploy to a site that already has content.\n\nFor end-to-end site builds install the headless skill: npx skills add hostinger/api-mcp-server";
 export default instructions;