@hostinger/mcp 3.1.0 → 3.2.1

package/src/servers/horizons.ts

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

package/src/servers/hosting.js

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

package/src/servers/hosting.ts

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

package/src/servers/mail.js

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

package/src/servers/mail.ts

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

package/src/servers/reach.js

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

package/src/servers/reach.ts

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

package/src/servers/vps.js

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

package/src/servers/vps.ts

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

package/src/servers/wordpress.js

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

package/src/servers/wordpress.ts

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

package/types.d.ts

@@ -4,6 +4,92 @@
  */
 
 export interface APITools {
+  /**
+   * 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.
+   */
+  "hosting_deploy": {
+    params: {
+      /**
+       * Domain name of the website to deploy to (e.g., example.com)
+       */
+      domain: string;
+      /**
+       * Local directory (preferred; it is archived for you, skipping node_modules, .git and .env files, but not reading .gitignore, so keep build output out) or archive (zip, tar, tar.gz, tgz, 7z, gz, gzip). Not together with git.
+       */
+      path?: string;
+      /**
+       * Deploy a repository branch instead of local files. Not together with path.
+       */
+      git?: object;
+      /**
+       * What is deployed. Detected for a directory (a Plugin Name: or Theme Name: header, wp-config.php or wp-content, a package.json with a build or start script); required for an archive, when detection reports ambiguity, and for a Git deploy unless the site already runs a Node.js app or Node.js settings are passed. static also covers PHP.
+       */
+      type?: string;
+      /**
+       * WordPress plugin or theme slug: lower-case letters, digits, - and _ (default: the directory name)
+       */
+      slug?: string;
+      /**
+       * Activate the theme after deployment (WordPress themes only, default: false)
+       */
+      activate?: boolean;
+      /**
+       * Path to a .sql dump; required for a WordPress site import
+       */
+      databaseDump?: string;
+      /**
+       * Node.js major version (default: detected from an archive, or stored for the site, else 22; set it from the project's engines for a Git deploy)
+       */
+      nodeVersion?: number;
+      /**
+       * Node.js framework, e.g. next, nuxt, vite, express, react, vue, astro; overrides detection or stored settings
+       */
+      appType?: string;
+      /**
+       * Directory with the package.json, relative to the site root (default .)
+       */
+      rootDirectory?: string;
+      /**
+       * Build output directory relative to the root directory, e.g. dist
+       */
+      outputDirectory?: string;
+      /**
+       * The package.json script that builds the app, e.g. build
+       */
+      buildScript?: string;
+      /**
+       * Entry file of a server app. Relative to the root directory for express, fastify, hono, react-router and other; for a compiled (TypeScript) app give the built file, e.g. dist/server.js, because detection guesses a root-level file. Relative to the output directory for nest, nuxt, nitro, astro and svelte-kit (main.js, not dist/main.js). Ignored for next.
+       */
+      entryFile?: string;
+      /**
+       * Package manager used to install dependencies
+       */
+      packageManager?: string;
+    };
+    response: any; // Response structure will depend on the API
+  };
+
+  /**
+   * 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.
+   */
+  "hosting_get-deployment": {
+    params: {
+      /**
+       * Domain name of the website (e.g., example.com)
+       */
+      domain: string;
+      /**
+       * Build to inspect, as returned by hosting_deploy (default: the latest build)
+       */
+      buildUuid?: string;
+      /**
+       * Read the build log from this line on (default 0, the whole log). Pass the lines count returned by the previous call to get only new output.
+       */
+      fromLine?: number;
+    };
+    response: any; // Response structure will depend on the API
+  };
+
   /**
    * Deploy a node-static Agency Plan (h5g) website from an archive file. WARNING: this overwrites the website's existing contents and cannot be undone — always confirm with the user before proceeding. Use this for Agency Plan websites of type node-static (a Node.js-built static site that requires a build step or a plain simple static site). The tool resolves the website from its domain, uploads the archive to the website's file browser over TUS, and triggers the build-assets process which builds the site and deploys the result to public_html. This operation is synchronous: the build and deployment complete before the tool returns, so the website is live as soon as the tool finishes successfully — there is no separate asynchronous build to wait for or poll. 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. For plain PHP applications that should be extracted as-is, use agency-hosting_deploy-php-application instead. The website UID is automatically resolved from the domain.
    */
@@ -4871,8 +4957,9 @@ wait for `status: completed` before uploading files, deploying or creating datab
 `failed` means the setup stopped before finishing or has not reported progress for
 over an hour. Setups older than 24 hours are not listed.
 
-`type` is the website type the setup was started with (`wordpress`, `headless_wordpress`,
-`headless_ecommerce`, `headless_pocketbase`), or `null` for an empty website.
+`type` is the website type the setup was started with (`wordpress`, `headless_empty`,
+`headless_wordpress`, `headless_ecommerce`, `headless_pocketbase`), or `null` for an empty
+website.
    */
   "hosting_websites_list-setups": {
     params: {
@@ -4895,17 +4982,25 @@ over an hour. Setups older than 24 hours are not listed.
   /**
    * Starts a website setup on a Web or Cloud hosting order and returns the created setup
 right away; the website itself is provisioned asynchronously. Poll the list website
-setups endpoint with the `domain` filter every 10 to 15 seconds and wait for
-`status: completed` before uploading files, deploying or creating databases.
+setups endpoint (`hosting_websites_list-setups`) with the `domain` filter every 10 to 15
+seconds and wait for `status: completed` before uploading files, deploying or creating
+databases.
 
 Omit `type` for an empty website. `type: wordpress` installs WordPress in the website
 root with the admin user, email and password from `wordpress`, the domain as the site
 title, and `en_US` when `wordpress.language` is omitted. The headless types
-(`headless_wordpress`, `headless_ecommerce`, `headless_pocketbase`) create a headless
-website; `headless_wordpress` additionally installs WordPress into the `cms` directory
-of the website root with generated credentials.
-
-Omit `domain` to set the website up on a generated temporary free subdomain.
+(`headless_empty`, `headless_wordpress`, `headless_ecommerce`, `headless_pocketbase`)
+create a headless website; `headless_wordpress` additionally installs WordPress into the
+`cms` directory of the website root with generated credentials. `headless_empty` installs
+nothing: WordPress can be added later through
+`POST /api/hosting/v1/accounts/{username}/wordpress/installations`
+(`wordpress_installations_install`) with `type: headless`.
+
+Omit `domain` to set the website up on a generated temporary free subdomain. To know the
+free subdomain before the call, so a timed-out call can be looked up and retried on the
+same domain, generate one through `POST /api/hosting/v1/domains/free-subdomains`
+(`hosting_domains_generate-free-subdomain`) and send it as `domain`. It is accepted for
+24 hours, only from the client that generated it.
 
 When the order has no hosting account yet, the setup creates one first, in the datacenter
 given by `datacenter_code` or the order's default datacenter when it is omitted.
@@ -4920,11 +5015,11 @@ running.
        */
       order_id: number;
       /**
-       * Website type. Omit or `null` for an empty website. `wordpress` installs WordPress in the website root and requires `wordpress`. The headless types (`headless_wordpress`, `headless_ecommerce`, `headless_pocketbase`) create a headless website; `headless_wordpress` additionally installs WordPress into the `cms` directory with generated credentials.
+       * Website type. Omit or `null` for an empty website. `wordpress` installs WordPress in the website root and requires `wordpress`. The headless types (`headless_empty`, `headless_wordpress`, `headless_ecommerce`, `headless_pocketbase`) create a headless website; `headless_wordpress` additionally installs WordPress into the `cms` directory with generated credentials. `headless_empty` installs nothing, so WordPress can be added later through `POST /api/hosting/v1/accounts/{username}/wordpress/installations` (`wordpress_installations_install`) with `type: headless`.
        */
       type?: string;
       /**
-       * Customer-owned domain. Cannot start with "www." and can have at most one subdomain level, e.g. `blog.example.com`. Omit or `null` to set the website up on a generated temporary free subdomain.
+       * Customer-owned domain, or a free subdomain you generated through `POST /api/hosting/v1/domains/free-subdomains` (`hosting_domains_generate-free-subdomain`) in the last 24 hours. Cannot start with "www." and can have at most one subdomain level, e.g. `blog.example.com`. Omit or `null` to set the website up on a generated temporary free subdomain.
        */
       domain?: string;
       /**
@@ -9580,19 +9675,29 @@ database files that have been uploaded to the website's directory.
    * Install WordPress on an existing website.
 
 The website must already exist before calling this endpoint. To create a new
-website first, use POST /api/hosting/v1/websites and poll
-GET /api/hosting/v1/websites until it appears.
-
-Call GET /api/hosting/v1/wordpress/installations filtered by username and
-domain before proceeding to check whether WordPress is already installed on
-the target domain/path. If WordPress already exists and `overwrite` is false
-(the default), the async job will fail.
+website first, use POST /api/hosting/v1/orders/{order_id}/onboardings
+(`hosting_websites_start-setup`) and poll GET /api/hosting/v1/onboardings
+(`hosting_websites_list-setups`) with the `domain` filter until its `status` is
+`completed`.
+
+Send `type: headless` to turn a headless website (for example one created by
+`hosting_websites_start-setup` with `type: headless_empty`) into a headless WordPress
+website: WordPress is installed into the `cms` directory with the Hostinger headless
+MU plugin and the website is marked as a headless WordPress website. `directory` is
+not allowed with it. The target website must already be headless: the headless
+install rewrites the root `.htaccess`, so on any other website the request is
+rejected with 422.
+
+Call GET /api/hosting/v1/wordpress/installations (`wordpress_installations_list`)
+filtered by username and domain before proceeding to check whether WordPress is
+already installed on the target domain/path. If WordPress already exists and
+`overwrite` is false (the default), the async job will fail.
 
 This operation is asynchronous: a successful response only means the install
 job has been queued, not that WordPress is ready. Installation typically
-takes 1-2 minutes. Poll GET /api/hosting/v1/wordpress/installations filtered
-by username and domain to track progress. When the installation appears in
-that list, WordPress is ready.
+takes 1-2 minutes. Poll GET /api/hosting/v1/wordpress/installations
+(`wordpress_installations_list`) filtered by username and domain to track
+progress. When the installation appears in that list, WordPress is ready.
 
 Returns 422 when the account already uses all the databases its plan allows,
 unless `database.name` is an existing database on the account.
@@ -9616,7 +9721,11 @@ unless `database.name` is an existing database on the account.
        */
       language?: string;
       /**
-       * Relative directory to install WordPress into. Defaults to the website root when omitted.
+       * Installation kind; `default` when omitted. `headless` installs WordPress into the `cms` directory with the Hostinger headless MU plugin and marks the website as a headless WordPress website. Accepted only for a website that is already headless, e.g. one created by `POST /api/hosting/v1/orders/{order_id}/onboardings` (`hosting_websites_start-setup`) with `type: headless_empty`; any other website is rejected with 422.
+       */
+      type?: string;
+      /**
+       * Installation subdirectory relative to the document root; omit for the root. Not allowed with `type: headless`, which always installs into `cms`.
        */
       directory?: string;
       /**