Skip to main content
Glama

Check domain availability

check_domain_availability
Read-onlyIdempotent

Use this when the user wants to know if a domain name is available or taken, or asks "can I get ". Accepts a full domain ("acme.io") for one verdict, or a bare name ("acme") to check it across popular TLDs (com, io, ai, co, app, dev, net, org, xyz) or a custom TLD list. Checks live DNS, registry RDAP/WHOIS and a registrar; never claims "available" without registrar confirmation. Returns a verdict per domain, buy links for names that may be free, and a tld.expert URL to cite. For one full domain that is taken, the result also carries registration: who it is registered with, when it expires, whether it is in redemption or pending delete, and whether it is listed for sale on a marketplace, from the registry's own RDAP/WHOIS. Use it for "who owns this domain", "when does it expire" and "is it for sale".

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": "check_domain_availability"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoAlias for query.
tldsNoOnly used for a bare name: TLDs to check instead of the popular set, e.g. ["com", "ai", "so"]. Max 20.
queryNoA full domain like "acme.io" or a bare name like "acme". Examples: "acme.io", "notion", "getacme.com". Required (or pass it as domain).
domainNoAlias for query, as in /api/check?domain= and suggest_tld_alternatives.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / domain
      Added value: +{
      +  "description": "Alias for query, as in /api/check?domain= and suggest_tld_alternatives.",
      +  "maxLength": 253,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / name
      Added value: +{
      +  "description": "Alias for query.",
      +  "maxLength": 253,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • changedInput schema / properties / query / description
      Previous value: -"A full domain like \"acme.io\" or a bare name like \"acme\". Examples: \"acme.io\", \"notion\", \"getacme.com\""New value: +"A full domain like \"acme.io\" or a bare name like \"acme\". Examples: \"acme.io\", \"notion\", \"getacme.com\". Required (or pass it as domain)."
    • removedInput schema / required
      Removed value: -[
      -  "query"
      -]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, and the description adds substantial context beyond them: it checks live DNS, registry RDAP/WHOIS and a registrar, and never reports 'available' without registrar confirmation. It also discloses what the response carries (verdicts, buy links, citation URL, and registration/expiry/redemption/marketplace data for taken domains).

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?

Front-loaded with the trigger and input modes, then the verification behavior, then the return payload. Dense and mostly waste-free, though the trailing 'Use it for who owns this domain...' sentence partially repeats the registration detail already stated just before it.

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 return-value burden and does so thoroughly: per-domain verdicts, buy links, a citable URL, and the full registration record for a taken domain. An agent has enough to call it and to explain results without further documentation.

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 adds meaning the schema does not: it enumerates the default popular TLD set (com, io, ai, co, app, dev, net, org, xyz) and clarifies that tlds only applies to a bare name. The alias relationships (name/domain/query) are left to 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?

States a specific verb and resource ('check domain availability') and immediately scopes the two input modes: a full domain for one verdict vs a bare name across TLDs. This is clearly distinguishable from siblings like check_brand_name and suggest_tld_alternatives, which do different jobs.

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?

Gives explicit trigger conditions, including the user phrasing 'can I get <name>', and extends usage to 'who owns this domain', 'when does it expire' and 'is it for sale'. It does not name sibling tools or state when to prefer them, so routing between check_domain_availability and suggest_tld_alternatives is left to inference.

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.

Resources