Atom.com — Premium Domains

Get domain purchase Coinbase (USDC) pay link

get_domain_purchase_coinbase_pay_link

Read-only

Get a Coinbase checkout link, paid in USDC, to purchase an ALREADY-LISTED Atom marketplace domain. Returns two URLs for the same payment: x402_url — an agent with an x402-capable crypto wallet (e.g. a Coinbase agentic wallet) pays it directly (POST, 402 Payment Required, signed retry); and checkout_url — the hosted page a human opens in a browser to pay with their own wallet. Use this when the user wants to pay with crypto/USDC, or when an x402-capable wallet is available in this session. For a fresh, unlisted domain use get_domain_register_coinbase_pay_link instead.

Always present the exact server-computed price returned here (it includes any registration fee, VAT and the Coinbase processing fee) — never estimate or recompute it yourself. This tool charges nothing by itself.

RIGHT AFTER handing over the link (or paying x402_url), start polling get_coinbase_payment_status with the returned payment_code — keep calling it while status is 'pending' and stop_polling is false (each call waits ~10s server-side). If stop_polling turns true, stop and show its user_message exactly as given; check again when the user says they have paid. The domain is only purchased once that reports status 'completed'.

If this reports error 'registrant_contact_required', ask the user for their name, phone, address, city, zip, and country, call create_registrant_contact with those, then retry. If it reports 'billing_country_required', the user must save a billing country on their Atom account first.

Input Schema

Name	Required	Description	Default
`domain`	Yes	The listed domain to purchase, including extension.

Output Schema

Name	Required	Description
`url`	Yes
`price`	No	Exact total the checkout charges.
`domain`	Yes
`success`	Yes
`currency`	No
`x402_url`	No	x402 payment endpoint for agent wallets: POST it, get 402 Payment Required, sign and retry. Prefer this over checkout_url when an x402 wallet is connected.
`sale_price`	No
`vat_amount`	No
`checkout_url`	Yes	Hosted Coinbase checkout page — give this to a human to pay in a browser.
`payment_code`	Yes	Pass to get_coinbase_payment_status after paying.
`processing_fee`	No
`registration_fee`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 1, 2026

changedOutput schema / properties / checkout_url / description

Previous value: -"Coinbase checkout URL (x402-payable). Hand to an x402 wallet or the user."New value: +"Hosted Coinbase checkout page — give this to a human to pay in a browser."

addedOutput schema / properties / x402_url

Added value: +{
+  "description": "x402 payment endpoint for agent wallets: POST it, get 402 Payment Required, sign and retry. Prefer this over checkout_url when an x402 wallet is connected.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

AddedSep 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description stays consistent while adding substance: 'This tool charges nothing by itself', the domain is only purchased once polling reports 'completed', and the x402_url contract (POST, 402 Payment Required, signed retry) is spelled out. It also discloses that each status call blocks ~10s server-side and that stop_polling/user_message must be surfaced verbatim — details unavailable from annotations.

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 core selection criteria and the x402_url vs checkout_url distinction are front-loaded, and the operational sequence and error branches follow in a usable order. It is lengthy, but nearly every clause is functional; a small amount of the polling prose could be tightened without loss.

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?

Although an output schema exists, the description still characterizes both returned URLs by audience (agent vs human) and covers the full lifecycle: price must be presented verbatim, nothing is charged here, purchase completes only on 'completed' status, and both registrant_contact_required and billing_country_required failures have recovery paths. Nothing an agent needs to call this correctly 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?

With a single parameter at 100% schema coverage, the schema already carries the syntax ('including extension'). The description still adds a real semantic constraint the schema cannot express: the domain must already be listed on the marketplace, otherwise a different tool applies.

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 description names a specific verb and resource (get a Coinbase/USDC checkout link) plus the exact scope constraint: an ALREADY-LISTED Atom marketplace domain. It explicitly separates itself from the sibling that handles the other case (get_domain_register_coinbase_pay_link for a fresh, unlisted domain), so an agent can route 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?

It states the selecting conditions directly — 'when the user wants to pay with crypto/USDC, or when an x402-capable wallet is available in this session' — and names the alternative for the unlisted case. It goes further with the required follow-up (poll get_coinbase_payment_status with the returned payment_code) and the two error-code branches with their remediation steps.

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.