mcp-server-domain-checker
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_domain_availabilityB | Performs authoritative registry socket query to verify whether a domain name is available for registration. |
| resolve_dns_recordsB | Resolves live DNS records (A, NS, MX, TXT) for any domain using Node.js native DNS resolver. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools target entirely different concerns: registration availability via registry socket query versus live DNS record resolution. There is no plausible scenario where an agent would confuse the two.
Both tools follow a clean verb_noun snake_case pattern (check_domain_availability, resolve_dns_records). Consistent and predictable.
Two tools is on the thin side for a domain-checker server; a single focused capability pair is defensible but leaves little room for adjacent operations. Not a mismatch, but borderline sparse.
Availability and DNS cover the core lookup needs, but there is no WHOIS/registrar data, expiry, or bulk/batch checking. Agents needing registration metadata would hit a dead end.