hostinger-api-mcp 3.19.2 → 3.20.1

package/CHANGELOG.md

@@ -4,6 +4,25 @@ Generated at release time from the diff between the previous and current
 build. Tool changes are listed individually; everything else is summarised
 by area.
 
+## v3.20.1 — 2026-10-28
+
+### Also in this release
+
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+
+## v3.20.0 — 2026-10-28
+
+### Operations
+
+- Added `changelog_list-entries` — List changelog and roadmap entries (what's new, what's coming)
+
+### Also in this release
+
+- Documentation: `README.md`
+- Server instructions: 4 files
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Build and packaging: `types.d.ts`
+
 ## v3.19.2 — 2026-10-28
 
 ### Also in this release

package/README.md

@@ -69,19 +69,19 @@ pnpm update -g @hostinger/mcp
 
 This package installs the following MCP server commands:
 
-- `hostinger-api-mcp` — unified server over every operation (412 total)
-- `hostinger-agency-hosting-mcp` — 42 operations for agency-hosting
-- `hostinger-agent-readiness-mcp` — 3 operations for agent-readiness
-- `hostinger-billing-mcp` — 9 operations for billing
-- `hostinger-dns-mcp` — 8 operations for dns
-- `hostinger-domains-mcp` — 42 operations for domains
-- `hostinger-ecommerce-mcp` — 29 operations for ecommerce
-- `hostinger-horizons-mcp` — 6 operations for horizons
-- `hostinger-hosting-mcp` — 61 operations for hosting
-- `hostinger-mail-mcp` — 38 operations for mail
-- `hostinger-reach-mcp` — 70 operations for reach
-- `hostinger-vps-mcp` — 67 operations for vps
-- `hostinger-wordpress-mcp` — 40 operations for wordpress
+- `hostinger-api-mcp` — unified server over every operation (413 total)
+- `hostinger-agency-hosting-mcp` — 43 operations for agency-hosting
+- `hostinger-agent-readiness-mcp` — 4 operations for agent-readiness
+- `hostinger-billing-mcp` — 10 operations for billing
+- `hostinger-dns-mcp` — 9 operations for dns
+- `hostinger-domains-mcp` — 43 operations for domains
+- `hostinger-ecommerce-mcp` — 30 operations for ecommerce
+- `hostinger-horizons-mcp` — 7 operations for horizons
+- `hostinger-hosting-mcp` — 62 operations for hosting
+- `hostinger-mail-mcp` — 39 operations for mail
+- `hostinger-reach-mcp` — 71 operations for reach
+- `hostinger-vps-mcp` — 68 operations for vps
+- `hostinger-wordpress-mcp` — 41 operations for wordpress
 
 Every binary exposes the same three tools; a scoped binary only searches and executes its own group's operations. `hostinger-api-mcp` remains the backwards-compatible default.
 
@@ -235,6 +235,13 @@ Operations that newer tools replace are hidden from `search`, and not documented
 
 ### `hostinger-agency-hosting-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### agency-hosting_deploy-node-static-website
 
 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.
@@ -685,6 +692,13 @@ Lists the WordPress core versions available for installation on an Agency Plan w
 
 ### `hostinger-agent-readiness-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### agent-readiness_checks_list
 
 List every check an agent readiness scan runs, with its name, category and weight.\n
@@ -721,6 +735,13 @@ Returns 404 when the domain has never been scanned; use the `Run agent readiness
 
 ### `hostinger-billing-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### billing_catalog_list
 
 Retrieve catalog items available for order.
@@ -835,6 +856,13 @@ Use this endpoint to renew any subscription available in your account.
 
 ### `hostinger-dns-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### dns_snapshots_get
 
 Retrieve particular DNS snapshot with contents of DNS zone records.
@@ -921,6 +949,13 @@ Use this endpoint to verify DNS record validity before applying changes.
 
 ### `hostinger-domains-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### domains_verifications_direct
 
 Retrieve a list of pending and completed domain verifications.
@@ -1455,6 +1490,13 @@ Use this endpoint to view which domains use specific contact profiles.
 
 ### `hostinger-ecommerce-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### ecommerce_discounts_list
 
 List a store's discounts. Filter by free text over code and name, or by disabled state.
@@ -1700,6 +1742,13 @@ store currency. Returns the created variant.
 
 ### `hostinger-horizons-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### horizons_websites_clone
 
 Clone a Hostinger Horizons website into a new website.\n
@@ -1814,6 +1863,13 @@ interface in the provided website URL.
 
 ### `hostinger-hosting-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### hosting_deploy
 
 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. A plugin or theme goes into the site's WordPress installation, also when WordPress is in a folder of the document root (headless). 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, they are detected from the branch's package.json; pass appType, nodeVersion, outputDirectory, buildScript or entryFile to override them). Git needs GitHub or GitLab connected once in hPanel.
@@ -2567,6 +2623,13 @@ complete. The response returns before the removal finishes.
 
 ### `hostinger-mail-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### mail_aliases_create-alias
 
 Create an alias for the given mailbox. The alias address is formed
@@ -2909,6 +2972,13 @@ requests are rate limited upstream.
 
 ### `hostinger-reach-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### reach_automations_get
 
 Get a single automation with the counts of contacts that entered it, are moving through it,
@@ -3736,6 +3806,13 @@ from the WordPress plugin - so confirm the site and the plan with the customer b
 
 ### `hostinger-vps-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### vps_data-centers_list
 
 Retrieve all available data centers.
@@ -4528,6 +4605,13 @@ Use this endpoint to power off running VPS instances.
 
 ### `hostinger-wordpress-mcp`
 
+#### changelog_list-entries
+
+What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### wordpress_ai-content_generate-images
 
 Start generating one or more images from a prompt and an image type for the specified

package/gemini-extension.json

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

package/src/core/instructions.agency-hosting.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- 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 from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\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 from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\n\nProduct updates\n- For what is new at Hostinger (release notes, recent changes, new features), call changelog_list-entries, filtered by `product` and `since`. For what is coming (the roadmap), call it with `status: upcoming`. It needs no API token.\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

@@ -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- 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 from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\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 from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\n\nProduct updates\n- For what is new at Hostinger (release notes, recent changes, new features), call changelog_list-entries, filtered by `product` and `since`. For what is coming (the roadmap), call it with `status: upcoming`. It needs no API token.\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- 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 from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\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 "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 from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\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\nProduct updates\n- For what is new at Hostinger (release notes, recent changes, new features), call changelog_list-entries, filtered by `product` and `since`. For what is coming (the roadmap), call it with `status: upcoming`. It needs no API token.\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- 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 from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\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";
+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 from a shell\n- The Hostinger CLI deploys a website in one command and links the directory: `hostinger up <dir> --domain <domain> --format json` (`--yes` replaces content, `--create` makes a site, `--dry-run` shows the plan). It never prompts without a terminal.\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\nProduct updates\n- For what is new at Hostinger (release notes, recent changes, new features), call changelog_list-entries, filtered by `product` and `since`. For what is coming (the roadmap), call it with `status: upcoming`. It needs no API token.\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

@@ -66,7 +66,7 @@ const GetSkillRequestSchema = z.object({
 
 /**
  * MCP Server for Hostinger API
- * Generated from OpenAPI spec version 2.5.0
+ * Generated from OpenAPI spec version 2.5.1
  */
 class MCPServer {
   constructor({ name, version, tools, instructions, skills = [] }) {
@@ -328,6 +328,8 @@ class MCPServer {
         return await this.handleNodeStaticDeploy(params);
       case 'agency-hosting_deploy-php-application':
         return await this.handlePhpAppDeploy(params);
+      case 'changelog_list-entries':
+        return await this.handleChangelogListEntries(params);
       default:
         throw new Error(`Unknown custom tool: ${tool.name}`);
     }
@@ -3509,6 +3511,66 @@ class MCPServer {
     };
   }
 
+  async handleChangelogListEntries(params) {
+    // Their key order is the order of the results: upcoming items, then released entries.
+    const CHANGELOG_FEEDS = {
+      upcoming: "https://www.hostinger.com/roadmap/feed.json",
+      released: "https://www.hostinger.com/changelog/feed.json",
+    };
+    // Agents often send null for an optional field they don't use; treat it as unset.
+    const { status = 'released', product, since, limit = 20 } = Object.fromEntries(Object.entries(params).filter(([, value]) => value !== null));
+    const feedStatuses = Object.keys(CHANGELOG_FEEDS);
+    if (status !== 'all' && !feedStatuses.includes(status)) {
+      throw new Error('status must be one of: ' + [...feedStatuses, 'all'].join(', '));
+    }
+    if (typeof limit !== 'number' || !Number.isInteger(limit) || limit < 1 || limit > 100) {
+      throw new Error('limit must be an integer from 1 to 100');
+    }
+    const sinceTime = since === undefined ? undefined : Date.parse(String(since));
+    // Only a real YYYY-MM-DD day, the one form that reads back unchanged: Date.parse also takes "Oct 1"
+    // (as 2001-10-01) and rolls 2026-02-30 over to March.
+    if (sinceTime !== undefined && (Number.isNaN(sinceTime) || new Date(sinceTime).toISOString().slice(0, 10) !== since)) {
+      throw new Error(`since must be a day as YYYY-MM-DD: ${since}`);
+    }
+    const sameText = (a, b) => String(a).toLowerCase() === String(b).toLowerCase();
+    const time = (date, ifMissing) => Date.parse(date ?? '') || ifMissing;
+
+    const statuses = status === 'all' ? feedStatuses : [status];
+    const entriesPerFeed = await Promise.all(statuses.map(async feedStatus => {
+      const feed = CHANGELOG_FEEDS[feedStatus];
+      // The feeds are public: send only the User-Agent, never the API headers.
+      const response = await axios.get(feed, { headers: { 'User-Agent': this.headers['User-Agent'] }, timeout: 30000 })
+        .catch((error) => { throw new Error(`${feed} could not be read: ${error.message}`); });
+      if (!Array.isArray(response.data?.items)) {
+        throw new Error(`${feed} returned no items (HTTP ${response.status})`);
+      }
+      // The feed sets the status: the changelog lists only released entries, the roadmap only unreleased items.
+      const toEntry = (item) => ({
+        title: item.title,
+        summary: item.summary,
+        product: item._hostinger?.product,
+        url: new URL(item.url, feed).toString(),
+        status: feedStatus,
+        plan: item._hostinger?.plan,
+      });
+      if (feedStatus === 'released') {
+        const publishedTime = (item) => time(item.date_published, 0);
+        return response.data.items
+          .filter(item => sinceTime === undefined || publishedTime(item) >= sinceTime)
+          .sort((a, b) => publishedTime(b) - publishedTime(a))
+          .map(item => ({ ...toEntry(item), date: item.date_published }));
+      }
+      // Roadmap items have no publication date: soonest expected release first, unknown dates last.
+      const releaseTime = (item) => time(item._hostinger?.expected_release_date, Number.MAX_SAFE_INTEGER);
+      return response.data.items
+        .sort((a, b) => releaseTime(a) - releaseTime(b))
+        .map(item => ({ ...toEntry(item), expected_release_date: item._hostinger?.expected_release_date }));
+    }));
+    const entries = entriesPerFeed.flat().filter(entry => product === undefined || sameText(entry.product, product));
+
+    return { feeds: statuses.map(feedStatus => CHANGELOG_FEEDS[feedStatus]), matched: entries.length, entries: entries.slice(0, limit) };
+  }
+
   /**
    * Execute an API call for a tool
    */

package/src/core/runtime.ts

@@ -39,6 +39,7 @@ interface OpenApiTool extends Tool {
   custom?: boolean;
   hidden?: boolean;
   group?: string;
+  everyServer?: boolean;
   topic?: string;
   handlerMethod?: string;
   templateFile?: string;
@@ -97,7 +98,7 @@ interface Skill { uri: string; frontmatter: Record<string, unknown>; resources:
 
 /**
  * MCP Server for Hostinger API
- * Generated from OpenAPI spec version 2.5.0
+ * Generated from OpenAPI spec version 2.5.1
  */
 class MCPServer {
   private readonly name: string;
@@ -359,6 +360,8 @@ class MCPServer {
         return await this.handleNodeStaticDeploy(params);
       case 'agency-hosting_deploy-php-application':
         return await this.handlePhpAppDeploy(params);
+      case 'changelog_list-entries':
+        return await this.handleChangelogListEntries(params);
       default:
         throw new Error(`Unknown custom tool: ${tool.name}`);
     }
@@ -3554,6 +3557,74 @@ class MCPServer {
     };
   }
 
+  private async handleChangelogListEntries(params: Record<string, unknown>): Promise<unknown> {
+    // Their key order is the order of the results: upcoming items, then released entries.
+    const CHANGELOG_FEEDS = {
+      upcoming: "https://www.hostinger.com/roadmap/feed.json",
+      released: "https://www.hostinger.com/changelog/feed.json",
+    } as const;
+    type ChangelogStatus = keyof typeof CHANGELOG_FEEDS;
+    interface ChangelogFeedItem {
+      url: string;
+      title: string;
+      summary?: string;
+      date_published?: string;
+      _hostinger?: { product?: string; plan?: string[]; expected_release_date?: string };
+    }
+    // Agents often send null for an optional field they don't use; treat it as unset.
+    const { status = 'released', product, since, limit = 20 } = Object.fromEntries(Object.entries(params).filter(([, value]) => value !== null));
+    const feedStatuses = Object.keys(CHANGELOG_FEEDS) as ChangelogStatus[];
+    if (status !== 'all' && !feedStatuses.includes(status as ChangelogStatus)) {
+      throw new Error('status must be one of: ' + [...feedStatuses, 'all'].join(', '));
+    }
+    if (typeof limit !== 'number' || !Number.isInteger(limit) || limit < 1 || limit > 100) {
+      throw new Error('limit must be an integer from 1 to 100');
+    }
+    const sinceTime = since === undefined ? undefined : Date.parse(String(since));
+    // Only a real YYYY-MM-DD day, the one form that reads back unchanged: Date.parse also takes "Oct 1"
+    // (as 2001-10-01) and rolls 2026-02-30 over to March.
+    if (sinceTime !== undefined && (Number.isNaN(sinceTime) || new Date(sinceTime).toISOString().slice(0, 10) !== since)) {
+      throw new Error(`since must be a day as YYYY-MM-DD: ${since}`);
+    }
+    const sameText = (a: unknown, b: unknown): boolean => String(a).toLowerCase() === String(b).toLowerCase();
+    const time = (date: string | undefined, ifMissing: number): number => Date.parse(date ?? '') || ifMissing;
+
+    const statuses = status === 'all' ? feedStatuses : [status as ChangelogStatus];
+    const entriesPerFeed = await Promise.all(statuses.map(async feedStatus => {
+      const feed = CHANGELOG_FEEDS[feedStatus];
+      // The feeds are public: send only the User-Agent, never the API headers.
+      const response = await axios.get<{ items?: ChangelogFeedItem[] }>(feed, { headers: { 'User-Agent': this.headers['User-Agent'] }, timeout: 30000 })
+        .catch((error: Error) => { throw new Error(`${feed} could not be read: ${error.message}`); });
+      if (!Array.isArray(response.data?.items)) {
+        throw new Error(`${feed} returned no items (HTTP ${response.status})`);
+      }
+      // The feed sets the status: the changelog lists only released entries, the roadmap only unreleased items.
+      const toEntry = (item: ChangelogFeedItem) => ({
+        title: item.title,
+        summary: item.summary,
+        product: item._hostinger?.product,
+        url: new URL(item.url, feed).toString(),
+        status: feedStatus,
+        plan: item._hostinger?.plan,
+      });
+      if (feedStatus === 'released') {
+        const publishedTime = (item: ChangelogFeedItem): number => time(item.date_published, 0);
+        return response.data.items
+          .filter(item => sinceTime === undefined || publishedTime(item) >= sinceTime)
+          .sort((a, b) => publishedTime(b) - publishedTime(a))
+          .map(item => ({ ...toEntry(item), date: item.date_published }));
+      }
+      // Roadmap items have no publication date: soonest expected release first, unknown dates last.
+      const releaseTime = (item: ChangelogFeedItem): number => time(item._hostinger?.expected_release_date, Number.MAX_SAFE_INTEGER);
+      return response.data.items
+        .sort((a, b) => releaseTime(a) - releaseTime(b))
+        .map(item => ({ ...toEntry(item), expected_release_date: item._hostinger?.expected_release_date }));
+    }));
+    const entries = entriesPerFeed.flat().filter(entry => product === undefined || sameText(entry.product, product));
+
+    return { feeds: statuses.map(feedStatus => CHANGELOG_FEEDS[feedStatus]), matched: entries.length, entries: entries.slice(0, limit) };
+  }
+
   /**
    * Execute an API call for a tool
    */

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

@@ -1,5 +1,56 @@
 // Auto-generated tool list for group: agency-hosting
 export default [
+  {
+    "name": "changelog_list-entries",
+    "title": "List changelog and roadmap entries (what's new, what's coming)",
+    "annotations": {
+      "title": "List changelog and roadmap entries (what's new, what's coming)",
+      "readOnlyHint": true,
+      "destructiveHint": false
+    },
+    "topic": "common",
+    "description": "What's new and what's coming at Hostinger: list entries of the public Hostinger changelog (release notes, product updates, recent changes, new features and improvements) and of the public roadmap (upcoming features not released yet). Released entries come newest first; upcoming items come soonest expected release first. Reads released changelog entries by default; pick upcoming for the roadmap or all for both. Filter by product or date. Each entry has its title, summary, product, URL, status (released or upcoming), and plan when the entry states one; released entries have their date, upcoming items their expected release date when set. Needs no API token.",
+    "method": "",
+    "path": "",
+    "inputSchema": {
+      "type": "object",
+      "properties": {
+        "status": {
+          "type": "string",
+          "description": "Which entries to list: released (default) reads the changelog, for what's new; upcoming reads the roadmap's unreleased items, for what's coming; all reads both.",
+          "enum": [
+            "released",
+            "upcoming",
+            "all"
+          ],
+          "default": "released"
+        },
+        "product": {
+          "type": "string",
+          "description": "Only entries for this product, matched case-insensitively. Products include AI Builder, Web Hosting, VPS, Domains, Hostinger Mail, Reach, Ecommerce, WordPress, Hostinger Agent, AI Automation Apps, Web Pro, Billing, Growth and Payments."
+        },
+        "since": {
+          "type": "string",
+          "format": "date",
+          "description": "Only released entries dated on or after this date, as YYYY-MM-DD. Upcoming items are not filtered by date."
+        },
+        "limit": {
+          "type": "integer",
+          "description": "Most entries to return",
+          "minimum": 1,
+          "maximum": 100,
+          "default": 20
+        }
+      },
+      "required": []
+    },
+    "security": [],
+    "custom": true,
+    "templateFile": "list-changelog-entries.template.js",
+    "templateFileTS": "list-changelog-entries.template.ts",
+    "handlerMethod": "handleChangelogListEntries",
+    "everyServer": true
+  },
   {
     "name": "agency-hosting_deploy-node-static-website",
     "title": "Deploy node-static website",