Skip to main content
Glama

Check domain availability

check_domains
Read-onlyIdempotent

Bulk-check hundreds of domain names in one call. Returns available, taken, or reserved status plus buy links and prices for free names.

Instructions

Checks whether domain names are free to register. Built for bulk search: almost every good .com is taken, so brainstorm many candidates and pass them ALL in one call - hundreds of names are fine - instead of checking names one by one. Runs on the user's machine: DNS first, then the registry itself (RDAP, or WHOIS where there is no RDAP), in parallel within polite rate limits.

Input: names with or without a TLD. "acme" is tried in every TLD from tlds (default: com, net, ai); "acme.io" is checked exactly as given. URLs work too. For a long list, pass only the TLDs the user wants (e.g. ["com"]): every name is checked in every TLD.

Statuses:

  • available: a registrar API confirmed it can be registered (only when the user set registrar API keys); premium says whether it costs more than the standard price.

  • likely_available: not in the registry or DNS. Premium or registry-reserved names look the same, so the final price is on the registrar's page.

  • taken: registered. May note that it is in deletion and may become available soon.

  • reserved: blocked by the registry, or not sellable according to the registrar.

  • unknown: could not verify right now (rate limit or timeout); try again later.

Free domains come with buy links, cheapest first, with standard per-year prices where public price lists exist, or the exact price when a registrar confirmed the name. When many names are free, the text lists each on one line with its cheapest offer; check the user's favourites again to get every registrar's link.

How to present the answer: list the free domains with their price and their buy link from this result - a table with a link column works well - so the user can register a name in one click. Keep the links; do not replace them with links of your own. Mention the renewal price when it differs from the first year, and any minimum term. Pass on the NOTES and, when present, the affiliate disclosure line.

New names on request: when the user asks to regenerate, or for more or similar names, suggest only names that were not checked before, and pass the domains the user saved in saved so they stay in the results.

Input Schema

NameRequiredDescriptionDefault
tldsNoTLDs to try for names without one, e.g. ["com", "io", "co.uk"]. Omit to use the defaults (com, net, ai); the user can change the defaults with DOMAINSCOUT_TLDS in the MCP server config.
savedNoDomains the user saved in the results panel, e.g. ["acme.com"]. They are checked again with the rest and come back marked saved, so they stay in the results. Pass them whenever the user asks for new names but keeps the ones they saved.
confirmNoConfirm free-looking domains with registrar APIs, which also reveals premium names and exact prices. Works only when the user has set registrar API keys; on by default. Set false to skip it for large lists.
detailsNoInclude the evidence from each source (DNS, RDAP, WHOIS, registrar API) for every domain.
domainsYesNames or domains, e.g. ["acme", "acme.io", "https://acme.dev"]. Pass every candidate in ONE call - hundreds of names are fine. An entry may also hold several names separated by spaces, commas or new lines.

Output Schema

NameRequiredDescriptionDefault
tldsYesTLDs used for names given without one
invalidYes
resultsYes
summaryYes
warningsYesThings that concern the whole call, e.g. a rejected API key or the confirmation limit
disclosureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, open-world, non-destructive, but the description adds substantial behavioral context beyond them: the DNS-then-registry lookup order, parallel execution within polite rate limits, registrar-key dependency for `confirm`/premium detection, and the meaning of each status including why 'likely_available' can hide premium or reserved names and that 'unknown' is a transient rate-limit/timeout state.

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 and bulk-search intent, then organized into clearly scoped sections (Input, Statuses, presentation, regeneration). It is long, but most sentences carry operational weight; the presentation and regeneration paragraphs could be tightened without losing meaning.

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?

An output schema exists, so return structure needn't be re-explained, yet the description still supplies the status taxonomy, pricing/buy-link behavior, and output-handling instructions (keep links, mention renewal price and minimum term, pass on NOTES and affiliate disclosure) that an agent needs to act correctly on the result.

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 100%, so baseline is 3, but the description adds real interpretation rules the schema lacks: bare names like 'acme' are tried in every TLD from `tlds` (default com/net/ai), fully-qualified names like 'acme.io' are checked exactly as given, URLs are accepted, and one entry may contain several names separated by spaces, commas or newlines.

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: 'Checks whether domain names are free to register.' It further narrows the scope by declaring this is built for bulk search, so an agent immediately understands the intended usage mode rather than just the operation.

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?

Explicitly instructs to pass all candidates in ONE call instead of checking one by one, and tells the agent what to do on regeneration requests ('suggest only names that were not checked before, and pass the domains the user saved in `saved`'). It also gives the filtering rule for long lists (pass only the desired TLDs). When/when-not guidance is concrete and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools