tld.expert

Suggest alternative domains

suggest_tld_alternatives

Read-onlyIdempotent

Use this when the domain the user wants is taken (or they ask for other options for a name). Given a full domain like "acme.com", proposes other endings (acme.io), added words (getacme.com), domain hacks and related words, checks every candidate live, and returns only the ones that are not taken. Slower than a single check (up to ~30 live lookups). Also use it when the user describes what the domain is for ("a fitness app in brazil", "a scratch site for side projects"): pass that as brief, with their name as domain if they have one. It then answers like the tld.expert search box: endings that fit the project (each with why and its source page), the popular endings, and name variants, every one checked live, taken ones counted but not listed. In brief mode, audience (who it is for) and vibe (how the name should feel) rethink the name ideas and lead with endings that suit them, like the questionnaire on the site. A suggestion on a gated ending (.law for licensed lawyers, .nyc for a New York City address) carries registration_rule with the registry source; closed ones are only proposed when the brief says the user qualifies.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "suggest_tld_alternatives"
  }
}

Input Schema

Name	Required	Description
`vibe`	No	Optional, brief mode only: how the name should feel. Reshapes the name ideas and leads with endings that suit it.
`brief`	No	Optional: a few words on what the domain is for, e.g. "fitness app in brazil" or "notes beside the main road". Switches to brief mode.
`domain`	No	The full domain the user wanted, e.g. "acme.com" or "stripe.io". With brief, a bare name like "acme" also works. Required unless brief is given.
`audience`	No	Optional, brief mode only: who it is for. Reshapes the name ideas and leads with endings that suit them.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 1, 2026

addedInput schema / properties / audience

Added value: +{
+  "description": "Optional, brief mode only: who it is for. Reshapes the name ideas and leads with endings that suit them.",
+  "enum": [
+    "everyone",
+    "business",
+    "developers",
+    "kids",
+    "local",
+    "fans"
+  ],
+  "type": "string"
+}

addedInput schema / properties / vibe

Added value: +{
+  "description": "Optional, brief mode only: how the name should feel. Reshapes the name ideas and leads with endings that suit it.",
+  "enum": [
+    "classic",
+    "playful",
+    "premium",
+    "techy",
+    "bold"
+  ],
+  "type": "string"
+}

Changed4 schema fields changedNov 1, 2026

addedInput schema / properties / brief

Added value: +{
+  "description": "Optional: a few words on what the domain is for, e.g. \"fitness app in brazil\" or \"notes beside the main road\". Switches to brief mode.",
+  "maxLength": 200,
+  "minLength": 2,
+  "type": "string"
+}

changedInput schema / properties / domain / description

Previous value: -"The full domain the user wanted, e.g. \"acme.com\" or \"stripe.io\""New value: +"The full domain the user wanted, e.g. \"acme.com\" or \"stripe.io\". With brief, a bare name like \"acme\" also works. Required unless brief is given."

changedInput schema / properties / domain / minLength
```
Previous value: -3New value: +1
```
removedInput schema / required
```
Removed value: -[
-  "domain"
-]
```

First observedOct 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations cover the read-only/idempotent/non-destructive and open-world profile, and the description adds substantial behavior beyond them: every candidate is checked live, only available names are returned, taken ones are counted but omitted, gated endings carry registration_rule plus the registry source, and closed endings are only proposed when the brief says the user qualifies.

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?

The trigger is front-loaded well, but everything sits in one long paragraph where the brief-mode, audience/vibe, and gated-ending rules blur together. Several clauses ('answers like the tld.expert search box', 'like the questionnaire on the site') carry marketing flavor rather than actionable specification, and some content duplicates the schema.

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?

There is no output schema, and the description compensates fully: it states what is returned (only available candidates, plus registration_rule with registry source and why/source per ending) and what is omitted (taken names are only counted). For a no-required-parameter, live-network tool this is complete enough to call correctly.

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 the baseline is 3, but the description still adds cross-parameter meaning: brief switches the whole tool into brief mode, domain may be a bare name when brief is supplied, and audience/vibe reshape the name ideas and lead with fitting endings. It loses a point because the brief/audience/vibe wording largely restates the schema descriptions.

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 first sentence names a concrete verb+resource (propose other domain endings from a given domain) and the description enumerates exactly what gets generated: other endings, added words, domain hacks, related words. It also distinguishes itself from the single-check sibling with the line 'Slower than a single check (up to ~30 live lookups).'

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?

Explicit triggers are given: when the desired domain is taken, when the user asks for other options, and when the user describes a project purpose rather than a name. The relative cost ('slower than a single check, up to ~30 live lookups') tells the agent when not to reach for it, even though the sibling check_domain_availability is not named.

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

All tld.expert tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?