---
name: atom-domains
description: Find, appraise, and buy or register premium domain names through Atom.com's MCP server. Two separate purchase tools - register_domain for a fresh domain, purchase_domain for an already-listed marketplace domain - each paid from the user's Atom balance, a saved card, or a connected MPP agent, with a clear price breakdown shown before charging. Use when a user wants to name a business or product, find a brandable or premium domain, check domain availability, value a domain, screen trademark conflicts, or buy/register a domain on their behalf.
---

# Atom.com Domains

Atom (https://atom.com) is a curated premium domain marketplace and accredited registrar. This skill teaches you to use Atom's MCP server for domain discovery and purchase.

## Connect

MCP endpoint (Streamable HTTP, MCP spec 2025-03-26, JSON responses):

```
POST https://mcp.atom.com/mcp
```

- `search_brandable_domains` is open and anonymous - no auth needed. Start here for name discovery.
- `get_domain_register_pay_link_guest` and `get_domain_purchase_pay_link_guest` are also open and anonymous - no OAuth needed, ever (`scope: null`).
- Every other tool requires OAuth 2.1 (`WWW-Authenticate: Bearer resource_metadata="..."` on a `401`, pointing to `https://mcp.atom.com/.well-known/oauth-protected-resource`; DCR supported).

## Decide first: authenticated or guest? (read this before Discovery workflow)

Atom's MCP server has no `whoami`/`auth_status` tool and no session-wide "authenticated" flag -
the server only checks, per call, whether THAT call carries a valid token for THAT tool's scope.
So never call a gated tool (`check_domain_availability`, `register_domain`, `get_domain_details`,
etc.) just to probe whether you're authenticated - decide first, with this rule:

> **Has a normal gated Atom tool already succeeded in THIS conversation, on THIS connector?**
> - **Yes** -> authenticated. Use Discovery workflow / Buying / MPP below as normal - nothing
>   there changes.
> - **No** - including the first domain-related turn of a fresh conversation, a connector whose
>   name contains "guest"/"test" (e.g. `atom-guest`, `atom-guest-test1`), or the user saying
>   there's no Atom login here - -> this is the **guest path**: see "No Atom account at all?"
>   near the end of this doc. Go straight there for a register/purchase request. Do not call
>   `check_domain_availability`/`get_domain_details`/`register_domain` first "to check," and do
>   not wait for a 401 to decide - the MCP client may turn that 401 into an unrecoverable
>   "please authenticate" state before you get another turn.

Once on the guest path: **OAuth is not a topic.** Never say authentication is required, never
print/link an `oauth/authorize` URL, never tell the user to run `/mcp` or sign in, and never
present OAuth as "step 1" with the guest tool as a fallback/"meanwhile" option. There is no other
option once this rule says guest - go straight to collecting buyer/registrant info and calling the
guest tool, per "No Atom account at all?" below.

The only exception: if a call you made *because a gated tool had already succeeded* unexpectedly
401s later in the same conversation, don't ask the user to re-authenticate and wait - silently
switch to the guest path from that point on.

## Discovery workflow (authenticated path)

1. **Search curated inventory**: `search_brandable_domains` with a natural-language brief ("AI fintech startup, short, modern"). Returns buyable premium listings with real prices - these are all marketplace listings, buy them with `purchase_domain`. Never invent domain names - unverified names are almost always taken.
2. **Check a specific domain**: `check_domain_availability` tells you which tool applies next - status `available` (a fresh, never-listed domain) -> `register_domain`; status `taken` or `premium` (an existing Atom marketplace listing) -> `purchase_domain`. Its `url` matches: a self-service `/register/{domain}` page for `available`, the real marketplace listing page otherwise - only worth mentioning if the user prefers to complete it themselves. Use `get_domain_details` for a deep-dive on one listing.
3. **Generate registrable names**: `generate_domain_names` for invented/made-up names verified available - register these with `register_domain`.
4. **Value**: `appraise_domain` returns an estimate with reasoning and comparable sales. Always present it as an estimate.
5. **Trademark**: `screen_trademark_conflicts` runs a preliminary USPTO screen - surfaces potential conflicts only, not legal advice.

## Buying - two separate tools, never one "figure it out" catch-all

- **`register_domain`** - STRICTLY for a fresh domain (status `available`). Registers it directly at
  the registrar. Price = registration_fee + VAT where applicable (term_years is derived from the TLD,
  never a caller input). Calling it on a marketplace listing fails with `is_marketplace_listing`.
- **`purchase_domain`** - STRICTLY for an already-listed Atom marketplace domain (status
  `premium`/`taken`). Price = sale_price + registration_fee (conditional) + VAT where applicable.
  Calling it on a fresh domain fails with `not_a_marketplace_listing`.

Both use the same quote -> confirm flow, and both accept exactly two payment methods that YOU must
state explicitly - never guessed or silently chosen. There is also a third path when neither of
these is available: a connected MPP-native agent (e.g. Stripe's `link-cli`) - see below.
- `payment_method: "balance"` - debits the user's Atom account balance.
- `payment_method: "saved_card"` - charges their saved/default card on file directly (no redirect,
  no extra tool).
- If neither applies (balance is too low and no saved card), check for a connected MPP agent (e.g.
  `link-cli`, exposing an `mpp_pay` tool) before asking the user to choose a payment method - see
  "No Atom balance or saved card?" below.

1. Call with `confirm=false` to get a quote: authoritative price **with its breakdown**
   (`register_domain`: unit_price + icann_total + vat_amount; `purchase_domain`: sale_price +
   registration_fee + vat_amount), the user's current `balance`, `sufficient_funds`, and whether they
   have a saved card (`has_saved_card` / `saved_card`).
2. **State the breakdown and the exact payment method + amount to the user before charging anything**
   - e.g. "$19.98 (domain $17.99 + ICANN fee $1.99) from your Atom balance" or "...from your saved
   Visa ending 4242." Get explicit confirmation.
3. Call again with `confirm=true`, the same `idempotency_key`, and `payment_method` set to exactly
   `"balance"` or `"saved_card"` - required, not optional. Returns the amount actually charged, which
   payment method was used, and the result (`registrar_domain_id` for a registration,
   `order_id`/`order_url` for a purchase). On success the domain shows up in the user's Atom account.

Handling the outcomes:
- **Insufficient balance** (`payment_method: "balance"`): error `insufficient_funds` returns
  `top_up_url` and whether a saved card exists (`has_saved_card`) as an alternative - tell the user
  both options plainly; don't silently retry with the other method yourself. Also check whether a
  connected MPP agent is available (see "No Atom balance or saved card?" below) - if so, that's a
  third option to mention alongside top-up and saved card.
- **Card charge failed** (`payment_method: "saved_card"`): error `card_payment_failed` explains why,
  including if it needs 3D Secure authentication (can't be completed here - offer balance or a
  different card instead).
- **Registrant contact** (`register_domain` only - a registry requires this): if it reports
  `registrant_contact_required`, call `create_registrant_contact` with the user's name, phone,
  address, city, zip, and country, then retry with `confirm=true`.

## No Atom balance or saved card? (MPP / link-cli / checkout link)

`register_domain`/`purchase_domain` above cover a user with funds already on their Atom account.
If neither payment method applies - no balance, no saved card, or the caller is itself a
payment-capable agent rather than a human with an Atom login - try these instead. Always hand over
the exact server-computed price/pay_url; never estimate or recompute an amount yourself.

1. **MPP pay link** - when an MPP-native payment agent is available in this session (e.g. Stripe's
   `link-cli` and its `mpp_pay` tool): call `get_domain_register_pay_link` (fresh domain) or
   `get_domain_purchase_pay_link` (already-listed marketplace domain) to mint a real, payable
   Machine Payment Protocol URL - a genuine HTTP 402 challenge, not a JSON echo. Hand the returned
   `pay_url` directly to the MPP agent's pay tool; don't fetch, decode, or pay it yourself. The
   registration or purchase itself fires automatically the moment that agent reports payment
   success - no further tool call from you is needed to complete it.

   If no MPP agent is present in this session, tell the user they can install and connect one:
   ```
   npm install -g @stripe/link-cli
   link-cli mcp add --agent claude-code
   link-cli auth login
   ```
   Once connected, retry from the top of this section.
2. **`get_checkout_link`** (marketplace domains only, last resort) - when no MPP agent is present
   and the user doesn't want to set one up, this returns a plain, pre-filled Atom checkout URL for
   the user to pay themselves in a browser where they're already logged into atom.com. It charges
   nothing itself, and there is no equivalent fallback for a fresh registration.

## No Atom account at all? (Guest checkout via MPP)

Reached from "Decide first" above once the guest path applies. Requires an MPP-native payment
agent in this session (e.g. Stripe's `link-cli`, exposing `mpp_pay`) - if none is present, tell
the user it's required (same install snippet as the MPP section above, then `link-cli auth
login`) and stop; don't fall back to any OAuth-gated tool instead, since none of them work here.

- **`get_domain_register_pay_link_guest`** - fresh, unregistered domain.
- **`get_domain_purchase_pay_link_guest`** - already-listed Atom marketplace domain.

Both skip OAuth entirely and take the end buyer's identity directly as call arguments instead of a
token: `buyer_email`, plus registrant (WHOIS) contact - `name`, `phone`, `address`, `city`, `country`
required, `state`/`zip`/`organization` recommended. Never invent these - ask the user. Tell them
plainly: Atom creates (or reuses) a real Atom account under that exact email, the domain lands
there, and an account-claim email is sent to that address afterward - the calling agent/platform can
never claim that account itself.

Both already re-check availability and pricing server-side, so don't call `check_domain_availability`
or `get_domain_details` first here - they require OAuth and will 401 in this session; nothing is
gained by trying them first. Hand the returned `pay_url` straight to the MPP agent's pay tool (e.g.
`mpp_pay`), exactly as in the MPP path above - never fetch, decode, or pay it yourself, and never
reuse a `pay_url`/`challenge_id` across attempts.

On a failure after a successful charge, most named failure branches (domain no longer available,
price mismatch, registrant contact missing, not-for-sale/not-purchasable, order-creation failure,
registrar submission failure) trigger a real Stripe refund automatically - report the tool result's
`refunded` field and message rather than assuming either way.

## Rules

- Always show the price breakdown and state the payment method + amount before calling confirm=true. Never chain a search result directly into a purchase.
- Present prices exactly as returned; availability and pricing change frequently - do not present cached results as current.
- Respect `429` responses and their `Retry-After` header.