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 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.

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses data source order (DNS delegation, RDAP, WHOIS fallback) and the unconfirmed result for throttled registries, beyond the readOnlyHint. It details confidence:estimated semantics, policy.closed handling, and the price-floor caveat for premium names. It also provides precise instructions about buy links and commissions, which the annotations do not cover.

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?

The description is lengthy but each section adds necessary behavior guidance, especially given the lack of an output schema. It is front-loaded with the core purpose, then method, then edge cases and presentation rules. Some sentences are repetitive (e.g., the closing use-case sentence), but no fluff dominates.

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 by detailing the return fields (availability, confidence, price, min term, eligibility, buy link) and special cases like paid:true, policy.closed, and confidence:estimated. It covers parameter behavior, data source reliability, and pricing caveats, making it a complete reference for invocation and interpretation.

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?

The input schema already covers both parameters with 100% description coverage, so the baseline is 3. The description adds meaning by explaining that bare names are expanded across tlds while exact domains are checked as-is, and that the tool resolves the right registry without being told which. This enriches the names and tlds parameters beyond the schema.

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 clearly states the tool checks domain availability and registration/renewal prices, with a specific verb and resource. It distinguishes itself from the raw whois sibling by explaining it resolves the correct registry per extension and covers .dev/.app, which have no port-43 whois. The final sentence explicitly states its use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Use for any question about whether a name is free or what it costs,' providing a clear invocation trigger. It contrasts with raw whois by warning that a raw whois query can falsely report availability when registries are throttled, implying this tool should be preferred. It also references list_tlds in the schema for choosing extensions, but does not explicitly name alternatives in the main description.

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.

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: check_domains checks availability and pricing, list_tlds enumerates supported extensions, and whois retrieves registry records. No overlap in functionality, and descriptions reinforce the boundaries.

Naming Consistency4/5

Two tools follow a clear verb_noun pattern (check_domains, list_tlds), while whois is a conventional standalone command rather than a verb_noun phrase. This is a minor deviation and does not create confusion.

Tool Count5/5

Three tools is an appropriate scope for a domain information server, covering the core operations (list, check, whois) without unnecessary redundancy. Each tool serves a distinct and necessary function.

Completeness5/5

The surface covers the expected operations for domain availability and registration data: discovering supported TLDs, checking availability with pricing, and retrieving full registry records. There are no obvious dead ends or missing lifecycle steps for this domain.

Resources