Atom.com — Premium Domains

Check domain availability

check_domain_availability

Read-only

Check whether ONE specific, fully-spelled domain is available, taken, or a premium listing. Use whenever a user names a specific domain (e.g. "is acme.com available?", "who owns x.io?", "can I get nova.ai?"). For open-ended "suggest names for my idea" requests use search_brandable_domains instead. If the user wants to PURCHASE a domain they already know is an Atom marketplace listing, use get_domain_details instead — this tool checks fresh-registration availability, which will misleadingly report an already-listed/owned domain as "taken."

Returns: status ("available" = registrable now | "taken" = registered/unavailable | "premium" = for sale on Atom), registrable (bool), price + currency when applicable, estimated_value (rough appraisal, optional), and alternatives[] — when the domain is taken or premium, the closest available premium names from Atom (each with domain, price, url) so the user always has a buyable path.

IMPORTANT — which tool to call next depends on status, and the top-level url means different things accordingly: status "available" (a fresh domain, NOT an Atom marketplace listing) → call register_domain to register it directly in this conversation; its url is a self-service registration page on Atom, only worth mentioning if the user prefers to do it themselves. Status "taken" or "premium" (an existing Atom marketplace listing) → call purchase_domain to buy it directly in this conversation; its url is the marketplace listing page. Never call register_domain for a "premium"/"taken" domain or purchase_domain for an "available" one — each rejects the wrong case with a clear error. Both tools quote a real price breakdown and ask you to state the payment method (Atom balance or saved card) before charging anything. If register_domain reports error registrant_contact_required, that's expected for a fresh domain and not a dead end: ask the user for their name, phone, address, city, zip, and country, call create_registrant_contact with those, then retry register_domain with confirm=true.

Input Schema

Name	Required	Description	Default
`domain`	Yes	The domain to check, including extension, e.g. 'example.com'.

Output Schema

Name	Required	Description
`url`	Yes	Atom URL for this domain.
`price`	No	Price in USD when applicable.
`domain`	Yes
`status`	Yes	available = registrable now; taken = registered/unavailable; premium = for sale on Atom.
`success`	Yes
`currency`	No
`registrable`	Yes	Whether the domain can be registered now.
`alternatives`	No	Closest available Atom premium names when the domain is taken/premium.
`estimated_value`	No	Rough appraisal in USD (optional).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 9, 2026

addedOutput schema / properties / alternatives / items / properties / logo

Added value: +{
+  "description": "Listing logo image URL.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

First observedJun 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Far exceeds the annotations: it defines each status value, enumerates the returned fields (registrable, price + currency, estimated_value, alternatives[]), and explains that the top-level url means different things per status. It also discloses the downstream routing rules and the expected registrant_contact_required error with the recovery path, none of which is derivable from readOnlyHint/openWorldHint.

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

Conciseness3/5

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

Front-loaded well: purpose, examples, then alternatives, then returns. But it spends several sentences on the register_domain / purchase_domain flow and the create_registrant_contact recovery, which is guidance that belongs with those tools and inflates a one-parameter check tool. Some of that text is duplicative of what register_domain and purchase_domain presumably say themselves.

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?

Despite the output schema, the description explains return values and the per-status branching, and it tells the agent exactly which sibling to call next in each case. Nothing needed to call this correctly or act on its result is missing.

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 100%, so the schema already documents the single 'domain' parameter, and an output schema exists. The description still adds meaning by stressing ONE domain, fully spelled, with extension — constraining the agent away from passing lists or bare labels. Only mildly additive given the schema does the rest.

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 and resource (check availability of ONE fully-spelled domain) plus the three outcomes it can return (available, taken, premium). It explicitly distinguishes itself from search_brandable_domains and get_domain_details, so an agent can pick it without opening any schema.

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?

Gives concrete trigger examples ("is acme.com available?", "who owns x.io?") and explicit exclusions with named alternatives for open-ended brainstorming and for purchasing known marketplace listings. The rationale for the exclusion (fresh-registration check misleadingly reports listed domains as taken) makes the boundary unambiguous.

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

All Atom.com — Premium Domains 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.