Summary
You ship 11 focused MCP servers and default to none of them. main, bin.mcp and
bin.hostinger-api-mcp all resolve to src/servers/all.js, which is the union of everything —
396 tools.
What's in the package
From package.json in hostinger-api-mcp@1.61.0:
"main": "./src/servers/all.js",
"bin": {
"hostinger-api-mcp": "./src/servers/all.js",
"mcp": "./src/servers/all.js",
"hostinger-dns-mcp": "./src/servers/dns.js",
"hostinger-vps-mcp": "./src/servers/vps.js",
...
}
Tool counts per server, from src/core/tools/*.js:
| server |
tools |
| all |
396 |
| hosting |
73 |
| vps |
64 |
| reach |
52 |
| domains |
41 |
| agency-hosting / mail / wordpress |
38 each |
| ecommerce |
29 |
| billing |
9 |
| dns |
8 |
| horizons |
6 |
So npx hostinger-api-mcp, which is what the README and most clients will use, loads all 396.
Why it matters
Tool-selection accuracy degrades well before 396 options, and the schemas alone consume a large
share of the context the model needs for the actual task. Your own issue
#3-equivalent problems around tool naming
and #47 around client breakage are
symptoms of the same thing: a very large generated surface arriving at clients that weren't built
for it.
The unusual part is that you already built the fix. Someone who only manages DNS can load 8
tools instead of 396 — but they'd have to read the bin map to discover that.
What I'd suggest
- Point
bin.mcp and main at a smaller default — either a curated core, or make the domain
choice explicit so there is no silent 396-tool path.
- Lead the README with the focused binaries, and present
all as the opt-in for people who
genuinely want everything.
Neither requires new code.
Credit where it's due
I went looking for annotation gaps and didn't find any: all 114 DELETE tools carry
destructiveHint, and nothing is mislabelled. The six POST tools marked readOnlyHint: true
(DNS_validateDNSRecordsV1, domains_checkDomainAvailabilityV1,
reach_previewContactsMatchingConditionsV1, and similar) are semantically correct — they're reads
that happen to take a request body. That's better hygiene than most published MCP servers manage,
which is why the default binary stood out as the one thing worth raising.
I do MCP tool-surface reviews and build guarded servers —
housewarden if the pattern is of interest.
Summary
You ship 11 focused MCP servers and default to none of them.
main,bin.mcpandbin.hostinger-api-mcpall resolve tosrc/servers/all.js, which is the union of everything —396 tools.
What's in the package
From
package.jsoninhostinger-api-mcp@1.61.0:Tool counts per server, from
src/core/tools/*.js:So
npx hostinger-api-mcp, which is what the README and most clients will use, loads all 396.Why it matters
Tool-selection accuracy degrades well before 396 options, and the schemas alone consume a large
share of the context the model needs for the actual task. Your own issue
#3-equivalent problems around tool naming
and #47 around client breakage are
symptoms of the same thing: a very large generated surface arriving at clients that weren't built
for it.
The unusual part is that you already built the fix. Someone who only manages DNS can load 8
tools instead of 396 — but they'd have to read the
binmap to discover that.What I'd suggest
bin.mcpandmainat a smaller default — either a curated core, or make the domainchoice explicit so there is no silent 396-tool path.
allas the opt-in for people whogenuinely want everything.
Neither requires new code.
Credit where it's due
I went looking for annotation gaps and didn't find any: all 114
DELETEtools carrydestructiveHint, and nothing is mislabelled. The sixPOSTtools markedreadOnlyHint: true(
DNS_validateDNSRecordsV1,domains_checkDomainAvailabilityV1,reach_previewContactsMatchingConditionsV1, and similar) are semantically correct — they're readsthat happen to take a request body. That's better hygiene than most published MCP servers manage,
which is why the default binary stood out as the one thing worth raising.
I do MCP tool-surface reviews and build guarded servers —
housewarden if the pattern is of interest.