@hostinger/mcp 3.0.0 → 3.2.0

package/CHANGELOG.md

@@ -4,6 +4,39 @@ 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.2.0 — 2026-10-19
+
+### Operations
+
+- Added `hosting_deploy` — Deploy website, nodejs app, WordPress plugin or theme
+- Added `hosting_get-deployment` — Get deployment status, build status, build logs and failure analysis
+- Hid 24 operations from search (they still run through `execute`): `hosting_import-wordpress-website`, `hosting_deploy-wordpress-plugin`, `hosting_deploy-wordpress-theme`, `hosting_deploy-js-application`, `hosting_deploy-static-website`, `hosting_list-js-deployments`, `hosting_show-js-deployment-logs`, `hosting_files_generate-upload-url`, `hosting_git_auto-deployment-settings`, `hosting_git_update-auto-deployment-settings`, `hosting_git_list-installations`, `hosting_git_list-installation-repositories`, `hosting_nodejs_list-builds`, `hosting_nodejs_start-build`, `hosting_nodejs_build-settings`, `hosting_nodejs_update-build-settings`, `hosting_nodejs_build-settings-from-archive`, `hosting_nodejs_analyse-failed-build`, `hosting_nodejs_build`, `hosting_nodejs_build-logs`, `hosting_websites_deploy-static-site-archive`, `wordpress_installations_import-website`, `wordpress_plugins_deploy`, `wordpress_themes_deploy`
+
+### Also in this release
+
+- Documentation: `README.md`
+- Dependencies: `package-lock.json`, `package.json`
+- Bundled agent skills: 6 files
+- Request handling and authentication: 4 files
+- Server instructions: 4 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+- Server entry points: `src/servers/agency-hosting.js`, `src/servers/agency-hosting.ts`
+- Build and packaging: `types.d.ts`
+
+## v3.1.0 — 2026-10-16
+
+### Operations
+
+- Changed the description and input schema of `ecommerce_products_update`
+- Changed the input schema of `ecommerce_products_create-physical`
+- Changed the description and input schema of `ecommerce_product-variants_update-in-batch`
+
+### Also in this release
+
+- Documentation: `README.md`
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Build and packaging: `types.d.ts`
+
 ## v3.0.0 — 2026-10-15
 
 ### Operations

package/README.md

@@ -69,7 +69,7 @@ pnpm update -g @hostinger/mcp
 
 This package installs the following MCP server commands:
 
-- `hostinger-api-mcp` — unified server over every operation (421 total)
+- `hostinger-api-mcp` — unified server over every operation (399 total)
 - `hostinger-agency-hosting-mcp` — 42 operations for agency-hosting
 - `hostinger-agent-readiness-mcp` — 3 operations for agent-readiness
 - `hostinger-billing-mcp` — 9 operations for billing
@@ -77,7 +77,7 @@ This package installs the following MCP server commands:
 - `hostinger-domains-mcp` — 42 operations for domains
 - `hostinger-ecommerce-mcp` — 29 operations for ecommerce
 - `hostinger-horizons-mcp` — 6 operations for horizons
-- `hostinger-hosting-mcp` — 81 operations for hosting
+- `hostinger-hosting-mcp` — 62 operations for hosting
 - `hostinger-mail-mcp` — 38 operations for mail
 - `hostinger-reach-mcp` — 56 operations for reach
 - `hostinger-vps-mcp` — 67 operations for vps
@@ -229,7 +229,9 @@ Every server exposes three tools:
 
 ## Operations
 
-The operations reachable through `execute`, by binary:
+The operations `search` offers, by binary:
+
+Operations that newer tools replace are hidden from `search`, and not documented, in every binary that also offers the replacing tool. They keep working through `execute` until they are removed.
 
 ### `hostinger-agency-hosting-mcp`
 
@@ -1554,9 +1556,11 @@ subscribers is archived instead of deleted so its data stays available.
 
 #### ecommerce_products_update
 
-Update a product's name, description or status. Set status to published to make it buyable,
-draft to hide it, or archived to retire it. Variants, prices and inventory are managed
-through the variant endpoints, not here. Returns the updated product summary.
+Update a product's name, description, status, SEO settings or collections. Set status to
+published to make it buyable, draft to hide it, or archived to retire it. SEO settings (title,
+description, slug) left out keep their values. collection_changes adds or removes collections
+without touching the others. Variants, prices and inventory are managed through the variant
+endpoints, not here. Returns the updated product summary.
 
 - **Method**: `PATCH`
 - **Path**: `/api/ecommerce/v1/stores/{store_id}/products/{product_id}`
@@ -1662,8 +1666,8 @@ plus its default currency. Useful to verify prerequisites before building a stor
 
 #### ecommerce_product-variants_update-in-batch
 
-Update up to 100 existing variants in place by id — title, inventory, stock tracking and
-prices. Variants omitted from the request are left untouched. Prices replace the variant's
+Update up to 100 existing variants in place by id — title, SKU, inventory, stock tracking
+and prices. Variants omitted from the request are left untouched. Prices replace the variant's
 existing prices in full. Returns the updated variants.
 
 - **Method**: `PATCH`
@@ -1810,51 +1814,16 @@ interface in the provided website URL.
 
 ### `hostinger-hosting-mcp`
 
-#### hosting_import-wordpress-website
-
-Import a WordPress website from an archive file to a hosting server. This tool uploads a website archive (zip, tar, tar.gz, etc.) and a database dump (.sql file) to deploy a complete WordPress website. The archive will be extracted on the server automatically. Note: This process may take a while for larger sites. After upload completion, files are being extracted and the site will be available in a few minutes. Upload credentials are generated and used internally — do not call a separate upload-url endpoint or upload the files yourself, this tool does it end-to-end. The username will be automatically resolved from the domain.
-
-- **Method**: `custom`
-- **Path**: `custom`
-
-#### hosting_deploy-wordpress-plugin
-
-Deploy a WordPress plugin from a directory to a hosting server. This tool uploads all plugin files and triggers plugin deployment. Upload credentials are generated and used internally — do not call a separate upload-url endpoint or upload the files yourself, this tool does it end-to-end.
-
-- **Method**: `custom`
-- **Path**: `custom`
-
-#### hosting_deploy-wordpress-theme
+#### hosting_deploy
 
-Deploy a WordPress theme from a directory to a hosting server. This tool uploads all theme files and triggers theme deployment. The uploaded theme can optionally be activated after deployment. Upload credentials are generated and used internally — do not call a separate upload-url endpoint or upload the files yourself, this tool does it end-to-end.
+Deploy, publish or upload a website to Hostinger web hosting (Shared, Cloud): static HTML, PHP, a nodejs (Node.js) app, a whole WordPress site, or a WordPress plugin or theme, from a local directory, an archive or a GitHub or GitLab repository. It detects what the project is and does the upload, build and Git setup itself: do not call upload or build operations, and do not archive the directory yourself. WARNING: it overwrites the website's contents and cannot be undone; confirm the domain with the user before deploying to a site that already has content. A Node.js build runs on the server: this returns a buildUuid at once, then call hosting_get-deployment until the build state is completed or failed. Static, PHP, plugin and theme deploys are done when this returns; a WordPress site import only starts, and its files are extracted a few minutes later. From Git, pass type (static or nodejs) unless the site already runs a Node.js app or you pass Node.js settings; a static or PHP site deploys the branch now and again on every push; a Node.js site builds the branch now and on every later push, with the settings stored for the site (when none are stored, pass appType and nodeVersion from the project's engines, plus outputDirectory and buildScript if the app has a build step). Git needs GitHub or GitLab connected once in hPanel.
 
 - **Method**: `custom`
 - **Path**: `custom`
 
-#### hosting_deploy-js-application
+#### hosting_get-deployment
 
-Deploy a JavaScript application from an archive file to a hosting server. IMPORTANT: the archive must ONLY contain application source files, not the build output, skip node_modules directory; also exclude all files matched by .gitignore if the ignore file exists. The build process will be triggered automatically on the server after the archive is uploaded. Upload credentials are generated and used internally — do not call a separate upload-url endpoint or upload the archive yourself, this tool does it end-to-end. After deployment, use the hosting_list-js-deployments tool to check deployment status and track build progress.
-
-- **Method**: `custom`
-- **Path**: `custom`
-
-#### hosting_deploy-static-website
-
-Deploy a static website from an archive file to a hosting server. IMPORTANT: This tool only works for static websites with no build process. The archive must contain pre-built static files (HTML, CSS, JavaScript, images, etc.) ready to be served. If the website has a package.json file or requires a build command, use hosting_deploy-js-application instead. The tool uploads the archive to the website's file browser over TUS and triggers deployment; the archive is extracted and deployed directly without any build steps. Upload credentials are generated and used internally — do not call a separate upload-url endpoint or upload the archive yourself, this tool does it end-to-end. The username will be automatically resolved from the domain.
-
-- **Method**: `custom`
-- **Path**: `custom`
-
-#### hosting_list-js-deployments
-
-List javascript application deployments for checking their status. Use this tool when customer asks for the status of the deployment. This tool retrieves a paginated list of Node.js application deployments for a domain with optional filtering by deployment states.
-
-- **Method**: `custom`
-- **Path**: `custom`
-
-#### hosting_show-js-deployment-logs
-
-Retrieve logs for a specified JavaScript application deployment for debugging purposes in case of failure.
+Check deployment status, build status, build logs and why a build failed (failure analysis) for a website's nodejs (Node.js) deployment: the state of its latest build (or of buildUuid), the end of the build log, the failure analysis when the build failed, and the build settings and Git auto-deployment settings stored for the site. Use it after hosting_deploy starts a Node.js build, and to find out why a deployment failed. Poll until the build state is completed or failed, with growing pauses. The log comes back in full; pass fromLine (the lines count from the previous call) to read only new output. A website without Node.js builds returns build: null with an explanation, because static, PHP, plugin and theme deploys are complete when hosting_deploy returns, and a WordPress site import is ready a few minutes after it starts.
 
 - **Method**: `custom`
 - **Path**: `custom`
@@ -2133,53 +2102,6 @@ Skip this verification when using Hostinger's free subdomains (*.hostingersite.c
 - **Method**: `POST`
 - **Path**: `/api/hosting/v1/domains/verify-ownership`
 
-#### hosting_files_generate-upload-url
-
-Generate a file browser upload URL with authentication credentials
-for uploading files directly to a website's file storage.
-
-While the website is still being set up (`status: running` on the list website setups
-endpoint) this endpoint returns 409 with a `Retry-After` header: wait that many
-seconds and retry, or poll the website setups until the status is `completed`.
-
-Returns `url`, `auth_key` and `rest_auth_key`. Use these to upload a file to the
-website's `public_html` directory via the TUS resumable upload protocol (TUS 1.0.0).
-Send `X-Auth: {auth_key}` and `X-Auth-Rest: {rest_auth_key}` headers on every request
-below.
-
-1. Create the upload: `POST` to `{url}/{relative_file_path}?override=true` with headers
-   `upload-length: {file size in bytes}` and `upload-offset: 0`. Expect `201 Created`.
-2. Upload the file: send the file bytes to the same location (any TUS 1.0.0 client, or
-   `PATCH` requests with an `upload-offset` header tracking progress) until complete.
-
-`relative_file_path` is the destination path inside `public_html`, e.g. `app.zip`.
-
-Instead of a TUS client, plain `curl` also works:
-```
-FILE=app.zip
-SIZE=$(stat -f%z "$FILE")   # stat -c%s on Linux
-
-curl -i -X POST "{url}/${FILE}?override=true" \
-  -H "X-Auth: {auth_key}" \
-  -H "X-Auth-Rest: {rest_auth_key}" \
-  -H "Tus-Resumable: 1.0.0" \
-  -H "Upload-Length: ${SIZE}" \
-  -H "Upload-Offset: 0"
-# -> 201 Created
-
-curl -i -X PATCH "{url}/${FILE}?override=true" \
-  -H "X-Auth: {auth_key}" \
-  -H "X-Auth-Rest: {rest_auth_key}" \
-  -H "Tus-Resumable: 1.0.0" \
-  -H "Content-Type: application/offset+octet-stream" \
-  -H "Upload-Offset: 0" \
-  --data-binary "@${FILE}"
-# -> 204 No Content, Upload-Offset response header equals SIZE when done
-```
-
-- **Method**: `POST`
-- **Path**: `/api/hosting/v1/files/upload-urls`
-
 #### hosting_files_list-website-and-directories
 
 List files and directories under a website's document root.
@@ -2200,35 +2122,6 @@ containing secrets (e.g. credential files) — none of these are returned by thi
 - **Method**: `GET`
 - **Path**: `/api/hosting/v1/accounts/{username}/domains/{domain}/files/content`
 
-#### hosting_git_auto-deployment-settings
-
-Returns the Git auto-deployment settings of the website: which repository and branch deploy
-into which directory, and whether pushes trigger a deployment. `is_enabled` false keeps the
-repository link but ignores pushes.
-
-When the website has no auto-deployment configured every field is null. Save settings with
-`Update Git auto-deployment settings`.
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/git/auto-deployments/settings`
-
-#### hosting_git_update-auto-deployment-settings
-
-Creates or replaces the Git auto-deployment settings of the website: repository, branch, the
-directory under the document root to deploy into, and `is_enabled`. Send the full set;
-`is_enabled` defaults to true and `directory` to the document root. `installation_uuid` must
-be an installation from `List Git installations` that belongs to the same customer as the
-website.
-
-For PHP and static websites, saving with `is_enabled` true deploys the branch right away and
-every later push to that branch deploys again. For Node.js and Website Builder websites saving
-does not clone anything. On a Node.js website start the first deploy with
-`Start Node.js build` using `source_type` `git`; pushes then trigger new builds with the build
-settings stored for the website.
-
-- **Method**: `PUT`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/git/auto-deployments/settings`
-
 #### hosting_git_delete-auto-deployment-settings
 
 Removes the Git auto-deployment settings of the website. Files already deployed stay on the
@@ -2238,39 +2131,6 @@ configured.
 - **Method**: `DELETE`
 - **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/git/auto-deployments/settings`
 
-#### hosting_git_list-installations
-
-Lists the Git provider accounts the customer has connected. Only installations with status
-`active` are returned unless the `status` filter says otherwise.
-
-An empty list means the customer has no active installation. Check `status=suspended` and
-`status=pending` as well. If there is none at all, a Git provider (GitHub or GitLab) has to be
-connected once in hPanel (Websites, Manage, Advanced, Git; or Add Website, Node.js Web App,
-Import Git Repository); this endpoint then lists the new installation.
-
-Use `uuid` as the path parameter of `List Git installation repositories`, and as
-`installation_uuid` in `Start Node.js build` with `source_type` `git` and in
-`Update Git auto-deployment settings`.
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/git/installations`
-
-#### hosting_git_list-installation-repositories
-
-Lists the repositories the Git installation can access, read live from the provider. Works
-for github and gitlab installations. Use an active installation: a suspended or pending one
-is still queried and the call fails with whatever the provider answers. The list is cut at
-the first 500 repositories in the order the provider returns them; when the account has
-more, name the repository directly instead of searching this list.
-
-`owner`, `name` and a branch (`default_branch` or another one) go into `source_options` of
-`Start Node.js build` or into `Update Git auto-deployment settings`. Returns 404 when the
-installation does not belong to the customer. Limited to 10 calls per minute per API client
-(429 above that).
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/git/installations/{uuid}/repositories`
-
 #### hosting_git_deploy-website-repository
 
 Clones a Git repository into a directory of the website, or pulls it again. An empty or missing
@@ -2332,84 +2192,6 @@ to it.
 - **Method**: `POST`
 - **Path**: `/api/hosting/v1/headless/agent-reports`
 
-#### hosting_nodejs_list-builds
-
-Retrieve a paginated list of Node.js build processes for a specific website.
-
-Each build represents a single run of the Node.js build pipeline. Use the `states`
-query parameter to filter results by build state (pending, running, completed, failed).
-Use the `uuid` from a build to poll its output via the `Get Node.js Build Logs` endpoint.
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/nodejs/builds`
-
-#### hosting_nodejs_start-build
-
-Start a Node.js build process using files already present on the website's file storage.
-
-WARNING: on success this overwrites the website's existing contents and cannot be
-undone — verify this is intended before calling this endpoint.
-
-With `source_type` `archive`, `source_options.archive_path` must point to an existing
-archive file on the server (relative to the website document root). Use the
-`Generate Upload URL` endpoint to obtain credentials and upload the archive first. To
-auto-detect build settings from an archive before starting, first call the
-`Get Node.js Build Settings from Archive` endpoint.
-
-With `source_type` `git`, `source_options` carries `owner`, `repository`, `branch` and
-`installation_uuid`. Take the installation from `List Git installations` and the owner and
-repository from `List Git installation repositories`; the branch is cloned at its current
-head. The installation must belong to the same customer as the website.
-
-The returned build `uuid` can be used to poll progress and retrieve logs via
-the `Get Node.js Build Logs` endpoint.
-
-- **Method**: `POST`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/nodejs/builds`
-
-#### hosting_nodejs_build-settings
-
-Returns the build settings stored for the website: framework (`app_type`), Node.js version,
-root and output directory, build script, entry file and package manager. Stored settings
-drive Git auto-deployment builds. A build started through the API uses the values sent in
-that request and saves them here only when no settings exist yet.
-
-Returns 404 until the first build or the first settings update stores them. Use this after
-a failed build to check whether the framework or the entry file were detected wrong, then
-fix them with the `Update Node.js build settings` endpoint.
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/nodejs/builds/settings`
-
-#### hosting_nodejs_update-build-settings
-
-Replaces the build settings stored for the website. Send the full set: `node_version` is
-required and every nullable field you omit is stored as null. Creates the settings when
-none exist yet.
-
-This does not start a build. Stored settings drive Git auto-deployment builds; a build
-started through the API uses the values sent in that request, so to rebuild with corrected
-settings call `Start Node.js build` with the same values. Typical fixes: a wrong `app_type`
-after auto-detection, or a missing `entry_file` for express, fastify, nest, nuxt and hono
-apps.
-
-- **Method**: `PUT`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/nodejs/builds/settings`
-
-#### hosting_nodejs_build-settings-from-archive
-
-Auto-detect Node.js build settings from a package.json inside an archive already on the server.
-
-Use this before calling `Start Node.js Build` to preview what settings will be used,
-or to let the user review and override values (framework, node version, root directory,
-output directory, build script) before committing to a build.
-
-The archive must already be present on the website's file storage. Use the
-`Generate Upload URL` endpoint to obtain credentials and upload the archive first.
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/nodejs/builds/settings/from-archive`
-
 #### hosting_nodejs_list-environment-variables
 
 Lists the Node.js environment variables currently set for the website. Values are always
@@ -2444,41 +2226,6 @@ values taken from the project `.env` file or the user prompt.
 - **Method**: `PUT`
 - **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/nodejs/builds/settings/env`
 
-#### hosting_nodejs_analyse-failed-build
-
-Returns an AI analysis of why a build failed and how to fix it, based on the build logs,
-the project file list and package.json. Only builds in the `failed` state can be analysed;
-any other state returns 422. When no analysis could be produced both `analysis` and
-`solution` are null, in which case read `Get NodeJS build logs` instead.
-
-Each call runs the analysis again, so call it once per failed build and keep the result.
-Limited to 5 calls per minute per API client (429 above that).
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/nodejs/builds/{uuid}/analysis`
-
-#### hosting_nodejs_build
-
-Returns one build by UUID: its state (`pending`, `running`, `completed`, `failed`), the
-options it ran with and timestamps. Poll this while a build is pending or running. When it
-is failed, read `Get NodeJS build logs` and `Analyse failed Node.js build` for the cause.
-Returns 404 when the UUID does not belong to a build of this website.
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/nodejs/builds/{uuid}`
-
-#### hosting_nodejs_build-logs
-
-Retrieve logs from a specific Node.js build process.
-
-To stream live output while a build is running, poll this endpoint repeatedly
-while the build state is `running`, passing the previously returned `lines` count
-as `from_line` to fetch only new output since the last call.
-Log content may contain ANSI escape sequences (color codes).
-
-- **Method**: `GET`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/nodejs/builds/{uuid}/logs`
-
 #### hosting_nodejs_runtime-logs
 
 Returns the Node.js application's runtime console log entries, oldest first, each with
@@ -2817,24 +2564,6 @@ completed` before uploading files, deploying or creating databases. While the se
 - **Method**: `POST`
 - **Path**: `/api/hosting/v1/websites`
 
-#### hosting_websites_deploy-static-site-archive
-
-Deploy a static application from an archive file.
-
-WARNING: this overwrites the website's existing contents and cannot be undone —
-verify this is intended before calling this endpoint.
-
-This endpoint allows you to deploy a static application from an archive
-file that has been uploaded to the website's directory.
-
-This only works for static sites (pre-built HTML/CSS/JS with no build step). For
-Node.js applications, use `Create NodeJS build from archive` instead, or
-`Start Node.js build` if the archive is already uploaded. For WordPress sites,
-use `Import WordPress website`.
-
-- **Method**: `POST`
-- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/deploy`
-
 #### hosting_websites_delete
 
 This endpoint permanently removes a website and all of its data. This action

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.0.0",
+  "version": "3.2.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/mcp",
-  "version": "3.0.0",
+  "version": "3.2.0",
   "mcpName": "io.github.hostinger/hostinger-api-mcp",
   "description": "MCP server for Hostinger API",
   "repository": {
@@ -44,6 +44,7 @@
     "cors": "^2.8.5",
     "dotenv": "^18.0.1",
     "express": "^5.2.1",
+    "fflate": "^0.8.3",
     "minimist": "^1.2.8",
     "tus-js-client": "^4.1.0",
     "zod": "^4.1.0"

package/server.json

@@ -6,12 +6,12 @@
     "url": "https://github.com/hostinger/api-mcp-server",
     "source": "github"
   },
-  "version": "3.0.0",
+  "version": "3.2.0",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "3.0.0",
+      "version": "3.2.0",
       "transport": {
         "type": "stdio"
       },

package/skills/audit-hosting/SKILL.md

@@ -30,7 +30,7 @@ Tell the user the size (plans, websites, WordPress installs) before the checks.
 Per Shared and Cloud website (skip `builder` and `horizons`):
 
 - `hosting_ssl_status` — flag `failed` (with `last_error`), `expired`, `not_installed` on a custom domain, `is_https_redirect_enabled: false`, and `expires_at` within 30 days when `is_lifetime` is false. Lifetime certificates renew on their own.
-- Node.js sites: `hosting_nodejs_list-builds` with `per_page: 1` (latest build failed?) and `hosting_nodejs_list-vulnerabilities` with `severities: ["critical", "high"]`.
+- Node.js sites: `hosting_get-deployment` (latest build failed? `build.state`; on the hosted server use `hosting_nodejs_list-builds` with `per_page: 1`) and `hosting_nodejs_list-vulnerabilities` with `severities: ["critical", "high"]`.
 
 Per hosting account (`username`): `hosting_databases_list` — flag `disk_usage_mb` above 80% of `max_size_mb`.
 

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

@@ -24,27 +24,30 @@ Ship a project that already exists — on disk or in a Git repository — to a H
 
 ## 2. Choose the deploy
 
-Wrong method is the most common failure. Decide from the project on disk:
+**Shared and Cloud, on the local `hostinger-api-mcp` server:** one operation does every deploy — `hosting_deploy` with `domain` and either `path` (a directory on this machine) or `git: { repository: "owner/name", branch }`. Given a directory it detects what the project is, packs it itself (it skips `node_modules`, `.git` and `.env` files, listing the `.env` ones as `skippedFiles` so you can set their values with `hosting_nodejs_replace-environment-variables`; it does not read `.gitignore`, so keep build output out of the directory) and does the upload, build and Git setup. Do not archive the directory or call upload and build operations by hand.
 
-| Project | Shared / Cloud |
+| Project | `hosting_deploy` treats it as |
 | --- | --- |
-| Plain HTML/CSS/JS, or a framework's static build output | `hosting_deploy-static-website` |
-| `package.json` with a build or a server (Next.js, Nuxt, Express, Vite…) | `hosting_deploy-js-application` |
-| PHP code, no build step | `hosting_deploy-static-website` (extracts the archive as-is) |
-| WordPress plugin or theme folder | `hosting_deploy-wordpress-plugin` / `hosting_deploy-wordpress-theme` (`activate` optional) |
-| A whole WordPress site from elsewhere | the `migrate-to-hosting` skill |
+| Plain HTML/CSS/JS, or a framework's static build output | `static` — extracts as-is |
+| `package.json` with a build script, a start script or a server dependency (Next.js, Nuxt, Express, Vite…) | `nodejs` — starts a build, returns `buildUuid` |
+| PHP code, no build step | `static` |
+| WordPress plugin folder (a `Plugin Name:` header) or theme folder (`Theme Name:` in `style.css`) | `wordpress-plugin` / `wordpress-theme`; `activate: true` activates a theme |
+| A whole WordPress site from elsewhere | `wordpress-site`, with `databaseDump` — see the `migrate-to-hosting` skill |
 
-On Agency the website's type decides (`agency-hosting_websites_get`): sites created as `node-static` take `agency-hosting_deploy-node-static-website`, which runs the build when the project has one; every other site takes `agency-hosting_deploy-php-application`, which extracts the archive as-is. WordPress plugins and themes on Agency sites are installed from wp-admin.
+- Pass `type` to override detection. It is required for an archive (an archive cannot be inspected) and when a directory matches more than one WordPress type, which `hosting_deploy` rejects as ambiguous.
+- Node.js build settings come from the project; detection covers the framework and the build script. Set `appType`, `outputDirectory`, `buildScript`, `entryFile`, `nodeVersion` (default 22), `rootDirectory` or `packageManager` when it is wrong. A TypeScript or other compiled server app always needs `entryFile` set to the built file (for example `dist/server.js`): detection only guesses a root-level file, and the build fails with "Entry file not found". The entry file is relative to the root directory for express, fastify, hono, react-router and other, and to the output directory for nest, nuxt, nitro, astro and svelte-kit (`main.js`, not `dist/main.js`); Next.js ignores it. Per-framework values are in the Hostinger docs under Node.js (Supported Frameworks, Build Settings).
+- Static, PHP, plugin and theme deploys are live when the call returns. A WordPress site import only starts (`status: import_started`) and finishes extracting a few minutes later; do not report it complete or verify it before then. Node.js builds run on the server: see step 3.
 
-Archive rules (name archives `name_YYYYMMDD_HHMMSS.zip`):
+**Agency:** the website's type decides (`agency-hosting_websites_get`): sites created as `node-static` take `agency-hosting_deploy-node-static-website`, which runs the build when the project has one; every other site takes `agency-hosting_deploy-php-application`, which extracts the archive as-is. They deploy archives, synchronously: the site is live when the call returns. WordPress plugins and themes on Agency sites are installed from wp-admin.
+
+Archive rules for Agency (name archives `name_YYYYMMDD_HHMMSS.zip`) and for archives you build yourself:
 
 - **Static:** build locally first. `index.html` must be at the archive root, not inside a folder: `cd dist && zip -r ../site_20260101_120000.zip .`
 - **Node.js source:** no `node_modules/`, no build output (`dist/`, `.next/`, `build/`), no `.env*`, nothing matched by `.gitignore`; 50 MB at most. `git archive --format=zip -o app_20260101_120000.zip HEAD` produces exactly the committed files — mention that uncommitted changes are left out.
-- Agency deploys are synchronous: the site is live when the call returns.
 
-The operations in the table read the archive from this machine, so only the local `hostinger-api-mcp` server has them. On the hosted server (`mcp.hostinger.com`) `search` does not find them — upload the files yourself as below.
+`hosting_deploy` and the `agency-hosting_deploy-*` operations read files from this machine, so only the local server has them. On the hosted server (`mcp.hostinger.com`) `search` does not find them — upload the files yourself as below.
 
-### Without the local deploy operations
+### Without the local deploy operations (hosted server; on the local server only for Agency)
 
 1. Get upload credentials: `hosting_files_generate-upload-url` (`username`, `domain`); Agency: `agency-hosting_files_generate-upload-url` (`website_uid`). Both return `url`, `auth_key` and `rest_auth_key`, which authenticate the upload instead of the API token.
 2. Upload each file with TUS, where `DEST` is its path in the website's storage:
@@ -69,15 +72,29 @@ curl -sS -X PATCH "$URL/$DEST?override=true" -H "X-Auth: $AUTH_KEY" -H "X-Auth-R
 
 ## 3. Node.js builds
 
-`hosting_deploy-js-application` uploads the archive to the document root, detects settings from `package.json` and starts a build. Track it with `hosting_nodejs_list-builds` and `hosting_nodejs_build` (by `uuid`), polling every 10–20 s — builds take minutes.
+`hosting_deploy` returns a `buildUuid` at once; the build runs on the server and takes minutes. Track it with `hosting_get-deployment` (`domain`, optionally `buildUuid`; the latest build by default), polling every 10–20 s until `build.state` is `completed` or `failed`. It returns the build, its log and the stored build settings; pass the previous `logs.lines` as `fromLine` to read only new output.
+
+- Failed build: the response already carries `analysis` (fetched once per build; the API allows 5 a minute).
+- Wrong detection (framework, `output_directory`, or an entry file inside the build output, such as `dist/server.js` for a compiled app): deploy again with `appType`, `outputDirectory`, `buildScript` or `entryFile` set. An archive deploy sends its settings with the request and leaves the stored ones alone; a Git deploy also stores these values, so later pushes build with them.
+
+On the hosted server, which has no `hosting_deploy` or `hosting_get-deployment`:
 
+- After the upload steps below, start the build and track it with `hosting_nodejs_list-builds` and `hosting_nodejs_build` (by `uuid`), polling every 10–20 s.
 - Failed build: `hosting_nodejs_analyse-failed-build` once per build (5 calls a minute), then `hosting_nodejs_build-logs` if the analysis is empty.
-- Wrong detection (framework, `output_directory`, or a missing `entry_file` for express, fastify, nest, nuxt and hono): run `hosting_nodejs_start-build` with explicit values, `source_type: "archive"` and `source_options.archive_path` set to the archive's file name in the document root (check it is there with `hosting_files_list-website-and-directories`). Store the same values with `hosting_nodejs_update-build-settings`.
+- Wrong detection: run `hosting_nodejs_start-build` with explicit values, `source_type: "archive"` and `source_options.archive_path` set to the archive's file name in the document root (check it is there with `hosting_files_list-website-and-directories`). Store the same values with `hosting_nodejs_update-build-settings`.
 - To review detected settings before any build: upload the archive with `hosting_files_generate-upload-url` (the TUS steps are in its description), then `hosting_nodejs_build-settings-from-archive`.
 
 ## 4. Auto-deploy from Git
 
-1. `hosting_git_list-installations`. With no `active` installation (check `status: "pending"` and `"suspended"` too), the user connects GitHub or GitLab once in hPanel under Websites → Manage → Advanced → Git; there is no API for that step.
+On the local server, `hosting_deploy` with `git: { repository: "owner/name", branch }` does all of it: it finds the Git installation that can reach the repository and deploys it as the `type` you give. Always pass `type: "static"` or `"nodejs"` unless the site already runs a Node.js app (or you pass Node.js settings such as `appType`): a new site is not detected as Node.js, and a Node.js repository deployed as static would publish its source. Then:
+- **PHP and static sites:** saves the auto-deployment settings, which deploys the branch immediately and again on every push;
+- **Node.js sites:** starts a build of the branch with the stored build settings; later pushes build the same way. A Git deploy has nothing to detect from, so when none are stored pass `appType` and `nodeVersion` (from `engines` in `package.json`), plus `outputDirectory` and `buildScript` if the app has a build step; they are stored for those pushes.
+
+With no active installation it stops and says so: the user connects GitHub or GitLab once in hPanel under Websites → Manage → Advanced → Git; there is no API for that step. Confirm with `hosting_get-deployment`, which returns the stored `gitAutoDeployment`.
+
+On the hosted server, by hand:
+
+1. `hosting_git_list-installations`. With no `active` installation (check `status: "pending"` and `"suspended"` too), the user connects GitHub or GitLab once in hPanel, as above.
 2. `hosting_git_list-installation-repositories` with the installation `uuid` gives `owner`, `name` and `default_branch` (10 calls a minute).
 3. `hosting_git_update-auto-deployment-settings` with `installation_uuid`, `owner`, `repository`, `branch` and optional `directory`.
    - PHP and static sites deploy the branch immediately and again on every push.

package/skills/headless/references/DATABASE.md

@@ -29,8 +29,8 @@ Do not put the remote `host` into the deployed app — it has no grant for conne
 | You called | Poll this until | Typical wait |
 | --- | --- | --- |
 | `hosting_websites_create` | `hosting_websites_list-setups` with the domain reports `status: completed` | up to a few minutes |
-| `hosting_deploy-js-application` | `hosting_list-js-deployments` shows the build finished | minutes |
-| `hosting_nodejs_start-build` | `hosting_nodejs_build` state is `completed` or `failed` | minutes |
+| `hosting_deploy` of a Node.js app | `hosting_get-deployment` reports a `completed` or `failed` build | minutes |
+| `hosting_nodejs_start-build` (hosted server, which has no `hosting_deploy`) | `hosting_nodejs_build` state is `completed` or `failed` | minutes |
 | `wordpress_installations_install`, plugin/theme/core jobs | `wordpress_installations_list` lists the install | 1–2 minutes |
 | `hosting_databases_repair`, `hosting_websites_delete` | nothing to poll — runs in the background | minutes |
 | `agency-hosting_website-setups_create` | `agency-hosting_website-setups_status` with `setup_uuid` is `completed` | minutes |
@@ -39,7 +39,7 @@ Poll with backoff (a few seconds, then tens of seconds). A queued response is no
 
 ## 5. When the app is up but broken
 
-- Build failed: `hosting_nodejs_build-logs` for the raw log, `hosting_nodejs_analyse-failed-build` for a diagnosis.
+- Build failed: `hosting_get-deployment` returns the logs and a diagnosis together (hosted server: `hosting_nodejs_build-logs` for the raw log, `hosting_nodejs_analyse-failed-build` for a diagnosis).
 - Build passed, app errors: `hosting_nodejs_runtime-logs` with a `period` such as `1h`; entries before `last_deployed_at` belong to the previous deploy.
 - `Access denied for user 'x'@'::1'`: the app used `localhost` from Node.js — set `DB_HOST` to `127.0.0.1`.
 - PHP limits (memory, upload size): `hosting_php_get`, then `hosting_php_update-options`.