Skip to main content
Glama

Check domain availability and price

check_domains
Read-only

Checks whether domain names are available, with registration and renewal prices. Answers come from the registry itself: DNS delegation first, then RDAP, with a WHOIS fallback for the registries that publish no RDAP service. A registry that is throttled, timed out or unreachable is reported as unconfirmed, never as available — a raw whois query reports one as available, which is the one wrong answer that costs money. Covers .dev and .app, whose operators run no port-43 whois server at all, and resolves the right registry per extension without being told which. Accepts bare names (expanded across the given extensions) and exact domains (checked as-is). Returns availability, confidence, price, minimum registration term, any eligibility restriction, and where to buy. When a buy link has paid:true, show the response's top-level disclosure sentence alongside it — a commission is earned on that link and the reader is entitled to know before clicking. Each row in prices[] names the registrar it belongs to in vendor — quote the number with that registrar, and link the same one. buy[].url is the link to give; never present check_at[] (estimates only) as a buy link, only as "check availability at"; never compose a registrar URL yourself. Show the link for an available name in the same message as the verdict rather than waiting to be asked, and say so when renewal costs more than the first year or min_term_years makes the first bill a multiple of the price shown. confidence:estimated is not availability — it means no registry answered, usually because one was throttled, so present it as unconfirmed and never as a free name. A result carrying policy.closed is an extension that sells to nobody: it has no price and no buy link, and calling it available offers a name that cannot be bought at any price. When policy carries eligibility, say so before the price — a rule that turns the buyer away at checkout matters more than what they would have paid. Every quoted price is a floor: premium and reserved names return the same registry answer as an ordinary free one and can cost hundreds of times more, so say the price is the standard one rather than promising it. Use for any question about whether a name is free or what it costs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tldsNoExtensions to check bare names against, without leading dots. Choose ones that fit the business: a bakery and an ML startup should not get the same list, and the person asking usually cannot name the extension that suits them because they do not know it exists — call list_tlds to see what is available. A local business usually wants its own country code, e.g. ['de','com'] for Germany. Include 'com' even when something else fits better; it is the one that will be asked about. Omitting this gets a general-purpose set, which is a fallback so the call still works, not a recommendation. Guidance only — any extension list_tlds returns is valid.
namesYesBrand names or exact domains. A name without a dot is checked across every extension in tlds; a name with a dot is checked exactly as given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Far exceeds what readOnlyHint/openWorldHint provide: it names the resolution chain (DNS, RDAP, WHOIS fallback), states that throttled/timeout registries are 'unconfirmed, never available', explains confidence:estimated, policy.closed, eligibility ordering, and the paid:true commission-disclosure obligation. This is unusually rich behavioral context.

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

Conciseness3/5

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

Front-loaded and operationally dense, but the same point is re-made several times — 'unconfirmed never available' and registry throttling appear three times, and output-formatting rules are interleaved with semantics. It is long enough that an agent may skim past the price-floor caveat.

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?

With no output schema, the description compensates fully: it enumerates the return fields (availability, confidence, price, min_term_years, eligibility, buy links, prices[].vendor, check_at[]) and states how each should be presented, including the premium-price floor caveat. Nothing an agent needs to call and report correctly is 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?

Schema description coverage is 100%, so the baseline is 3. The description restates the bare-name vs exact-domain rule that the schema already documents and adds no syntax, format, or constraint detail beyond it; the practical extension-selection advice lives in the schema's own `tlds` description, not here.

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?

Opening sentence states a specific verb and resource ('checks whether domain names are available') plus the added value (registration and renewal prices). It distinguishes itself from the sibling `whois` by explicitly contrasting the raw-query failure mode ('a raw whois query reports one as available, which is the one wrong answer that costs money').

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?

Closes with an explicit routing rule ('Use for any question about whether a name is free or what it costs') and routes the extension-selection sub-problem to a named sibling ('call list_tlds to see what is available'). When-not guidance is implicit but the whois contrast makes the boundary clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources