hostinger-api-mcp 3.10.4 → 3.11.0

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

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