tldx: Bulk Domain Availability Checks Over RDAP, DNS and WHOIS

The gap tldx fills between a name idea and a registrar search box

Checking one domain is a browser tab. Checking four hundred is a script. The awkward middle is where most naming work actually happens: you have a stem like openai, a handful of prefixes you like, a handful of suffixes, and three or four TLDs you would accept, and you want to see which of the resulting combinations are free. Doing that by hand means dozens of searches, and doing it with a shell loop means writing the loop, handling the TLD list, and parsing whatever each registry returns.

tldx takes the stem and the affixes as flags and does the expansion and the checking in one process. The README's opening example is exactly this shape: tldx openai -p get,use -s ly,hub -t com,io,ai --only-available, which prints lines such as getopenaily.com is available. The audience is developers, indie hackers and naming consultants who are comfortable in a terminal and who would rather type a flag than click through a registrar. The --regex mode pushes it further: tldx '[a-z]{3}' --regex --tlds com --only-available walks every three-letter .com combination, which is a search space no human would attempt manually.

One design decision worth noting early: the tool does not try to be a registrar interface. It answers availability. Registration, pricing and transfer are out of scope, and the README does not pretend otherwise.

RDAP first, DNS and WHOIS behind it, and what that ordering costs

The description names three lookup mechanisms: RDAP, DNS and WHOIS. The feature list says availability checks run concurrently over RDAP, and the tool streams results as they are found rather than buffering the whole run. That combination explains the output style in the README examples, where result lines appear in an order that does not match the order of the keywords on the command line. The three keywords google youtube reddit come back as reddit, google, youtube. If you are piping output into another tool and you care about ordering, that is a property you have to handle yourself.

RDAP is the primary path because it returns structured data, which is what makes the json, json-stream, json-array, csv, grouped and grouped-tld formats practical. DNS and WHOIS sit behind it as fallbacks for registries that do not answer RDAP cleanly. The README does not document the exact fallback order, the timeout per lookup, or the retry behaviour, so treat those as unknowns. The practical consequence is that a run is only as reliable as the weakest registry in your TLD list. A TLD whose RDAP endpoint is missing or slow will drag the whole batch toward the WHOIS path, and WHOIS responses vary enough between registries that the README's silence on parsing rules is a real gap rather than a documentation nit.

The --for-sale flag adds a second kind of query. It checks taken domains for an RFC 10023 _for-sale TXT record, which is how a registrant can advertise that a registered name is on the market. --only-for-sale implies --for-sale. This is a useful signal but a narrow one: it only finds domains whose owners opted into that convention, so a taken domain with no TXT record tells you nothing about whether the owner would sell.

Regex expansion, the 500,000 combination cap, and dry runs

The --regex flag changes the meaning of the keyword argument. Instead of a literal stem, each keyword becomes a pattern, and tldx checks every combination the pattern expands to. The README shows three uses: all three-letter .com domains with '[a-z]{3}', all two-letter domains on .io and .ai with '[a-z]{2}', and patterns combined with prefixes so that '[a-z]{2}' --prefixes my,get --tlds app produces candidates like myaa.app and getab.app.

There is a guard rail here, and it is the most important operational fact in the README: patterns that expand to more than 500,000 combinations are skipped. That cap is what stands between a typo and a very long afternoon. A pattern like '[a-z]{5}' on a single TLD is 11.8 million combinations before prefixes or suffixes multiply it further, so it will be skipped rather than attempted. If you are planning a wide sweep, count your combinations before you run it, because the failure mode is silent skipping rather than an error you can catch in a script.

The --dry-run flag is the intended way to do that counting. It prints the domains that would be checked without making network calls. Given that a real run against a broad TLD preset can issue thousands of lookups, --dry-run is not a convenience flag, it is the sanity check you run first. --max-domain-length defaults to 64 and bounds the generated names, so long prefix and suffix chains get filtered before they reach the network.

Getting it running: flags, presets and the config file

The binary is invoked as tldx [keywords] [flags], with subcommands for completion, config, help, mcp and preset. The flags that matter for a first run are -p for prefixes, -s for suffixes, -t for TLDs, -a for showing only available domains, -l to stop after finding a set number of available domains, and -f to choose the output format. The README's usage block lists text, json, json-stream, json-array, csv, grouped and grouped-tld as the format values, with text as the default.

TLD presets save typing. tldx preset list shows the built-ins, which include all, cheap, popular and tech, and marks custom presets with an asterisk. The popular preset is ai me app com dev net org; tech is a longer list covering io, ai, gg, app, dev, tech and others. You can create your own with tldx preset add myteam com io ai, and comma-separated input works too. tldx preset default nordic sets a preset that applies to every run, and tldx preset default with no argument shows the current default. Custom presets live in ~/.config/tldx/config.toml, which the preset commands write to and which also holds your usual TLDs and flags.

Keywords can come from a file or from stdin with -i, and - is the stdin sentinel. That matters for scripted use: you can generate a candidate list elsewhere, pipe it in, and get csv or json-stream out. Exit code 2 is returned when --only-available is set but nothing is found, which gives you a clean branch in a shell script without parsing stdout. --show-stats prints statistics at the end of a run, and --no-color disables colored output for logs.

The MCP server and what an agent can actually do with it

tldx mcp starts a Model Context Protocol server over stdio. The README lists it as a feature and as a subcommand, and the repository carries an MCP toplist badge, but the supplied material does not document the tool names, schemas or prompts the server exposes. That is a genuine limitation for anyone evaluating it as an agent component: you can see that the integration exists, and you cannot see from this README what an agent would call or what it would receive back.

The design implication is still legible. Because the CLI already speaks json-stream and json-array, wrapping it in an MCP server is a thin layer rather than a second implementation, and an agent that needs to check a naming idea mid-conversation gets the same lookup path a human would use from the shell. The risk is the same as the shell path: a broad regex or a wide preset can turn a single tool call into thousands of network requests, and the 500,000 combination cap is the only documented brake. If you wire tldx into an agent, constrain the TLD list and the pattern width on the agent side rather than trusting the model to pick sensible flags.

Where tldx is the wrong tool

Availability is not the same as registrability. A domain can come back available from RDAP and still be blocked by a registry's reserved-name policy, a trademark claim, or a premium pricing tier that the lookup does not surface. tldx answers whether a name appears unregistered at the moment of the query. It does not tell you what it costs, whether you are allowed to have it, or whether someone else is about to take it.

The concurrency model has a second consequence. Because results stream as they are found, a run that you interrupt halfway has produced partial output with no marker saying so, and the README does not describe a resume mechanism. For a long sweep across a large preset, that means the useful artifact is the output file, not the terminal scrollback, and you should be writing to one of the machine-readable formats if you intend to process the result.

Finally, the tool is a point-in-time check with no persistence layer. There is no database, no history, no diff between runs. If your actual problem is watching a shortlist of names over weeks, tldx is the wrong shape entirely, and you would be better served by a scheduled job that runs tldx and stores the output yourself.

How tldx differs from a WHOIS wrapper or a registrar API

The obvious alternative is a plain WHOIS client wrapped in a shell loop, and the difference is not cosmetic. WHOIS output is free-form text that differs between registries, so a wrapper has to parse per-registry patterns and breaks when a registry changes its formatting. tldx puts RDAP first specifically because RDAP returns structured JSON, which is what makes its own json and csv output modes trustworthy. A WHOIS loop also has no notion of permutations, no TLD presets, no combination cap, and no streaming. You would be rebuilding the flag surface before you got to the first lookup.

The other alternative is a registrar's own bulk search API. Those tend to return pricing and purchase links alongside availability, which tldx does not. The trade is that registrar APIs are tied to one registrar, usually rate-limited per account, and awkward to call from an agent or a CI job without credentials. tldx has no account model, no API key, and no rate-limit documentation in the README, which cuts both ways: nothing to configure, and nothing telling you how hard you can push a given registry before it starts refusing you.

Licence, maintenance and what to verify before adopting

tldx is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes. Apache-2.0 also includes an explicit patent grant, which is the practical difference from MIT if you plan to embed this in a product. This is a description of the licence text, not legal advice; if you are redistributing a modified tldx, have your own counsel read the NOTICE requirements.

The release cadence visible in the material is three releases between May and August 2026, with v1.6.0 the most recent, and the repository was pushed in September 2026. That is a project under active development, which means flag behaviour and output formats can shift between minor versions. If you script against the json or csv output, pin a version and read the release notes before upgrading, because the README does not promise output stability.

The first thing to verify on your own machine is combination count. Run your real keyword set with --dry-run and your intended prefixes, suffixes and TLDs, and confirm the number of generated domains is what you expect and under the 500,000 cap. The second is RDAP coverage for your target TLDs, since a TLD without a working RDAP endpoint pushes your run onto the WHOIS path whose parsing rules are not documented here. The third is whether you need the --for-sale signal at all, because it adds a second query per taken domain and only finds owners who published an RFC 10023 TXT record.

Editorial conclusion

Adopt tldx if you generate name candidates programmatically and want the availability verdict to come back in the same shell pipeline, particularly if you already script the rest of your provisioning. Do not adopt it if you need registrar-grade certainty, trademark screening, or a record of what a domain looked like last week, because tldx answers a single question at a single moment and writes nothing down. Before you rely on it, run tldx with --dry-run on your real keyword set to see how many combinations your flags actually produce, and check whether your target registries publish RDAP endpoints, since the fallback path decides how much of your run depends on WHOIS.

Official sources

1. brandonyoungdev/tldx on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases