Atom.com — Premium Domains

get_domain_purchase_pay_link

Read-only

Get a real, payable Machine Payment Protocol (MPP) URL to purchase an ALREADY-LISTED Atom marketplace domain via Stripe SPT (the SPT-paid sibling of register_domain, which pays from an Atom balance instead) — for use with an MPP-native payment agent (e.g. Stripe's link-cli). Use this ONLY when an MPP-native agent's tools (e.g. link-cli's mpp_pay) are available in this session, and only for domains that are curated Atom listings — for a fresh, unlisted domain, use get_domain_register_pay_link instead.

PAYMENT PRIORITY: this is priority 2 for buying a premium/marketplace domain — reach for it only after register_domain (Atom balance, priority 1) reports insufficient funds, and only when link-cli is present. Always hand over the exact server-computed pay_url/price returned here — never estimate or recompute the amount yourself. If link-cli is not available either, use get_checkout_link (priority 3, last resort) instead.

Returns a pay_url that a real HTTP 402 challenge is served from — hand it directly to the MPP agent's pay tool (e.g. mpp_pay) rather than fetching or decoding it yourself.

If this reports error 'registrant_contact_required' (the transfer needs this to complete once paid), ask the user for their name, phone, address, city, zip, and country, call create_registrant_contact with those, then retry this tool — this is expected and not a dead end.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes
`price`	No
`domain`	Yes
`pay_url`	Yes	Real MPP-payable URL — hand this to an MPP agent, do not fetch it yourself.
`success`	Yes
`currency`	No
`expires_at`	No

TDQS

A4.7/5.0

Behavior5/5

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

Annotations mark the tool as read-only, and the description aligns with that by describing a URL-returning operation rather than a mutating purchase. It adds useful behavioral detail beyond annotations: the URL is served from a real HTTP 402 challenge, the caller should hand the pay_url to mpp_pay rather than decode it, and the expected registrant_contact_required error has a defined recovery workflow.

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

Conciseness5/5

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

Though longer than average, every sentence earns its place: purpose, usage conditions, priority ordering, exact-value handling, and error recovery. The main use case is front-loaded, and the detailed fallback instructions are structured clearly with explicit markers like PAYMENT PRIORITY and error-name highlighting.

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?

Given the tool has one parameter, an output schema, and read-only annotations, the description covers the essential operational context an agent needs: when to choose it, what to do with the returned pay_url, and how to recover from the documented error. No critical usage step appears to be missing.

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

Parameters3/5

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

The single domain parameter is already fully described in the input schema, including the 'including extension' detail. The description adds contextual eligibility requirements like 'already-listed' and 'curated Atom listing', but it does not add new parameter-format semantics beyond the schema. This matches the baseline for high schema coverage.

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 states a specific verb and resource: get a real, payable MPP URL to purchase an already-listed Atom marketplace domain via Stripe SPT. It explicitly differentiates itself from get_domain_register_pay_link, which is for fresh unlisted domains, and clarifies its role relative to register_domain's balance-based payment.

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?

Usage guidance is explicit and prioritized: use only when an MPP-native agent's tools are available, only for curated Atom listings, after register_domain reports insufficient funds, and before get_checkout_link as last resort. It also names alternatives and gives a fallback path when link-cli is unavailable.

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

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.

get_domain_purchase_pay_link

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources