@hostinger/mcp 3.0.0 → 3.2.0

package/skills/headless/references/DEPLOYMENT.md

@@ -2,27 +2,25 @@
 
 Match the deploy method to what the project actually is — this is the single most common failure point.
 
-The deploy operations below 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 and deploy from the upload as described in the `deploy-to-hosting` skill ("Without the local deploy operations"). Agency Plan sites deploy through the Agency operations listed there as well.
+On the local `hostinger-api-mcp` server one operation does every deploy: `hosting_deploy` with `domain` and `path` (the project directory; it detects the type, packs the files itself; it skips `node_modules`, `.git` and `.env` files, reporting the `.env` ones as `skippedFiles` (set their values with `hosting_nodejs_replace-environment-variables`); it does not read `.gitignore`, so keep build output out of the directory) or `git: { repository, branch }` with `type: "static"` or `"nodejs"` (a new site is not yet detected as Node.js). It reads files from this machine, so the hosted server (`mcp.hostinger.com`) does not have it: there, upload the files and deploy from the upload as described in the `deploy-to-hosting` skill ("Without the local deploy operations"). Agency Plan sites deploy through the Agency operations listed there as well.
 
-## Static site → `hosting_deploy-static-website`
+## Static site → `hosting_deploy` (detected as `static`)
 
-For pre-built files only: plain HTML/CSS/JS, or the **build output** of a framework (run the build locally first).
+For pre-built files only: plain HTML/CSS/JS, or the **build output** of a framework (run the build locally first, then pass the output directory as `path`).
 
-- The archive (zip/tar) must have `index.html` at its **root** — not nested inside a folder.
-- Name it `name_YYYYMMDD_HHMMSS.zip`; pass `removeArchive: true` to clean up after upload.
+- `index.html` must be at the **root** of that directory — not nested inside a folder.
 - Deployment is effectively immediate — verify right after.
 
-## Node.js app → `hosting_deploy-js-application`
+## Node.js app → `hosting_deploy` (detected as `nodejs`)
 
-For anything that needs a server or a server-side build (Express, Next.js, NestJS, SSR frameworks).
+For anything that needs a server or a server-side build (Express, Next.js, NestJS, SSR frameworks). Pass the project's **source** directory, not the output: the install and build run on Hostinger.
 
-- Archive the **source**, not the output: exclude `node_modules/`, `dist/`, `.next/`, `build/`, and everything matched by `.gitignore`. The install and build run on Hostinger.
-- Hard cap: **50 MB** archive.
-- The upload starts a build. Track it with `hosting_list-js-deployments`; on failure pull `hosting_show-js-deployment-logs`, fix, and redeploy. Poll with backoff — builds take minutes, not seconds.
+- The call returns a `buildUuid` and the build runs on the server. Track it with `hosting_get-deployment` (`domain`) until `build.state` is `completed` or `failed`; on failure the response carries the logs and an analysis — fix, and deploy again. Poll with backoff: builds take minutes, not seconds.
+- When the framework, output directory or entry file is detected wrong, pass `appType`, `outputDirectory`, `buildScript` or `entryFile` to `hosting_deploy`. A TypeScript or other compiled server app always needs `entryFile` set to the built file (for example `dist/server.js`).
 
-## WordPress → `hosting_import-wordpress-website` / plugin & theme operations
+## WordPress → `hosting_deploy` with `type: "wordpress-site"` / plugin & theme directories
 
-Only when the user explicitly wants a WordPress *site* migrated or themed. Site imports take an archive plus a `.sql` dump and can run for several minutes. (WordPress as a headless content backend behind an agent-built frontend is a different flow — that's `WORDPRESS.md`, installed fresh via the API, not imported here.)
+Only when the user explicitly wants a WordPress *site* migrated or themed. A site import takes the site directory plus `databaseDump` (a `.sql` file) and can run for several minutes; a plugin or theme directory is detected from its header (`activate: true` activates a theme). (WordPress as a headless content backend behind an agent-built frontend is a different flow — that's `WORDPRESS.md`, installed fresh via the API, not imported here.)
 
 ## Verify (every deploy)
 

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

@@ -41,11 +41,11 @@ Create the Hostinger website on the domain being migrated, not on a free subdoma
 
 ## 3. Import
 
-`hosting_import-wordpress-website`, `hosting_deploy-static-website` and `agency-hosting_deploy-php-application` read files from this machine and exist only in the local `hostinger-api-mcp` server. On the hosted server (`mcp.hostinger.com`), upload the files first as described in the `deploy-to-hosting` skill ("Without the local deploy operations") and use the operation named in brackets below.
+`hosting_deploy` and `agency-hosting_deploy-php-application` read files from this machine and exist only in the local `hostinger-api-mcp` server. On the hosted server (`mcp.hostinger.com`), upload the files first as described in the `deploy-to-hosting` skill ("Without the local deploy operations") and use the operation named in brackets below.
 
-**WordPress, Shared and Cloud:** `hosting_import-wordpress-website` with `domain`, `archivePath` and `databaseDump` uploads both, extracts the files and imports the database; large sites take several minutes. [Upload `site.zip` and `dump.sql`, then `wordpress_installations_import-website` with `archive_path` and `sql_path`.] Then `wordpress_installations_detect` with `username` and poll `wordpress_installations_list` with `domain` until the install appears with `is_valid: true`.
+**WordPress, Shared and Cloud:** `hosting_deploy` with `domain`, `path` (the site directory or its archive), `databaseDump` and `type: "wordpress-site"` uploads both, extracts the files and imports the database; large sites take several minutes. Always pass `type`: left to detection, a directory without `wp-config.php` or `wp-content` at its top level is taken for a plain site and the dump is not imported. [Upload `site.zip` and `dump.sql`, then `wordpress_installations_import-website` with `archive_path` and `sql_path`.] Then `wordpress_installations_detect` with `username` and poll `wordpress_installations_list` with `domain` until the install appears with `is_valid: true`.
 
-**Static, or PHP without a database:** `hosting_deploy-static-website` [upload, then `hosting_websites_deploy-static-site-archive`]; Agency: `agency-hosting_deploy-php-application` [upload to `.h5g/`, then `agency-hosting_files_import-website-from-archive`].
+**Static, or PHP without a database:** `hosting_deploy` with `domain` and `path` [upload, then `hosting_websites_deploy-static-site-archive`]; Agency: `agency-hosting_deploy-php-application` [upload to `.h5g/`, then `agency-hosting_files_import-website-from-archive`].
 
 **PHP with a database, Shared and Cloud:**
 

package/skills/troubleshoot-website/SKILL.md

@@ -44,9 +44,9 @@ dig +short NS DOMAIN; dig +short A DOMAIN; dig +short CAA DOMAIN
 
 ### Node.js (`nodejs`)
 
-Batch `hosting_nodejs_list-builds` (`per_page: 3`), `hosting_nodejs_runtime-logs` (`period: "1h"`, `levels: ["ERROR", "WARN"]`) and `hosting_nodejs_list-environment-variables` (keys only; values always come back masked).
+Batch `hosting_get-deployment` (the latest build with its log, failure analysis and stored settings), `hosting_nodejs_runtime-logs` (`period: "1h"`, `levels: ["ERROR", "WARN"]`) and `hosting_nodejs_list-environment-variables` (keys only; values always come back masked). On the hosted server, which has no `hosting_get-deployment`, use `hosting_nodejs_list-builds` (`per_page: 3`) in its place.
 
-- Latest build `failed`: call `hosting_nodejs_analyse-failed-build` once for that build — every call re-runs the analysis and the limit is 5 a minute. When it returns nulls, read `hosting_nodejs_build-logs`. A wrongly detected framework, output directory or missing `entry_file` is the usual cause: compare `hosting_nodejs_build-settings` with the project, rebuild with corrected values through `hosting_nodejs_start-build`, and store the same values with `hosting_nodejs_update-build-settings` so Git pushes build correctly too.
+- Latest build `failed`: `hosting_get-deployment` already holds the `analysis` (fetched once per build — the API re-runs it on every call and allows 5 a minute). A wrongly detected framework, output directory or missing `entry_file` is the usual cause: compare the returned `buildSettings` with the project and deploy again with corrected `appType`, `outputDirectory`, `buildScript` or `entryFile`; a Git deploy stores them, so pushes build correctly too. On the hosted server: `hosting_nodejs_analyse-failed-build` once for that build, then `hosting_nodejs_build-logs`; compare `hosting_nodejs_build-settings`, rebuild through `hosting_nodejs_start-build` and store the values with `hosting_nodejs_update-build-settings`.
 - Build `completed` but the app errors: read the runtime logs; entries older than `last_deployed_at` belong to the previous deploy. A variable the code reads but the key list lacks is fixed with the `deploy-to-hosting` skill's environment step. `Access denied for user '…'@'::1'` means the app connects to `localhost` — `DB_HOST` must be `127.0.0.1`.
 - Hung process: `hosting_nodejs_restart-application` (restarts without rebuilding).
 

package/src/core/catalog.js

@@ -2,6 +2,7 @@
 // multi-execute over a catalog of API operations. Pure functions only; the
 // runtime supplies the catalog and the function that performs a call.
 // Keep in sync with catalog.ts and with api-remote-mcp's PHP implementation.
+// `hidden` is stdio-only: the hosted server hides nothing, so the PHP side has no such flag.
 
 export const DEFAULT_SEARCH_LIMIT = 5;
 export const MAX_SEARCH_LIMIT = 20;
@@ -94,7 +95,10 @@ export function searchOperations(operations, query, limit = DEFAULT_SEARCH_LIMIT
         throw new ToolInputError(`limit must be an integer from 1 to ${MAX_SEARCH_LIMIT}`);
     }
 
+    // Hidden operations stay executable (findOperation does not look at the flag) but are
+    // never offered, so the model is steered to their replacement.
     return operations
+        .filter(op => !op.hidden)
         .map(op => {
             const name = op.name.toLowerCase();
             const group = (op.group ?? '').toLowerCase();

package/src/core/catalog.ts

@@ -1,5 +1,6 @@
 // Typed mirror of catalog.js. Keep both files, and api-remote-mcp's PHP
-// implementation, behaviourally identical.
+// implementation, behaviourally identical. `hidden` is stdio-only: the hosted server hides
+// nothing, so the PHP side has no such flag.
 
 export const DEFAULT_SEARCH_LIMIT = 5;
 export const MAX_SEARCH_LIMIT = 20;
@@ -12,6 +13,7 @@ export interface CatalogOperation {
   title?: string;
   description?: string;
   group?: string;
+  hidden?: boolean;
   annotations?: { readOnlyHint?: boolean; destructiveHint?: boolean; [key: string]: unknown };
   inputSchema: { type: 'object'; properties?: Record<string, unknown>; required?: string[]; [key: string]: unknown };
 }
@@ -113,7 +115,10 @@ export function searchOperations(operations: CatalogOperation[], query: unknown,
     throw new ToolInputError(`limit must be an integer from 1 to ${MAX_SEARCH_LIMIT}`);
   }
 
+  // Hidden operations stay executable (findOperation does not look at the flag) but are
+  // never offered, so the model is steered to their replacement.
   return operations
+    .filter(op => !op.hidden)
     .map(op => {
       const name = op.name.toLowerCase();
       const group = (op.group ?? '').toLowerCase();

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

@@ -0,0 +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- hosting_nodejs_start-build -> hosting_nodejs_build; logs via hosting_nodejs_build-logs; on failure hosting_nodejs_analyse-failed-build.\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";

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

@@ -0,0 +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- hosting_nodejs_start-build -> hosting_nodejs_build; logs via hosting_nodejs_build-logs; on failure hosting_nodejs_analyse-failed-build.\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 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- hosting_nodejs_start-build -> hosting_nodejs_build; logs via hosting_nodejs_build-logs; on failure hosting_nodejs_analyse-failed-build.\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- hosting_nodejs_start-build -> hosting_nodejs_build; logs via hosting_nodejs_build-logs; on failure hosting_nodejs_analyse-failed-build.\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 named above.\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- hosting_nodejs_start-build -> hosting_nodejs_build; logs via hosting_nodejs_build-logs; on failure hosting_nodejs_analyse-failed-build.\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- hosting_nodejs_start-build -> hosting_nodejs_build; logs via hosting_nodejs_build-logs; on failure hosting_nodejs_analyse-failed-build.\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 named above.\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;