A
license-
qualityF
maintenanceCheck domain name availability via RDAP. Single lookups, bulk checks (up to 50), and smart name suggestions with registration links. No API key needed.
Last updated
MIT
dotsweep
by com.dotsweep
Server Details
Domain availability across 1,200+ TLDs, with renewal price, minimum term and eligibility
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.6/5.0
Tool DescriptionsA
Average 4.6/5 across 3 of 3 tools scored.
Server CoherenceA
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.
Available Tools
3 toolscheck_domainsCheck domain availability and priceARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tlds | No | Extensions 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. | |
| names | Yes | Brand 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. |
Tool Definition Quality
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.
list_tldsList checkable extensions with pricesARead-onlyInspect
Every extension this server can check, with registration and renewal price, minimum registration term, and any eligibility restriction on who may register it. Use before check_domains when the extensions to check are not already decided: the catalogue is wider than the handful most people can name, prices vary by more than an order of magnitude, and min_term_years means the first bill can be a multiple of the price shown. An entry carrying vendor is priced by a registrar other than the one quoted by default, because that one does not sell the extension — the number is still real, it just belongs to the named registrar. An entry with no price at all means no registrar here sells it, which is a fact about this catalogue and not about the extension: several are sold perfectly well by registrars we hold no feed for, so an absent price leaves availability an open question rather than settling it. All prices are USD.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, and the description adds context beyond them: vendor-priced entries are explained, and missing prices are clarified as a catalogue limitation rather than an extension property. This significantly enriches behavioral understanding.
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 somewhat long but every sentence adds meaningful detail. It is front-loaded with the core purpose, then usage guidance, then caveats. Slightly verbose but not wasteful.
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 carries the burden of explaining return values. It thoroughly covers price, minimum term, eligibility restrictions, vendor indicator, and the meaning of absent prices, making it complete for a list tool.
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 tool has no parameters, and the baseline for zero parameters is 4. The description doesn't need to explain parameters; it focuses on output semantics instead, which is appropriate.
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 that the tool lists every extension the server can check, along with registration/renewal prices, minimum term, and eligibility restrictions. It distinguishes itself from siblings (check_domains, whois) by focusing on the catalogue aspect.
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 use before check_domains when extensions are not already decided, and provides concrete reasons (catalogue wider than assumed, price variance, min term affecting first bill). This gives clear when-to-use guidance and implies the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoisLook up a domain's registry recordARead-onlyInspect
Registry record for one domain: registrar, registration and expiry dates, nameservers, status codes, and whether it appears to be for sale. Resolves the correct registry host for the extension itself, and reads RDAP for .dev, .app and other extensions whose operators publish no port-43 whois service. Use when asked who owns a domain, when it expires, or where it is hosted. It forces a registry lookup, so it is also the only call that fills offer — a taken domain that appears to be parked or listed for sale. An offer is an inference from nameservers and a listing page, never a quote: the asking price lives on the listing and not in the registry, so link the listing rather than naming a figure.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | A full domain, e.g. example.com |
Tool Definition Quality
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses internal behavior beyond annotations: resolves the registry host per extension, falls back to RDAP when port-43 is unavailable, forces a live registry lookup, and defines offer as an inference, not a quote. This adds significant context to the readOnlyHint/openWorldHint annotations without contradiction.
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?
Description is somewhat long but front-loaded with a clear first sentence. Subsequent sentences add valuable detail on usage and offer nuance, though there is minor redundancy with the title ('registry record'). Each sentence earns its place.
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 one-parameter tool with no output schema, the description covers return fields, use cases, special RDAP behavior, and the offer caveat. It is self-contained enough for an agent to select and invoke correctly without further context.
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 covers the single parameter at 100% with format example. Description adds minimal semantics about singular domain and registry-host resolution, but does not redefine the parameter; baseline 3 is appropriate.
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?
Description explicitly states 'Registry record for one domain' and enumerates contents (registrar, dates, nameservers, status codes, sale status). It distinctly positions the tool for single-domain lookups and differentiates from siblings by noting it is the only call that fills the offer field.
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?
Provides direct usage cues: 'Use when asked who owns a domain, when it expires, or where it is hosted.' It also notes exclusivity for offer. However, it does not explicitly contrast with sibling tools for multi-domain or TLD-list use cases, so it lacks a full when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Alicense-quality-maintenanceEnables users to check domain name availability across 877 TLDs, generate intelligent suggestions, and retrieve WHOIS registration information. It supports bulk domain checks and cross-TLD searches through natural language interfaces.Last updated0
- AlicenseAqualityCmaintenanceFast domain availability checker that searches across multiple registrars (Porkbun, Namecheap) and protocols (RDAP, WHOIS) to find available domains, compare pricing, get suggestions, and check social media username availability.Last updated792425MIT
- FlicenseAqualityDmaintenanceEnables domain name availability checking through DNS and WHOIS lookups with confidence scoring. It supports searching across alternative TLDs and generating domain name variations for branding purposes.Last updated4