Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Check Domains

checkDomains
Read-only

Checks a name or domain across popular extensions and reports availability plus Cloady registration costs, with an exact mode for verifying only the queried name.

Instructions

Checks a name across popular extensions, with what registering each costs on Cloady. q is a name (acme) or a domain (acme.dev): the name searched for comes first, with .com when no extension was typed, then the same name under other extensions, then free variants of it. Availability comes from each registry's RDAP server, or from DNS where an extension has none, so registerDomain's dry run has the final word, on premium names too. With exact, only the name searched for is checked. Public: no token needed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "q": "<q>"
    },
    "name": "checkDomains"
  }
}

Input Schema

NameRequiredDescriptionDefault
qYesA name like `acme`, or a domain like `acme.dev`
exactNoCheck only the name searched for

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish read-only, open-world, non-destructive behavior, and the description still adds real value: the availability source per extension (RDAP server, DNS fallback), the caveat that results may be superseded by registerDomain's dry run on premium names, and the fact that no token is required. It stops short of describing result volume or rate limits on many registry lookups.

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 purpose is front-loaded and every sentence carries information about inputs, sourcing, or caveats. The sentence about RDAP/DNS and registerDomain's dry run is dense and slightly run-on, but it is not padding.

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

Completeness4/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 must convey what comes back, and it does describe the ordering of results (searched name first, .com when no extension is given, then other extensions, then free variants) plus the pricing dimension. It leaves the exact response shape and per-extension formatting unstated, a minor gap for a two-parameter read 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?

Schema coverage is 100%, so both parameters are already documented, yet the description adds genuine semantics: `q` accepts either a bare name or a full domain, a missing extension defaults to .com, and `exact` restricts output to only the searched name rather than the surrounding variant set. That is meaning beyond the schema's one-line field 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 description names a specific verb and resource — checking a name across popular extensions and reporting Cloady registration costs — and scopes it further (RDAP/DNS sourcing, .com default, variant expansion). It also distinguishes itself from registerDomain by noting that a dry run there is authoritative, so an agent can separate this checker from the actual registration siblings.

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?

It clearly establishes the input contract (name or domain via `q`) and the narrowing behavior of `exact`, and it hints at the relationship to registerDomain for final confirmation. What it lacks is an explicit statement of when to prefer this over getWhois or checkMailDomains, or a warning about when not to rely on its results for purchasing decisions.

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

Deploy Server

Other Tools