aipozi

Check domain availability

check_domain

Read-onlyIdempotent

Is a domain name free? Use it whenever someone names an app, product or company, asks "find me a name with a free domain", "is there a .com for…", or "is X taken". Asks each registry for its own record, live (RDAP, else the registry's WHOIS). One name: across .com, .ai, .io, .app, .dev and more, or the extensions given. Brainstorming: pass up to 10 candidates in names and get them on .com, .ai, .io, .app and .dev, free ones first. Each result: available or not registered (with a registrar link), taken (with its registration date and age), or couldn't check. Free, no sign-in. Always use this for availability; never guess from DNS or memory. aipozi doesn't register names.

Input Schema

Name	Required	Description
`name`	No	One name ("livedot") or a domain ("livedot.ai"). With an extension, only that one is checked unless extensions are given.
`names`	No	Up to 10 candidate names to compare when naming something, e.g. ["livedot", "dotlive", "followdot"]. Checked on .com, .ai, .io, .app and .dev unless extensions are given (up to 6).
`extensions`	No	Extensions to check, e.g. ["ai", "io", "co.za"].

Output Schema

Name	Required	Description
`view`	Yes	What this answer is; "none" for a question back, a plain no, or nothing there yet (see message).
`label`	No	The name searched.
`message`	No	When view is "none": what to tell the person.
`results`	No	{ domain, tld, status: available\|premium\|unregistered\|unavailable\|taken\|unknown, price, registeredAt, ageDays, registerUrl, checkedAt }.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 28, 2026

changedInput schema / properties / name / description

Previous value: -"A name (\"livedot\") or a domain (\"livedot.ai\"). With an extension, only that one is checked unless extensions are given."New value: +"One name (\"livedot\") or a domain (\"livedot.ai\"). With an extension, only that one is checked unless extensions are given."

addedInput schema / properties / names

Added value: +{
+  "description": "Up to 10 candidate names to compare when naming something, e.g. [\"livedot\", \"dotlive\", \"followdot\"]. Checked on .com, .ai, .io, .app and .dev unless extensions are given (up to 6).",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

removedInput schema / required
```
Removed value: -[
-  "name"
-]
```

First observedOct 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the read-only annotations, the description explains that results come live from each registry via RDAP or WHOIS, that the service is free and needs no sign-in, and that aipozi does not register names. It also describes the result categories, including registrar links, registration dates, ages, and uncheckable cases.

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?

The description is front-loaded with the core question and usage conditions, and most sentences add practical value. It is somewhat dense and conversational, but not redundant enough to obscure the main operation.

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?

Given the annotations and output schema, the description covers what an agent needs: when to call it, how it queries registries, what kinds of results to expect, and the important boundary that it only checks availability and does not register names.

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

Parameters3/5

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

Schema coverage is 100%, so the input schema already carries most parameter meaning. The description adds some operational context, such as free names being returned first, but much of the parameter behavior it mentions is already present in the schema field descriptions.

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?

The opening question and subsequent sentences state a specific action and resource: checking whether domain names are available across registries. It is clearly distinct from sibling domain-information tools such as domain_age and domain_rating because the description is entirely about availability, not historical or reputation data.

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?

The description gives concrete triggering scenarios: naming an app, product or company, asking for a name with a free domain, or asking whether a .com exists. It also sets a hard usage rule: always use this tool for availability and never guess from DNS or memory.

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

All aipozi tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.