Skip to main content
Glama
cfenzo
by cfenzo

suggest_domains

Generate available domain name suggestions based on keywords, checking multiple TLDs and variations to help find suitable web addresses for projects or businesses.

Instructions

Suggest available domain names based on a keyword or phrase. Checks multiple variations and TLDs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keywordYesThe keyword or phrase to base suggestions on
categoryNoCategory of TLDs to check. Default: general
includeVariationsNoInclude variations like adding 'app', 'hq', 'get' prefixes/suffixes. Default: true

Implementation Reference

  • The main handler for the 'suggest_domains' tool. It accepts a keyword parameter, optionally generates variations (e.g., adding 'app', 'hq' prefixes/suffixes), gets TLDs based on category, checks all combinations using checkAlternativeTlds, filters available domains, and returns a sorted summary by confidence and domain length.
    case "suggest_domains": {
      const keyword = args?.keyword as string;
      if (!keyword) {
        throw new Error("Keyword is required");
      }
    
      const category = (args?.category as string) || "general";
      const includeVariations = args?.includeVariations !== false;
    
      const names = includeVariations ? generateVariations(keyword) : [keyword];
      const tlds = getSuggestedTlds(category as "general" | "tech" | "country" | "all");
    
      // Check all combinations
      const allResults: DomainCheckResult[] = [];
      for (const name of names) {
        const results = await checkAlternativeTlds(name, tlds.slice(0, 5), { concurrency: 3 });
        allResults.push(...results.results);
      }
    
      const available = allResults.filter((r) => r.available);
    
      const summary = {
        keyword,
        variationsChecked: names,
        totalChecked: allResults.length,
        availableCount: available.length,
        suggestions: available.sort((a, b) => {
          // Sort by confidence then by domain length
          if (a.confidence !== b.confidence) {
            const order = { high: 0, medium: 1, low: 2 };
            return order[a.confidence] - order[b.confidence];
          }
          return a.domain.length - b.domain.length;
        }),
      };
    
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(summary, null, 2),
          },
        ],
      };
    }
  • src/index.ts:65-89 (registration)
    Tool registration and schema definition for 'suggest_domains'. Defines the tool's name, description, and inputSchema with properties: keyword (required), category (enum: general/tech/country/all), and includeVariations (boolean, default true).
    {
      name: "suggest_domains",
      description:
        "Suggest available domain names based on a keyword or phrase. Checks multiple variations and TLDs.",
      inputSchema: {
        type: "object" as const,
        properties: {
          keyword: {
            type: "string",
            description: "The keyword or phrase to base suggestions on",
          },
          category: {
            type: "string",
            enum: ["general", "tech", "country", "all"],
            description: "Category of TLDs to check. Default: general",
          },
          includeVariations: {
            type: "boolean",
            description:
              "Include variations like adding 'app', 'hq', 'get' prefixes/suffixes. Default: true",
          },
        },
        required: ["keyword"],
      },
    },
  • Helper function generateVariations that creates domain name variations from a keyword. Adds common prefixes (get, try, use, my, the, go) and suffixes (app, hq, io, hub, labs, now) to suggest alternative domain names.
    function generateVariations(keyword: string): string[] {
      const base = keyword.toLowerCase().replace(/[^a-z0-9]/g, "");
      const variations = [base];
    
      // Common prefixes
      const prefixes = ["get", "try", "use", "my", "the", "go"];
      // Common suffixes
      const suffixes = ["app", "hq", "io", "hub", "labs", "now"];
    
      prefixes.forEach((p) => variations.push(`${p}${base}`));
      suffixes.forEach((s) => variations.push(`${base}${s}`));
    
      return [...new Set(variations)];
    }
  • checkAlternativeTlds function that checks domain availability across multiple TLDs. Processes domains in configurable batches to avoid overwhelming servers and returns all check results. Used by suggest_domains to check multiple TLDs for each generated variation.
    export async function checkAlternativeTlds(
      domainName: string,
      tlds: string[] = POPULAR_TLDS,
      options: { concurrency?: number; batchDelay?: number } = {}
    ): Promise<AlternativeTldResult> {
      const { concurrency = DEFAULT_CONCURRENCY, batchDelay = BATCH_DELAY_MS } = options;
      const name = domainName.includes(".") ? parseDomain(domainName).name : domainName;
    
      const results: DomainCheckResult[] = [];
    
      // Process in batches to avoid overwhelming servers
      for (let i = 0; i < tlds.length; i += concurrency) {
        const batch = tlds.slice(i, i + concurrency);
        const batchResults = await Promise.all(
          batch.map((tld) => checkDomain(`${name}.${tld}`))
        );
        results.push(...batchResults);
    
        // Add delay between batches (except after the last batch)
        if (i + concurrency < tlds.length) {
          await sleep(batchDelay);
        }
      }
    
      return {
        originalDomain: name,
        results,
      };
    }
  • getSuggestedTlds function that returns TLD arrays based on category (general, tech, country, or all). Provides the appropriate TLD list for the suggest_domains tool to check against.
    export function getSuggestedTlds(
      purpose: "general" | "tech" | "country" | "all" = "general"
    ): string[] {
      switch (purpose) {
        case "tech":
          return TECH_TLDS;
        case "country":
          return COUNTRY_TLDS;
        case "all":
          return [...new Set([...POPULAR_TLDS, ...TECH_TLDS, ...COUNTRY_TLDS])];
        case "general":
        default:
          return POPULAR_TLDS;
      }
    }
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool 'checks multiple variations and TLDs', which gives some context about its scope, but fails to describe critical behaviors like response format (e.g., list of suggestions with availability status), rate limits, authentication needs, or whether it performs actual availability checks vs. generating names only. This leaves significant gaps for a tool with potential external dependencies.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose ('suggest available domain names') and adds essential context ('based on a keyword or phrase' and 'checks multiple variations and TLDs') without any wasted words. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters with full schema coverage and no output schema, the description is adequate for a read-only suggestion tool but incomplete. It lacks details on behavioral aspects (e.g., response format, rate limits) and doesn't leverage the absence of annotations to compensate, leaving the agent with gaps in understanding how to interpret results or handle errors.

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 schema fully documents all parameters (keyword, category, includeVariations). The description adds no additional parameter semantics beyond what's in the schema, such as examples of variations or TLD categories. Baseline 3 is appropriate as the schema handles the heavy lifting.

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's purpose with a specific verb ('suggest') and resource ('available domain names'), and distinguishes it from siblings by specifying it checks 'multiple variations and TLDs' based on a keyword/phrase, unlike check_domain (likely single domain verification) or list_tlds (listing TLDs only).

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

Usage Guidelines3/5

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

The description implies usage context by mentioning 'based on a keyword or phrase' and 'checks multiple variations and TLDs', suggesting it's for brainstorming domain ideas. However, it lacks explicit guidance on when to use this vs. alternatives like check_alternative_tlds or check_domain, and doesn't mention prerequisites or exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cfenzo/domain-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server