Atom.com — Premium Domains

Purchase a marketplace domain

purchase_domain

Destructive

Purchase an ALREADY-LISTED Atom marketplace domain. This SPENDS REAL MONEY and requires the 'domains:register' scope. Use this ONLY when check_domain_availability reported status 'premium' or 'taken' (a curated Atom listing) for this exact domain, or get_domain_details confirmed it's a listing. If the domain is instead fresh/never-listed (status 'available'), use register_domain instead — never this tool; it will reject a fresh domain with error 'not_a_marketplace_listing'.

MANDATORY two-step flow — never skip the quote:

Call with confirm=false (default) to get a QUOTE: returns the authoritative price, its breakdown (sale_price, registration_fee, vat_amount), the user's current balance, sufficient_funds, whether a saved card exists (has_saved_card / saved_card), and expires_at.
SHOW THE USER: the exact price breakdown, and state plainly which payment method you are about to use and how much it will charge — e.g. "$1,250.00 (listing price $1,200 + $50 registration fee) from your Atom balance" or "...from your saved Visa ending 4242". Get explicit confirmation before proceeding.
Call again with confirm=true, the SAME idempotency_key, and payment_method set to exactly 'balance' or 'saved_card' (REQUIRED at this step — never omit it or guess): commits the charge and the purchase. Returns status='purchased', amount_charged, payment_method, order_id, and order_url.

Rules: never assume or pass a price. Reuse one client-generated idempotency_key across both calls (and any retry) to prevent double-charging. If payment_method='balance' and funds are insufficient, error 'insufficient_funds' reports required/available/top_up_url and whether a saved card exists as an alternative — tell the user both options plainly, do not silently retry with the other method. If payment_method='saved_card' and the charge fails, error 'card_payment_failed' reports why (including if it needs 3D Secure authentication, which cannot be completed here — offer balance or a different card instead). If it reports error 'registrant_contact_required' (a marketplace-domain transfer needs this to complete), ask the user for their name, phone, address, city, zip, and country, call create_registrant_contact with those, then retry with confirm=true — this is expected and not a dead end.

Input Schema

Name	Required	Description
`domain`	Yes	The Atom marketplace listing to purchase, including extension.
`confirm`	No	false returns a quote; true commits the charge and purchase (payment_method required).
`payment_method`	No	Which rail to charge. REQUIRED when confirm=true — state this to the user before calling, never picked automatically. Ignored (and unnecessary) at the quote stage.
`idempotency_key`	Yes	Client-generated unique key; identical across the quote and confirm calls for the same intended purchase. Prevents double-charging on retry.

Output Schema

Name	Required	Description
`url`	Yes
`price`	No	Authoritative total price in USD (quote stage).
`stage`	Yes	'quote' = price for confirmation; 'committed' = purchase completed.
`domain`	Yes
`status`	No	Purchase status (committed stage).
`balance`	No	User's current Atom balance (quote stage).
`success`	Yes
`currency`	No
`order_id`	No	Atom marketplace order id (committed stage).
`breakdown`	No	Price components (quote stage): sale_price, registration_fee, vat_amount.
`next_step`	No	How to complete the purchase (quote stage).
`expires_at`	No	Quote expiry (quote stage).
`saved_card`	No	{brand, last4} of the saved card, if any (quote stage).
`amount_charged`	No	Amount actually charged in USD (committed stage).
`has_saved_card`	No	Whether the user has a saved/default card on file (quote stage).
`payment_method`	No	Which rail was actually charged (committed stage).
`idempotency_key`	No
`sufficient_funds`	No	Whether balance covers the price (quote stage).

Schema Changelog

Changes observed during successful MCP inspections.

AddedAug 28, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds far more: real money is spent, the 'domains:register' scope is required, a mandatory quote-before-charge flow, idempotency_key reuse to prevent double-charging, and specific error contracts (insufficient_funds, card_payment_failed, registrant_contact_required) with the instruction not to silently retry on another rail.

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?

Front-loaded with the critical constraint (real money, correct tool), then structured as a numbered mandatory flow with rules last. Nearly every sentence is load-bearing, though the literal price-breakdown example and the enumerated error catalog make it longer than strictly necessary.

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?

For a destructive, money-spending tool with an output schema already covering return values, the description still covers preconditions, the confirmation UX contract, payment method selection, and every documented failure path including the registrant_contact_required detour. Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is 100%, so baseline would be 3, but the description adds flow-level meaning the schema cannot: payment_method is meaningless at the quote stage and mandatory at confirm, and one client-generated idempotency_key must be reused across quote, confirm, and retries. That is genuine semantics beyond the 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?

States a specific verb+resource ('Purchase an ALREADY-LISTED Atom marketplace domain') and immediately draws the boundary against the nearest sibling, register_domain, including the exact error a fresh domain would yield. An agent can distinguish this from register_domain without opening either 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 explicit entry conditions (check_domain_availability reported 'premium' or 'taken', or get_domain_details confirmed a listing), explicit exclusions ('If the domain is instead fresh/never-listed ... use register_domain instead — never this tool'), and names the alternative tool twice. This is the when/when-not/alternative trifecta.

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.