domain-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
The tools are mostly distinct: check_domain and check_domains are clearly single vs bulk variants, while domain_info is differentiated by its stated purpose (metadata for known-registered domains). However, check_domain and domain_info perform essentially the same underlying check, which could cause mild misselection; the description mitigates this but the overlap is real.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (check_domain, check_domains, domain_info, list_supported_tlds, clear_domain_cache). Minor deviation: domain_info uses 'info' rather than a clearer verb like 'get_domain_info', breaking the otherwise clean pattern, and clear_domain_cache uses an adjective+noun rather than object-first.
Tool Count4/5
Five tools is within the ideal 3-15 range and appropriate for a domain-checking server. The count feels slightly trimmed—check_domain and domain_info are near-duplicates, suggesting one could be folded into the other—but the overall scope is reasonably well served.
Completeness4/5
The server covers checking, bulk checking, metadata lookup, TLD discovery, and cache management, covering the core domain-lookup workflows well. Minor gaps exist: there is no tool for WHOIS-style detailed records beyond raw payloads, and no capability to register or manage domains (if that were in scope). For pure lookups, the surface is complete.
Average 3.6/5 across 5 of 5 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on July 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. The description states the action (clear cache) but doesn't disclose side effects—does this invalidate domain checks for all domains? Does it require privileges? Is there any persistence impact? With zero annotations, this is under-specified for a mutating tool.
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?
A single clear sentence with no waste. It's appropriately brief for a zero-parameter tool. Could arguably benefit from one additional clause explaining when to invoke, but the current form is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, this is a mutating cache-clearing operation with no annotations and no usage guidance. For a tool with side effects, additional context (side effects, prerequisites, frequency of need) would meaningfully improve agent decision-making. The current description is bare-minimum.
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?
There are 0 parameters, and schema description coverage is 100%. The baseline for 0 params is 4 since there is nothing for the description to compensate for. The description adds nothing beyond what's needed, and none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it clears the in-memory domain check cache, giving a clear verb and resource (clear + cache). However, it doesn't distinguish clearly from siblings—given sibling tools are check_domain, domain_info, etc., the cache-clearing purpose is reasonably distinct, but the description doesn't explain what the cache is used for or why an agent might want to clear it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool. It doesn't explain scenarios (e.g., after updates to domain rules, when stale check results are observed) or when NOT to use it. For a cache-clearing maintenance tool with no schema parameters, usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses some behavior via the Args (use_cache = TTL cache with 5-minute default, include_raw = verbose payload) and Returns (status, registrar, dates, nameservers), which adds context. However, it does not disclose network latency considerations, rate-limit behavior, or what happens with unsupported TLDs, which could matter for a network-dependent checking tool with sibling list_supported_tlds.
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 description is reasonably concise and well-structured with Args/Returns sections. The Args section repeats parameter names that already exist in the schema, but adds meaningful commentary with examples and defaults. Each line earns its place; no filler. Could be slightly tighter but is efficient overall.
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 this is a network-dependent tool with a an output schema, the description is decently complete: it covers inputs, outputs, and cache behavior. However, it lacks guidance on edge cases like invalid domains, unsupported TLDs (despite a sibling list_supported_tlds suggesting TLD awareness matters), and expected behavior when RDAP/WHOIS fails. The absence of annotations increases the burden the description must carry, and this falls slightly short for a tool with real-world network dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameter meaning. It does explain each parameter: domain (with example including internationalized 'bücher.de'), include_raw (verbose), use_cache (in-memory TTL cache, 5 min default). While this adds value beyond the bare schema, the explanation is light — it doesn't detail return value structure for include_raw or how cache invalidation works, though the output schema partially mitigates this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a single domain is available or registered, using a specific verb ('Check') with a resource ('single domain'). It distinguishes itself from the sibling check_domains (batch) by explicitly noting 'a single domain', providing differentiation. The Args section and Returns section add clarity to the purpose.
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 mentions 'single domain' which implicitly differentiates from check_domains (batch), suggesting when to use this vs the batch tool. However, it doesn't explicitly state when NOT to use it or call out alternatives by name like domain_info or list_supported_tlds. Usage guidance is implied through the 'single domain' keyword rather than being explicit about exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that results are returned in input order (a key behavioral trait), that include_raw can produce 'large responses' (size concern), that caching is in-memory and TTL-based (implying cache can go stale), and notes parallel execution with rate-limit friendliness. This is richer behavioral context than typical.
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 compact and front-loaded: the first line states the core purpose and key differentiator (parallel bulk check, rate-limit friendly). The Args section uses clear docstring formatting, and the Returns line is a single efficient sentence. Every sentence earns its place with no fluff.
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?
The tool has an output schema that documents the return structure, so the Returns line adequately summarizes. The three parameters are all documented in the Args section with useful detail. Given the moderate complexity (bulk parallel operation with caching and raw payload options), the description covers the essential behavioral and usage context well, though it could note potential cache-staleness implications of use_cache.
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 0%, so the description must compensate for all three parameters, and it does reasonably well: domains has a max-recommended count, include_raw signals size tradeoff via 'large responses', and use_cache is described as 'in-memory TTL cache'. This adds meaningful semantic context beyond the bare schema titles, though it lacks nuance on what 'raw' actually contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks multiple domains in parallel, distinguishing it as a bulk operation. However, it doesn't explicitly differentiate from the sibling 'check_domain' beyond the plural/bulk implication, nor does it state what 'check' means (availability, DNS, WHOIS, etc.) — the verb 'check' remains ambiguous about the specific domain attribute being verified.
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 notes it's 'rate-limit friendly' and specifies a max recommended 50 domains per call, which gives useful context for when to prefer this bulk tool. However, it doesn't explicitly state when to use check_domains vs the single check_domain sibling, nor when to toggle include_raw or use_cache — the when/when-not guidance for these params is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the check is the same underlying as check_domain and mentions the optional include_raw flag behavior. However, it doesn't describe the output format, error behavior for unregistered domains, rate limits, or what fields populate when include_raw is false. Adequate but sparse for an unannotated tool.
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?
Two compact paragraphs plus a structured Args list. Front-loaded with purpose, then usage guidance, then parameters. Every sentence earns its place with zero filler.
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?
For a 2-parameter tool with an output schema present and decent description coverage, this is reasonably complete. The description explains the tool's purpose, its relationship to check_domain, and parameter intent. Could add error handling or unregistered-domain behavior, but given the tool's simplicity and output schema availability, the coverage is sufficient.
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 coverage is 0%, so neither schema nor description documents parameter semantics beyond names. The description mentions 'domain' and 'include_raw' in the Args section but only restates what the names imply—no format hints, no example values, no types beyond the schema defaults. The description adds minimal meaning beyond the parameter names.
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?
Description clearly states it retrieves registration details (registrar, expiry, nameservers) for a domain. It explicitly differentiates from check_domain by noting they share the same underlying check but this tool is preferred for WHOIS-like metadata on already-registered domains. Verb+resource+scope are all specific.
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?
Explicitly states when to prefer this tool ('prefer this when you need WHOIS-like metadata for a domain you already know is registered') and names the alternative (check_domain). Lacks an explicit 'when not to use' clause, but the positive guidance and sibling differentiation are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the list is not exhaustive (via WHOIS fallback note), which is useful behavioral context about coverage limitations. However, it doesn't describe return format, ordering, or whether this reflects real-time vs cached data.
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?
Two compact sentences with zero waste. Front-loaded with the core purpose, followed by one useful caveat. Every sentence earns its place.
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?
The tool is a simple read-only list with no parameters and an output schema available. The description covers the essential purpose and a critical caveat (WHOIS fallback). An output schema exists, so return values don't need description. Slightly more behavioral context (caching, freshness) could push it higher.
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?
The tool has 0 parameters, so schema coverage is 100% and there are no parameters to document. The description reasonably describes what is being listed without needing to explain parameter syntax, satisfying the baseline 4 for a zero-parameter tool.
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?
Description clearly states 'List TLDs with known RDAP endpoints (IANA bootstrap + overrides)' — a specific verb (list) and specific resource (TLDs with known RDAP endpoints) with scoping detail. The mention of IANA bootstrap + overrides distinguishes scope from a generic TLD listing.
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?
The description explicitly notes that 'TLDs missing from this list may still work via WHOIS fallback', providing important context about when this list is not exhaustive. It doesn't explicitly state when to prefer this over siblings, but the fallback caveat gives useful usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![domain-mcp MCP server](https://glama.ai/mcp/servers/danielgtmn/domain-mcp/badges/card.svg)](https://glama.ai/mcp/servers/danielgtmn/domain-mcp)

Score Badge

Copy to your README.md:

[![domain-mcp MCP server](https://glama.ai/mcp/servers/danielgtmn/domain-mcp/badges/score.svg)](https://glama.ai/mcp/servers/danielgtmn/domain-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/danielgtmn/domain-mcp'

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