Skip to main content
Glama
hostinger

hostinger-api-mcp

Official
by hostinger
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Remote

Complete domain setup

domains_completeDomainSetupV1

Register a domain already paid for but awaiting setup by completing missing contact or TLD details, using the existing subscription without new payment or order.

Instructions

Register a domain you have already paid for but which has not been set up yet.

Use this endpoint when an order completed without registering the domain, for example when Purchase new domain returned 202 Accepted and the domain was added to your account without being registered, or when an earlier setup attempt failed. No new order is placed and no payment is taken: the subscription you already own is used, for the period you already paid for.

A domain is left awaiting setup when the details needed to register it were missing or invalid as the order completed. Domains ordered elsewhere can be awaiting setup for the same reason. Complete the missing information, then call this endpoint. If the order itself has not completed yet, the domain is not on your account, wait until it appears in Get domain list.

If domain_contacts is omitted, the default WHOIS profile of that TLD is used for all four roles. The profile must exist and be complete for the TLD, an incomplete profile is the most common reason a domain is left awaiting setup. Create one with Create WHOIS profile.

Some TLDs require additional_details. These are validated before setup, so a missing or invalid value is rejected without any registration being attempted.

The domain is set up with the default nameservers and without privacy protection. Use Update domain nameservers and Enable privacy protection afterwards to change either.

A successful response means the setup request was accepted, not that the domain is already registered. Poll Get domain list for the outcome, the domain appears in Get domain details only once it is registered.

Use this endpoint to finish registering a domain that is awaiting setup on your account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesDomain name
domain_contactsNoDomain contact information
additional_detailsNoAdditional registration data, possible values depends on TLD

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.59.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the readOnlyHint=false/destructiveHint=false annotations: no new order is placed and no payment is taken, the existing subscription is used, setup uses default nameservers without privacy protection, additional_details are validated before any registration is attempted, and a success response means accepted—not registered—so polling is required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded—the core purpose and the 202-Accepted trigger come first, with prerequisites and caveats following. It is on the verbose side and the closing sentence largely restates the opening, which costs a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating no-output-schema endpoint, the description covers everything an agent needs: preconditions, alternative fields/fallbacks, validation caveats, side effects (default NS, no privacy), and how to confirm the eventual outcome elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds real semantics: omitting domain_contacts falls back to the TLD's default WHOIS profile for all four roles, that profile must exist and be complete (a common failure cause), and additional_details is TLD-dependent and pre-validated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Register a domain you have already paid for but which has not been set up yet') and clearly distinguishes this from purchase/setup flows among the many domains_* siblings. The agent knows exactly which state of the world this tool operates on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly enumerates when to call it (order completed without registering, purchase returned 202 Accepted, earlier setup attempt failed) and when not to (if the order itself has not completed, wait until the domain appears in Get domain list). It also names the follow-up tools for changing nameservers/privacy and the WHOIS profile creation tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools