Skip to main content
Glama

Atom.com — Premium Domains

by com.atom

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

TableJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain to check, including extension, e.g. 'example.com'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesAtom URL for this domain.
priceNoPrice in USD when applicable.
domainYes
statusYesavailable = registrable now; taken = registered/unavailable; premium = for sale on Atom.
successYes
currencyNo
registrableYesWhether the domain can be registered now.
alternativesNoClosest available Atom premium names when the domain is taken/premium.
estimated_valueNoRough appraisal in USD (optional).

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already signal readOnlyHint=true, and the description adds useful behavioral context: it checks fresh-registration availability, may misleadingly report already-listed/owned domains as taken, and explains status semantics and follow-up tools. However, this contradicts the stated 'premium' status definition ('for sale on Atom'), creating genuine confusion about whether an Atom marketplace listing returns 'premium' or 'taken'.

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 purpose, then organized into clear usage, returns, and IMPORTANT follow-up sections. It is longer than strictly necessary, and the contradictory 'taken' sentence should be corrected, but each section carries meaningful operational information for an agent.

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

Completeness4/5

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

The description covers when to use the tool, what status values mean, the alternatives array, which sibling to call next based on status, URL interpretations, and how to recover from the registrant_contact_required error. The only material gap is the unresolved 'taken' vs 'premium' inconsistency, which prevents full contextual completeness.

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 baseline is 3. The description adds value by emphasizing that the domain must be ONE specific, fully-spelled domain and by giving natural-language examples like 'is acme.com available?', which clarify the expected input beyond the schema's brief description.

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 sentence states the exact verb and resource: checking one specific, fully-spelled domain for whether it is available, taken, or premium. It further differentiates from search_brandable_domains and get_domain_details with concrete examples, so an agent can immediately identify this tool's distinctive role.

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 explicit when-to-use guidance ('whenever a user names a specific domain') and names alternatives for other cases, such as search_brandable_domains for open-ended requests and get_domain_details for known Atom purchases. It also provides downstream routing rules, including explicit warnings against calling register_domain for premium/taken domains or purchase_domain for available ones.

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 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation2/5

Several tools serve the same resource+action through different payment channels (e.g., register_domain, register_domain_spt, get_domain_register_pay_link; purchase_domain, get_domain_purchase_pay_link, get_checkout_link; buy_ai_tokens, get_ai_tokens_pay_link). brainstorm_names is explicitly a duplicate of search_brandable_domains, so the set has multiple confusing overlaps despite detailed descriptions.

Naming Consistency4/5

Most tool names follow a predictable snake_case verb_noun pattern (appraise_domain, check_domain_availability, purchase_domain, screen_trademark_conflicts). Minor deviations like brainstorm_names, register_domain_spt, and get_checkout_link break the pattern slightly but remain readable and recognizable.

Tool Count3/5

Sixteen tools is right at the boundary where a tool set starts to feel heavy. Many tools are legitimately needed for discovery, purchasing, and payment routing, but the duplicate name-generation tool and the multiple payment-route variants add unnecessary bulk.

Completeness4/5

The core domain lifecycle is well covered: search/discovery, availability checks, details, appraisal, trademark screening, registrant contact, and both fresh registration and marketplace purchase paths are present. Minor gaps exist around post-purchase management, account balance visibility, and offer submission, but the main user journey has no significant dead ends.

Resources