hostinger-api-mcp 1.61.1 → 1.62.0

package/CHANGELOG.md

@@ -4,6 +4,23 @@ Generated at release time from the diff between the previous and current
 build. Tool changes are listed individually; everything else is summarised
 by area.
 
+## v1.62.0 — 2026-09-21
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/SKILL.md`, `skills/headless/references/SETUP.md`, `skills/headless/references/DATABASE.md`
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Server entry points: 6 files
+- Server instructions: `src/core/instructions.js`, `src/core/instructions.ts`
+
+## v1.61.2 — 2026-09-21
+
+### Also in this release
+
+- Dependencies: `package-lock.json`
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Other files: `.gitignore`
+
 ## v1.61.1 — 2026-09-17
 
 ### Also in this release

package/gemini-extension.json

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

package/skills/headless/SKILL.md

@@ -31,7 +31,7 @@ If signals conflict, ask the user — don't guess.
 2. **Setup** (`references/SETUP.md`) — plan check, then provision the website on a free subdomain (or the user's own domain) and wait until it's ready.
 3. **Store** (`references/STORE.md`, only when commerce is needed) — resolve or create the store and its `custom` sales channel, seed products/shipping/payment, and note the `sales_channel_id` for the frontend.
 4. **Content backend** (`references/WORDPRESS.md`, only when owner-managed content is needed) — install WordPress on a dedicated subdomain, wait until it's ready, and hand the owner a wp-admin login link. The frontend reads it through the public WP REST API.
-5. **Build** — create or wire the frontend. For store runs, follow the frontend contract in `references/STORE.md` (catalog fetched at runtime from the public Storefront API, cart in `localStorage`, client-side checkout — never embed an API token in the site). For content runs, follow the frontend contract in `references/WORDPRESS.md` (posts fetched at runtime from the WP REST API, rendered HTML bodies, graceful empty states).
+5. **Build** — create or wire the frontend. For store runs, follow the frontend contract in `references/STORE.md` (catalog fetched at runtime from the public Storefront API, cart in `localStorage`, client-side checkout — never embed an API token in the site). For content runs, follow the frontend contract in `references/WORDPRESS.md` (posts fetched at runtime from the WP REST API, rendered HTML bodies, graceful empty states). When the app needs MySQL, follow `references/DATABASE.md` (which host each runtime connects to, credentials via env vars or a server-side config file, never in the frontend).
 6. **Deploy** (`references/DEPLOYMENT.md`) — archive and deploy via the matching hosting tool, polling build logs for Node.js runs.
 7. **Verify** — curl the live URL for a 200 and a piece of real page copy; for store runs, confirm a checkout POST returns a redirect URL; for content runs, confirm the WP REST API returns 200 and the frontend renders posts. Show the user the live URL and where to manage things (hPanel: https://hpanel.hostinger.com, the store dashboard for commerce, wp-admin for content).
 8. **Record** — write `.hostinger/site.json` into the project: `{ "domain", "username", "type": "static"|"nodejs", "sales_channel_id"?, "store_id"?, "cms_domain"? }`. This is what makes future runs resolve as `iterate`.
@@ -46,6 +46,7 @@ Run non-interactively wherever possible. The exceptions that must involve the us
 | Store: seed the backend + the frontend API contract | `references/STORE.md` |
 | WordPress: headless CMS/blog backend + the frontend read contract | `references/WORDPRESS.md` |
 | Deploy: static vs Node.js, archive rules, logs, verify | `references/DEPLOYMENT.md` |
+| Database + runtime: MySQL host per runtime, env vars, what to poll, runtime logs | `references/DATABASE.md` |
 
 ## Where the how comes from
 

package/skills/headless/references/DATABASE.md

@@ -0,0 +1,49 @@
+# Database and runtime — MySQL hosts, env vars, and what to poll
+
+Use this when the app needs MySQL, or when a deploy "succeeded" but the app cannot reach its database. Everything here uses the **hosting** MCP tools; Agency Plan differences are at the end.
+
+## 1. Create the database
+
+1. `hosting_createAccountDatabaseV1` on the site's `username` with a database name, a user and a password you generate — name and user are prefixed with the account username automatically.
+2. Read the full, prefixed `name` and `user` back from `hosting_listAccountDatabasesV1`; every other database tool wants the full name.
+3. Do not print the password to the user once it is stored, and never commit it.
+
+## 2. Which host the app connects to
+
+| Where the code runs | Host | Port | Why |
+| --- | --- | --- | --- |
+| PHP on the website | `localhost` or `127.0.0.1` | 3306 | `localhost` uses the MySQL socket; both are granted |
+| Node.js on the website | `127.0.0.1` | 3306 | `localhost` may resolve to IPv6 `::1`, and not every database user has that grant |
+| Outside Hostinger (a laptop, another server) | the `host` from `hosting_listAccountDatabasesV1` (`srvNNNN.hstgr.io`) | 3306 | needs `hosting_createDatabaseRemoteConnectionV1` for that client's IP first — never `%`, it opens the database to every address on the internet |
+
+Do not put the remote `host` into the deployed app — it has no grant for connections that come from the server itself.
+
+## 3. Hand credentials to the app
+
+- **Node.js:** environment variables via `hosting_replaceNode_jsEnvironmentVariablesV1`. Conventional keys: `DB_HOST=127.0.0.1`, `DB_PORT=3306`, `DB_NAME`, `DB_USER`, `DB_PASSWORD`, plus `DATABASE_URL=mysql://USER:PASSWORD@127.0.0.1:3306/NAME` for ORMs that want one string — URL-encode `USER` and `PASSWORD` there (`encodeURIComponent`), or a password containing `@`, `:`, `/` or `#` breaks the URL. The call is a **full replace**: list the current keys with `hosting_listNode_jsEnvironmentVariablesV1` (values come back masked as `********` — never copy those), then send the complete set with real values. Saving restarts the process; frameworks that bake variables into the build (Next.js, `NEXT_PUBLIC_*`) need a new `hosting_startNode_jsBuildV1` afterwards.
+- **PHP:** a config file on the server that the app reads (its own `config.php`, WordPress's `wp-config.php`). Ship it with the deploy, keep it out of git.
+- **Never** in client-side JavaScript, in a committed `.env`, or in chat replies.
+
+## 4. What is asynchronous, and what to poll
+
+| You called | Poll this until | Typical wait |
+| --- | --- | --- |
+| `hosting_createWebsiteV1` | `hosting_listWebsitesV1` lists the domain | up to a few minutes |
+| `hosting_deployJsApplication` | `hosting_listJsDeployments` shows the build finished | minutes |
+| `hosting_startNode_jsBuildV1` | `hosting_getNode_jsBuildDetailsV1` state is `completed` or `failed` | minutes |
+| `hosting_installWordPressV1`, plugin/theme/core jobs | `hosting_listWordPressInstallationsV1` lists the install | 1–2 minutes |
+| `hosting_repairDatabaseV1`, `hosting_deleteWebsiteV1` | nothing to poll — runs in the background | minutes |
+| `agency-hosting_createANewWebsiteV1` | `agency-hosting_getWebsiteSetupStatusV1` with `setup_uuid` is `completed` | minutes |
+
+Poll with backoff (a few seconds, then tens of seconds). A queued response is not a failure, and re-sending the write does not speed it up.
+
+## 5. When the app is up but broken
+
+- Build failed: `hosting_getNodeJSBuildLogsV1` for the raw log, `hosting_analyseFailedNode_jsBuildV1` for a diagnosis.
+- Build passed, app errors: `hosting_getNode_jsRuntimeLogsV1` 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_getPHPDetailsV1`, then `hosting_updatePHPOptionsV1`.
+
+## Agency Plan websites (`agency-hosting_*`)
+
+`agency-hosting_createWebsiteDatabaseV1` creates the database and its single user; the user is granted on `localhost`, so the PHP app connects to `localhost`. Deploys are synchronous there — `agency-hosting_deployPhpApplication` returns when the site is live. Other jobs (SSL, backups) show up in `agency-hosting_listWebsiteProcessesV1`.

package/skills/headless/references/SETUP.md

@@ -30,5 +30,5 @@ If the domain already has a website (an `iterate` run, or the user pointed at an
 
 ## 4. Optional extras (only when the run needs them)
 
-- **Database:** `hosting_createAccountDatabaseV1` for Node.js apps that need MySQL; pass the credentials to the app via its environment/config, never hard-coded into client-side code.
+- **Database:** when the app needs MySQL, follow `DATABASE.md` — creating it, which host each runtime connects to (Node.js must use `127.0.0.1`), and handing the credentials to the app without hard-coding them.
 - **DNS records:** the DNS tools (`DNS_updateDNSRecordsV1` etc.) for custom-domain records; take a snapshot (`DNS_getDNSSnapshotListV1` context) before destructive changes.

package/src/core/instructions.js

@@ -0,0 +1,2 @@
+// Auto-generated server instructions
+export default "Hostinger API notes for agents. Tool descriptions are authoritative for request shapes; read them before calling.\n\nDatabases (web hosting, hosting_* tools)\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_listAccountDatabasesV1 (srvNNNN.hstgr.io) is only for connections from outside Hostinger, after hosting_createDatabaseRemoteConnectionV1. Never use it from the app.\n- Agency Plan (agency-hosting_* tools) 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 tool with backoff (seconds, then minutes). Never re-send the write.\n- hosting_createWebsiteV1 -> poll hosting_listWebsitesV1 until the domain appears (a few minutes).\n- hosting_startNode_jsBuildV1 -> hosting_getNode_jsBuildDetailsV1; logs via hosting_getNodeJSBuildLogsV1; on failure hosting_analyseFailedNode_jsBuildV1.\n- hosting_installWordPressV1 and WordPress plugin/theme/core jobs -> poll hosting_listWordPressInstallationsV1.\n- agency-hosting_createANewWebsiteV1 -> poll agency-hosting_getWebsiteSetupStatusV1 with setup_uuid; other Agency Plan jobs -> agency-hosting_listWebsiteProcessesV1.\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_replaceNode_jsEnvironmentVariablesV1 (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.ts

@@ -0,0 +1,3 @@
+// Auto-generated server instructions
+const instructions: string = "Hostinger API notes for agents. Tool descriptions are authoritative for request shapes; read them before calling.\n\nDatabases (web hosting, hosting_* tools)\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_listAccountDatabasesV1 (srvNNNN.hstgr.io) is only for connections from outside Hostinger, after hosting_createDatabaseRemoteConnectionV1. Never use it from the app.\n- Agency Plan (agency-hosting_* tools) 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 tool with backoff (seconds, then minutes). Never re-send the write.\n- hosting_createWebsiteV1 -> poll hosting_listWebsitesV1 until the domain appears (a few minutes).\n- hosting_startNode_jsBuildV1 -> hosting_getNode_jsBuildDetailsV1; logs via hosting_getNodeJSBuildLogsV1; on failure hosting_analyseFailedNode_jsBuildV1.\n- hosting_installWordPressV1 and WordPress plugin/theme/core jobs -> poll hosting_listWordPressInstallationsV1.\n- agency-hosting_createANewWebsiteV1 -> poll agency-hosting_getWebsiteSetupStatusV1 with setup_uuid; other Agency Plan jobs -> agency-hosting_listWebsiteProcessesV1.\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_replaceNode_jsEnvironmentVariablesV1 (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/runtime.js

@@ -10,6 +10,8 @@ import { config as dotenvConfig } from "dotenv";
 import {
   ListToolsRequestSchema,
   CallToolRequestSchema,
+  ErrorCode,
+  McpError,
 } from "@modelcontextprotocol/sdk/types.js";
 import { OAuthProvider, getEnvToken } from "./oauth.js";
 import * as tus from "tus-js-client";
@@ -19,6 +21,19 @@ import path from "path";
 // Load environment variables
 dotenvConfig({ quiet: true });
 
+/**
+ * An upstream API call that came back as a failure. Carries the status and the
+ * API's own response body so the CallTool handler can hand both to the model.
+ */
+class ApiExecutionError extends Error {
+  constructor(status, data, message) {
+    super(message || `API request failed with status ${status}`);
+    this.name = 'ApiExecutionError';
+    this.status = status;
+    this.responseData = data;
+  }
+}
+
 const SECURITY_SCHEMES = {
   "apiToken": {
     "type": "http",
@@ -32,11 +47,12 @@ const SECURITY_SCHEMES = {
  * Generated from OpenAPI spec version 1.53.1
  */
 class MCPServer {
-  constructor({ name, version, tools }) {
+  constructor({ name, version, tools, instructions }) {
     // Initialize class properties
     this.name = name;
     this.version = version;
     this.toolList = tools;
+    this.instructions = instructions;
     this.server = null;
     this.tools = new Map();
     this.debug = process.env.DEBUG === "true";
@@ -57,6 +73,7 @@ class MCPServer {
         capabilities: {
           tools: {}, // Enable tools capability
         },
+        instructions: this.instructions,
       }
     );
 
@@ -157,13 +174,17 @@ class MCPServer {
         }
       }
 
+      // An unknown tool is a protocol error, not a tool execution error: the
+      // model cannot self-correct its way out of a name the server does not
+      // have. -32602 is what the spec's example and the SDK's own McpServer
+      // use; a plain Error would go out as -32603 instead.
       if (!toolName) {
-        throw new Error(`Tool not found: ${name}`);
+        throw new McpError(ErrorCode.InvalidParams, `Tool not found: ${name}`);
       }
 
       toolDetails = this.toolList.find(t => t.name === toolName);
       if (!toolDetails) {
-        throw new Error(`Tool details not found for ID: ${toolName}`);
+        throw new McpError(ErrorCode.InternalError, `Tool details not found for ID: ${toolName}`);
       }
 
       try {
@@ -189,10 +210,32 @@ class MCPServer {
 
       } catch (error) {
         const errorMessage = error instanceof Error ? error.message : String(error);
-        const response = error.response;
         this.log('error', `Error executing tool ${name}: ${errorMessage}`);
 
-        throw error;
+        // MCP reports tool execution failures (API errors, bad input, business
+        // logic) inside the result with isError: true. Throwing here would turn
+        // them into JSON-RPC protocol errors instead, which the spec reserves
+        // for unknown tools and malformed requests — those are still thrown,
+        // above, before this try. The status stays in the text so the model can
+        // tell a retryable 429/503 from a 403 it should not retry.
+        let errorText = errorMessage;
+        if (error instanceof ApiExecutionError) {
+          const payload = error.responseData;
+          const body = payload === null || payload === undefined || payload === ''
+            ? errorMessage
+            : typeof payload === 'object' ? JSON.stringify(payload) : String(payload);
+          errorText = error.status ? `HTTP ${error.status}: ${body}` : body;
+        }
+
+        return {
+          isError: true,
+          content: [
+            {
+              type: "text",
+              text: errorText
+            }
+          ]
+        };
       }
     });
   }
@@ -2474,6 +2517,13 @@ class MCPServer {
         this.log('debug', `Retry response status: ${response.status}`);
       }
 
+      // validateStatus resolves everything under 500, so a 4xx arrives here as
+      // an ordinary response. Without this it would be returned to the model as
+      // a successful tool result whose body happens to be the API's error.
+      if (response.status >= 400) {
+        throw new ApiExecutionError(response.status, response.data);
+      }
+
       return response.data;
 
     } catch (error) {
@@ -2489,10 +2539,14 @@ class MCPServer {
           data: typeof responseData === 'object' ? JSON.stringify(responseData) : responseData
         });
 
-        // Rethrow with more context for better error handling
-        const detailedError = new Error(`API request failed with status ${responseStatus}: ${errorMessage}`);
-        detailedError.response = error.response;
-        throw detailedError;
+        // Structured so the CallTool handler can report this as an MCP tool
+        // execution error carrying the API's own payload. Status is 0 for a
+        // transport failure (DNS, ECONNREFUSED, timeout) — there is no response.
+        throw new ApiExecutionError(
+          responseStatus ?? 0,
+          responseData,
+          `API request failed with status ${responseStatus}: ${errorMessage}`
+        );
       }
 
       throw error;
@@ -2606,7 +2660,7 @@ class MCPServer {
   }
 }
 
-export async function startServer({ name, version, tools }) {
+export async function startServer({ name, version, tools, instructions }) {
   const argv = minimist(process.argv.slice(2), {
     string: ['host'],
     boolean: ['stdio', 'http', 'help', 'version', 'login', 'logout'],
@@ -2664,7 +2718,7 @@ export async function startServer({ name, version, tools }) {
     }
   }
 
-  const server = new MCPServer({ name, version, tools });
+  const server = new MCPServer({ name, version, tools, instructions });
   if (argv.http) {
     await server.startHttp(argv.host, argv.port);
   } else {

package/src/core/runtime.ts

@@ -10,6 +10,8 @@ import { config as dotenvConfig } from "dotenv";
 import {
   ListToolsRequestSchema,
   CallToolRequestSchema,
+  ErrorCode,
+  McpError,
   Tool,
 } from "@modelcontextprotocol/sdk/types.js";
 import { OAuthProvider, getEnvToken } from "./oauth.js";
@@ -42,6 +44,22 @@ interface SecurityScheme {
   scheme?: string;
 }
 
+/**
+ * An upstream API call that came back as a failure. Carries the status and the
+ * API's own response body so the CallTool handler can hand both to the model.
+ */
+class ApiExecutionError extends Error {
+  public readonly status: number;
+  public readonly responseData: any;
+
+  constructor(status: number, data: any, message?: string) {
+    super(message || `API request failed with status ${status}`);
+    this.name = 'ApiExecutionError';
+    this.status = status;
+    this.responseData = data;
+  }
+}
+
 const SECURITY_SCHEMES: Record<string, SecurityScheme> = {
   "apiToken": {
     "type": "http",
@@ -60,16 +78,18 @@ class MCPServer {
   private readonly toolList: OpenApiTool[];
   private server: Server;
   private tools: Map<string, Tool> = new Map();
+  private instructions?: string;
   private debug: boolean;
   private baseUrl: string;
   private headers: Record<string, string>;
   private oauth: OAuthProvider;
 
-  constructor({ name, version, tools }: { name: string; version: string; tools: OpenApiTool[] }) {
+  constructor({ name, version, tools, instructions }: { name: string; version: string; tools: OpenApiTool[]; instructions?: string }) {
     // Initialize class properties
     this.name = name;
     this.version = version;
     this.toolList = tools;
+    this.instructions = instructions;
     this.debug = process.env.DEBUG === "true";
     this.baseUrl = process.env.API_BASE_URL || "https://developers.hostinger.com";
     this.headers = this.parseHeaders(process.env.API_HEADERS || "");
@@ -88,6 +108,7 @@ class MCPServer {
         capabilities: {
           tools: {}, // Enable tools capability
         },
+        instructions: this.instructions,
       }
     );
 
@@ -188,13 +209,17 @@ class MCPServer {
         }
       }
 
+      // An unknown tool is a protocol error, not a tool execution error: the
+      // model cannot self-correct its way out of a name the server does not
+      // have. -32602 is what the spec's example and the SDK's own McpServer
+      // use; a plain Error would go out as -32603 instead.
       if (!toolName) {
-        throw new Error(`Tool not found: ${name}`)
+        throw new McpError(ErrorCode.InvalidParams, `Tool not found: ${name}`);
       }
 
       toolDetails = this.toolList.find(t => t.name === toolName);
       if (!toolDetails) {
-        throw new Error(`Tool details not found for ID: ${toolName}`);
+        throw new McpError(ErrorCode.InternalError, `Tool details not found for ID: ${toolName}`);
       }
         
       try {
@@ -221,8 +246,31 @@ class MCPServer {
       } catch (error) {
         const errorMessage = error instanceof Error ? error.message : String(error);
         this.log('error', `Error executing tool ${toolName}: ${errorMessage}`);
-        
-        throw error;
+
+        // MCP reports tool execution failures (API errors, bad input, business
+        // logic) inside the result with isError: true. Throwing here would turn
+        // them into JSON-RPC protocol errors instead, which the spec reserves
+        // for unknown tools and malformed requests — those are still thrown,
+        // above, before this try. The status stays in the text so the model can
+        // tell a retryable 429/503 from a 403 it should not retry.
+        let errorText: string = errorMessage;
+        if (error instanceof ApiExecutionError) {
+          const payload = error.responseData;
+          const body = payload === null || payload === undefined || payload === ''
+            ? errorMessage
+            : typeof payload === 'object' ? JSON.stringify(payload) : String(payload);
+          errorText = error.status ? `HTTP ${error.status}: ${body}` : body;
+        }
+
+        return {
+          isError: true,
+          content: [
+            {
+              type: "text",
+              text: errorText
+            }
+          ]
+        };
       }
     });
   }
@@ -2524,6 +2572,13 @@ class MCPServer {
         this.log('debug', `Retry response status: ${response.status}`);
       }
 
+      // validateStatus resolves everything under 500, so a 4xx arrives here as
+      // an ordinary response. Without this it would be returned to the model as
+      // a successful tool result whose body happens to be the API's error.
+      if (response.status >= 400) {
+        throw new ApiExecutionError(response.status, response.data);
+      }
+
       return response.data;
 
     } catch (error) {
@@ -2540,10 +2595,14 @@ class MCPServer {
           data: typeof responseData === 'object' ? JSON.stringify(responseData) : String(responseData)
         });
 
-        // Rethrow with more context for better error handling
-        const detailedError = new Error(`API request failed with status ${responseStatus}: ${errorMessage}`);
-        (detailedError as any).response = axiosError.response;
-        throw detailedError;
+        // Structured so the CallTool handler can report this as an MCP tool
+        // execution error carrying the API's own payload. Status is 0 for a
+        // transport failure (DNS, ECONNREFUSED, timeout) — there is no response.
+        throw new ApiExecutionError(
+          responseStatus ?? 0,
+          responseData,
+          `API request failed with status ${responseStatus}: ${errorMessage}`
+        );
       }
 
       throw error;
@@ -2657,7 +2716,7 @@ class MCPServer {
   }
 }
 
-export async function startServer({ name, version, tools }: { name: string; version: string; tools: OpenApiTool[] }): Promise<void> {
+export async function startServer({ name, version, tools, instructions }: { name: string; version: string; tools: OpenApiTool[]; instructions?: string }): Promise<void> {
   const argv = minimist(process.argv.slice(2), {
     string: ['host'],
     boolean: ['stdio', 'http', 'help', 'version', 'login', 'logout'],
@@ -2715,7 +2774,7 @@ export async function startServer({ name, version, tools }: { name: string; vers
     }
   }
 
-  const server = new MCPServer({ name, version, tools });
+  const server = new MCPServer({ name, version, tools, instructions });
   if (argv.http) {
     await server.startHttp(argv.host, argv.port);
   } else {

package/src/servers/agency-hosting.js

@@ -2,5 +2,6 @@
 // Auto-generated entry for group: agency-hosting
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agency-hosting.js';
+import instructions from '../core/instructions.js';
 
-startServer({ name: 'hostinger-agency-hosting-mcp', version: '1.61.1', tools });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '1.62.0', tools, instructions });

package/src/servers/agency-hosting.ts

@@ -2,5 +2,6 @@
 // Auto-generated entry for group: agency-hosting
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agency-hosting.js';
+import instructions from '../core/instructions.js';
 
-startServer({ name: 'hostinger-agency-hosting-mcp', version: '1.61.1', tools });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '1.62.0', tools, instructions });

package/src/servers/all.js

@@ -2,5 +2,6 @@
 // Auto-generated entry for group: all
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/all.js';
+import instructions from '../core/instructions.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '1.61.1', tools });
+startServer({ name: 'hostinger-api-mcp', version: '1.62.0', tools, instructions });

package/src/servers/all.ts

@@ -2,5 +2,6 @@
 // Auto-generated entry for group: all
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/all.js';
+import instructions from '../core/instructions.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '1.61.1', tools });
+startServer({ name: 'hostinger-api-mcp', version: '1.62.0', tools, instructions });

package/src/servers/billing.js

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

package/src/servers/billing.ts

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

package/src/servers/dns.js

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

package/src/servers/dns.ts

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

package/src/servers/domains.js

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

package/src/servers/domains.ts

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

package/src/servers/ecommerce.js

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

package/src/servers/ecommerce.ts

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

package/src/servers/horizons.js

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

package/src/servers/horizons.ts

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

package/src/servers/hosting.js

@@ -2,5 +2,6 @@
 // Auto-generated entry for group: hosting
 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: '1.61.1', tools });
+startServer({ name: 'hostinger-hosting-mcp', version: '1.62.0', tools, instructions });

package/src/servers/hosting.ts

@@ -2,5 +2,6 @@
 // Auto-generated entry for group: hosting
 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: '1.61.1', tools });
+startServer({ name: 'hostinger-hosting-mcp', version: '1.62.0', 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: '1.61.1', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '1.62.0', 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: '1.61.1', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '1.62.0', 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: '1.61.1', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '1.62.0', 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: '1.61.1', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '1.62.0', 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: '1.61.1', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '1.62.0', 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: '1.61.1', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '1.62.0', 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: '1.61.1', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '1.62.0', 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: '1.61.1', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '1.62.0', tools });