Loading ToolBench
MCP server for Hostinger API providing tools for domain management, hosting, DNS, billing, WordPress, e-commerce, VPS, mail, and other Hostinger services
The Hostinger MCP server presents a domain management toolkit with consistent naming conventions and proper schema definitions. However, there are significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Tool names follow verb_noun patterns (get_, create_, update_, delete_), which is positive. Descriptions are present but vary in completeness, some include helpful context about rate limits and use cases, while others are minimal. Critical issues: (1) NO parameter descriptions for any tool except the enum values on redirect_type; (2) NO output schema documentation visible in any tool definition; (3) NO error handling or recovery guidance; (4) Missing idempotency hints on non-destructive write operations. Per-tool analysis shows consistent structure (all have inputSchema, descriptions, annotations), but parameter documentation quality is uniformly weak across the board.
Cancel a pending IRTP verification. Use this endpoint to back out of a WHOIS change that is stuck waiting on registrant confirmation, for example when the confirmation email cannot be received, without waiting out the 5-day expiry.
Check availability of domain names across multiple TLDs. Multiple TLDs can be checked at once. If you want alternative domains with response, provide only one TLD and set `with_alternatives` to `true`. TLDs should be provided without leading dot (e.g. `com`, `net`, `org`). Endpoint has rate limit of 90 requests per minute. Use this endpoint to verify domain availability before purchase.
Create domain forwarding configuration. Use this endpoint to set up domain redirects to other URLs.
Delete domain forwarding data. Use this endpoint to remove redirect configuration from domains.
Retrieve domain forwarding data. Use this endpoint to view current redirect configuration for domains.
NO parameter descriptions provided for any tool. Parameters like 'domain', 'tlds', 'limit', 'with_alternatives', 'redirect_type', 'redirect_url' have type definitions but lack descriptions explaining what values are valid, what format is expected, or constraints. For example, 'domain' parameter appears in multiple tools but has no description explaining whether it should include or exclude the TLD.
Output schemas are not documented. The tool definitions in src/core/tools/domains.js show inputSchema but contain NO returnSchema, description of response fields, or documentation of what data structure the LLM should expect back. This forces LLMs to guess what fields are available for downstream tool calls or response parsing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Retrieve a pending IRTP verification for a domain. Both the old and new registrant must confirm it before the WHOIS change takes effect. Use this endpoint to check the status of a WHOIS change awaiting registrant confirmation.
Suggest available domain names based on a free-text description of your project. Suggestions are generated by an AI model, so they differ between calls. Endpoint has rate limit of 90 requests per minute. Use this endpoint to find a domain name when you only know what the website is about.
Suggest available domain names based on a domain name you already have in mind. Suggestions are generated by an AI model, so they differ between calls. Endpoint has rate limit of 90 requests per minute. Use this endpoint when the domain you wanted is taken and you need close alternatives.
Update domain forwarding configuration. Use this endpoint to modify existing redirect configuration for domains.
Retrieve a list of pending and completed domain verifications.
No error handling guidance or recovery hints in tool descriptions. Descriptions do not indicate what errors might occur (e.g., domain not found, rate limit exceeded, invalid domain format, authorization failure) or what the LLM should do next. This violates the recovery-guide pattern.
Destructive operations lack confirmation or dry-run patterns. Tools like domains_deleteDomainForwardingV1 and domains_cancelPendingIRTPVerificationV1 perform irreversible actions but have no confirmation request pattern, dry-run option, or explicit prereq warning in the description.
Parameter 'limit' in suggestion tools (domains_suggestDomainNamesFromADescriptionV1, domains_suggestDomainNamesFromADomainV1) has no description of valid range. No minimum/maximum specified. The rubric requires explicit bounds (e.g., 'limit: 1 - 50') to prevent LLMs from passing absurd values.
Tool 'domains_checkDomainAvailabilityV1' has parameter 'with_alternatives' (boolean) but the description states it only applies when 'provide only one TLD'. This conditional constraint is documented in the tool description but NOT in the parameter description itself, violating the param-relationships pattern.
Tool naming ambiguity: 'domains_suggestDomainNamesFromADescriptionV1' vs 'domains_suggestDomainNamesFromADomainV1' differ by only 'Description' vs 'Domain'. While technically distinct, LLMs may conflate them or struggle to select the correct one without re-reading descriptions. Consider more explicit names like domains_suggestFromDescription vs domains_suggestFromSimilarDomain.