Atom.com — Premium Domains

Create website

create_website

Destructive

Build a real website, with a logo, for a business on a domain in the user's Atom account, and optionally put it live. Use when the user wants to launch a website, including right after registering a domain.

MANDATORY flow:

BEFORE any payment, call with confirm=false and the description (no domain needed). This costs nothing. It refuses sites Atom won't build (error content_not_allowed: tell the user the message and do NOT register a domain for it) and returns questions[] for details still missing, such as address and opening hours for a business people visit.
Ask the user those questions ONCE, in one message, together with any registrant contact details the registration needs. If they skip something, carry on: that section is left out. Never invent answers.
Register the domain and wait until it completes (for USDC: get_coinbase_payment_status reports completed).
Call with confirm=true, the domain, business_name exactly as the user wrote it (domains lose their capitals and spaces, and this is the text on the logo), and answers{} keyed by the question ids. Set publish=true only if the user asked for the site to go live; otherwise it stays a private preview.
Keep calling get_website_status until stop_polling is true, then give the user the live_url or preview_url, the edit_url, and show the logo_url.

If this reports error 'listed_for_sale', ask the user, because going live removes the listing; if they agree, retry with confirm_delist=true.

Only the owner can open preview_url. Do not describe the logo as unique or safe to trademark: screen_trademark_conflicts checks a name, not artwork.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "description": "<description>"
    },
    "name": "create_website"
  }
}

Input Schema

Name	Required	Description	Default
`email`	No	Contact email to show on the site, if the user gave one.
`phone`	No	Contact phone to show on the site, if the user gave one.
`domain`	No	Required when confirm=true. A domain active in the user's Atom account.
`answers`	No	Answers keyed by question id: audience, offer, difference, proof, goal, address, service_area, hours, booking (with any booking link), socials (profile links or handles with the network named), shop.
`confirm`	No	false checks the idea and returns questions; true builds the site.
`publish`	No	true puts the site live on the domain. Only when the user asked for that.
`logo_url`	No	A full https link to the logo the user already has. Skips making one.
`site_type`	No		website
`logo_style`	No	Optional style for the logo in a few words, such as hand drawn.
`description`	Yes	What the business does and what the site is for, in the owner's words. At least 20 characters.
`business_name`	No	Required when confirm=true. The name exactly as the user wrote it, such as NY Warm Buns.
`confirm_delist`	No	The user agreed to remove the domain from sale on Atom.

Output Schema

Name	Required	Description
`url`	Yes
`stage`	Yes
`domain`	No
`message`	No
`success`	Yes
`presence`	No	local, online or both.
`can_build`	No
`next_step`	No
`questions`	No
`stop_polling`	No
`business_name`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond annotations (destructiveHint=true, openWorldHint=true), it discloses that confirm=false costs nothing, that it refuses disallowed content with a specific error, that it returns questions[], that preview_url is owner-only, and that 'listed_for_sale' requires explicit user consent before confirm_delist. It even warns not to over-claim the logo's uniqueness.

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 purpose before the numbered flow, and each step carries non-obvious operational detail rather than filler. It is long, but the length tracks genuine multi-step complexity; a few clauses (the trademark caveat) sit slightly apart from the core flow.

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 12-parameter destructive, open-world tool with a nested answers object, the description covers prerequisites, error paths, consent gates, and post-call polling. An output schema exists, yet the description still names the key artifacts (live_url, preview_url, edit_url, logo_url) an agent must relay.

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 92%, so the schema already documents most fields, but the description adds real meaning: the confirm=false/true two-phase contract, that business_name must be verbatim user wording because it becomes the logo text, and that answers{} is keyed by returned question ids. It does not restate site_type, logo_style, or email/phone, which are handled by the enum and schema text.

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 gives a specific verb and resource ("Build a real website, with a logo") plus scope (on a domain in the user's Atom account, optionally live). It is clearly distinguishable from siblings like regenerate_website_logo or get_website_status, which appear elsewhere in the flow.

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 explicitly when to use it ("when the user wants to launch a website, including right after registering a domain") and sequences it against siblings: register_domain must complete first, get_coinbase_payment_status gates USDC, get_website_status polls afterward. It also gives exclusions, such as not registering a domain when content_not_allowed fires.

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.