MCP tools
The DomainRadar tools on the Norcube MCP server. Live single-domain and bulk checks, saved domains, brand-monitor hits, generated names, result fields, and metering.
The Norcube MCP server gives AI agents live domain availability. Language models can only guess whether a domain is free from stale training data; these tools run a real DomainRadar check against DNS, RDAP and WHOIS. Connecting, consent and scopes are covered on the platform page.
| Tool | Shape | Metered |
|---|---|---|
domainradar_check_domain | Synchronous, one domain | Yes |
domainradar_check_domains | Starts a bulk job, returns its id | Yes |
domainradar_get_bulk_check | Job progress + one page of results | No |
domainradar_list_bulk_checks | Your bulk jobs, newest first | No |
domainradar_list_saved_domains | Saved domains + their latest stored check | No |
domainradar_list_brand_watchers | Brand-monitor watchers | No |
domainradar_list_brand_hits | Brand-monitor hits, newest first | No |
domainradar_list_name_jobs | AI name-generation jobs | No |
domainradar_get_name_job | One job + a page of its generated names | No |
All of them need the domainradar.check scope (Check domain
availability on the consent screen). The list tools only read data
your organization already has in DomainRadar; none of them changes
anything.
If the connection covers more than one organization, every tool also
takes an organization argument (the organization id); usage is metered to that
organization. See Organizations.
domainradar_check_domain
Checks one domain and returns the result in the same call.
- Input: the domain (e.g.
example.com), and optionally amode. - Mode: defaults to
verified, a live DNS lookup that falls back to RDAP, with no false positives: if it says available, it's available. The other check modes (bloomfor the fast index-first check,infoandfullfor RDAP/WHOIS detail) work the same as in the API. Ask forinfowhen you also want the registrar and dates.
Bulk checks
For lists, use the asynchronous pair. It's the same pipeline as bulk checks in the dashboard: input is normalized and deduplicated, and the job runs in the background with fair scheduling.
Start: domainradar_check_domains with the list of domains (and
optionally a mode). It returns a job id immediately.
Poll: domainradar_get_bulk_check with the job id. It returns the
job status (processing, completed, cancelled or failed), progress,
and the first page of results.
Page: when there are more results, the response includes a
nextCursor. Pass it back as cursor to domainradar_get_bulk_check
to get the next page (up to 500 results per page with limit, 100 by
default). Keep paging until no nextCursor is returned. The response
also reports done and progress (completed of total) so the agent
knows when the job has finished.
Results arrive in resolution order, not input order, and pages
fill up while the job is still processing. An agent that only needs a
few available names can stop early; one that needs the full picture
should wait for completed. Poll at a modest interval rather than in
a tight loop: you share the MCP server's per-user rate limit, and
DomainRadar limits how many bulk jobs an organization can create per
hour (limits).
Your DomainRadar data
These tools read what you already have in DomainRadar, including things
created in the dashboard. They're free and paged with limit and
cursor / nextCursor.
domainradar_list_bulk_checks: bulk jobs with status, progress and mode, so an agent can pick up a job started earlier and read it withdomainradar_get_bulk_check.domainradar_list_saved_domains: your saved domains with notes and the latest stored check (availability, registrar, expiry). Filter withavailableorsearch. The stored check can be old (see itscheckedAt); rundomainradar_check_domainfor a fresh answer.domainradar_list_brand_watchersanddomainradar_list_brand_hits: your brand monitor watchers and the lookalike domains seen in new TLS certificates, each with a 0–100 score and, when analysed, the AI impersonation verdict. Filter hits bywatcherId,minScoreorsearch.domainradar_list_name_jobsanddomainradar_get_name_job: your AI name generations and their names (stems without a TLD). To find which are free, the agent combines them with TLDs and runsdomainradar_check_domains.
Saving domains, creating watchers and starting a name generation aren't available through MCP yet.
Result fields
Single and bulk results carry the same fields as the API's domain check result:
| Field | Meaning |
|---|---|
| Domain | The normalized domain name. |
| Available | true if it's free to register. |
| Status | available, registered, error, timeout or rate_limited (outcomes). |
| Method | Which source answered (index, DNS, RDAP or WHOIS). This is also what billing follows. |
| Registrar | For registered domains, when the mode and registry provide it. |
| Created / updated / expiry dates | Same. |
| Cache hit | Whether the answer was reused from a recent check. |
| Error | For error / timeout / rate_limited, what went wrong. |
Results do not include registration prices or premium-domain flags. One failed domain never fails the call or the bulk job.
Metering
Only the two check tools are metered; reading results and your stored data is free. MCP checks are ordinary DomainRadar checks: metered by the method that answered, with the same free tier and rates as the dashboard and API, on the organization the call targeted. There's no MCP surcharge. Blocked organizations get a billing error, as everywhere else.
Related
- MCP server: connecting clients, scopes, organizations, errors.
- Check modes: sources, latency and billing per mode.
- Bulk checks: job lifecycle and scheduling.
- Brand monitor: watchers, scores and AI analysis.