AI agents can write code, deploy it, and monitor it. But the moment an agent needs its own domain, everything stops. A human opens a browser, fills a form, solves a captcha, and types a card number.
That last human step is the one we removed.
AIvikings is a domain registrar built for agents first. The REST API is the product. The MCP server is the front door. There is no signup funnel designed for human eyeballs, no upsell page for hosting or email. One job: domains, done programmatically.
This post walks through the MCP server, what the tools look like from inside an agent, and why we think domains for agents are a different product than domains for people.
The entire tool surface
When an MCP client connects to https://mcp.aivikings.ai and calls tools/list, it gets exactly seven tools:
check_domain_availability Is this domain available?
register_domain Register a domain to your account
get_domain_status Lifecycle state of one domain
list_domains All domains on the account
renew_domain Extend a registration
update_nameservers Point the domain at your infrastructure
reconcile_domains Sync local state with registry truth
That is the whole registrar. No tool sprawl, no 40-tool context bloat. An agent loads the full capability set in a few hundred tokens and gets on with its task.
[DIAGRAM 1 - the flow]
+-----------+ MCP (streamable HTTP) +------------------+
| | ----------------------------------> | |
| Your | check_domain_availability | AIvikings |
| AI agent | register_domain | MCP server |
| (Claude, | update_nameservers | mcp.aivikings.ai|
| ChatGPT, | <---------------------------------- | |
| custom) | JSON results +--------+---------+
+-----------+ |
v
+------------------+
| Registry |
| (real WHOIS- |
| verifiable |
| registrations) |
+------------------+
Connecting takes one config block
For any MCP-compatible client:
{
"mcpServers": {
"aivikings": {
"url": "https://mcp.aivikings.ai"
}
}
}
Auth is OAuth 2.1 with Dynamic Client Registration, so clients like ChatGPT can connect without pre-shared secrets. Machine workloads can use bearer tokens instead.
What an agent actually does with it
Say an agent has just shipped a small service and needs an endpoint of its own. The conversation between the agent and the registrar looks like this.
Step 1: the agent checks availability. Note the domain - 23 characters, on .icu. No human would ever type this. No human has to.
// tool call
{
"name": "check_domain_availability",
"arguments": { "domains": ["inventory-sync-agent-eu7.icu"] }
}
// result
{
"domains": [
{
"domain": "inventory-sync-agent-eu7.icu",
"available": true
}
]
}
Step 2: it registers.
// tool call
{
"name": "register_domain",
"arguments": {
"domain": "inventory-sync-agent-eu7.icu",
"period_years": 1
}
}
// result
{
"domain": "inventory-sync-agent-eu7.icu",
"status": "registered",
"expiry": "2027-06-08T23:59:59"
}
Step 3: it points the domain at its own infrastructure.
// tool call
{
"name": "update_nameservers",
"arguments": {
"domain": "inventory-sync-agent-eu7.icu",
"nameservers": ["ns1.example-dns.net", "ns2.example-dns.net"]
}
}
Three tool calls. The registration is real and shows up in WHOIS. KeyDNS nameservers are applied by default when the agent does not provide its own DNS, so the agent can skip step 3 entirely if the default setup is enough.
Why long domains are the tell
Here is the part most registrars get backwards. The entire domain industry prices and markets domains for human memory. Short is premium. Brandable is premium.
Agents do not have that constraint. An agent needs a globally unique, machine-resolvable identifier. inventory-sync-agent-eu7.icu can be exactly as useful to an agent as a four-letter .com, with pricing designed for machine-scale use.
So we price long domains (15+ characters) for machines, not for human vanity. On TLDs like .icu, .sbs, and .cfd, an agent can register the identifier it needs while keeping the address layer low priced. That is not the headline of AIvikings. It is the proof that the product was designed for agents from the first line of code, not retrofitted with an API later.
No MCP client? Use the REST API
Everything the MCP server does is also plain HTTPS at https://api.aivikings.ai/v1:
import httpx
API = "https://api.aivikings.ai/v1"
headers = {"Authorization": "Bearer YOUR_API_KEY"}
with httpx.Client(base_url=API, headers=headers) as client:
# Check availability
r = client.post("/domains/check", json={"domains": ["fleet-router-042.sbs"]})
if r.json()["domains"][0]["available"]:
# Register it
r = client.post("/domains", json={
"domain": "fleet-router-042.sbs",
"period_years": 1
})
print(r.json()) # {"domain": "fleet-router-042.sbs", "status": "registered", ...}
That is the whole integration for a LangChain tool, a CrewAI task, or a cron job. Full reference at docs.aivikings.ai.
It also works from a chat window
The same MCP server is exposed as a ChatGPT connector. A non-developer can say "find and register a domain for my pottery project" and the registration happens end to end in the conversation. Same seven tools, different front end.
[DIAGRAM 2 - one server, three doors]
ChatGPT connector MCP clients REST API
| | |
+----------+----------+--------+--------+
| |
v v
mcp.aivikings.ai api.aivikings.ai/v1
\ /
+--------+--------+
|
one registrar core
Try it
Point your MCP client at https://mcp.aivikings.ai, or grab an API key and hit https://api.aivikings.ai/v1. Docs at docs.aivikings.ai.
If you are building agents that need their own infrastructure, we want to hear what breaks. The registrar is designed around low-priced long domains agents actually need, and the API will stay the product.