ドメイン番人
Server Details
ドメインの設定を調べる MCP サーバー。SPF / DKIM / DMARC・DNS・SSL 証明書・セキュリティヘッダ・サブドメイン・類似ドメインを、公開情報だけで確認します。登録不要・無料。
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-03-26
- URL
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of tool misselection or overlapping purpose. An agent has exactly one action to invoke and its description clearly states what it does.
The single name domain_diagnose is readable snake_case and clearly domain-scoped, so there is no inconsistency to penalize. The only minor deviation is the noun_verb ordering rather than the more conventional verb_noun, but with one tool this is trivial.
A single catch-all diagnostic tool is defensible for a one-shot health report, but it is on the thin side: every category (DNS, email auth, web security, RDAP, brand) is bundled behind one invocation with no granular entry points. Callers wanting just an SPF check or just an RDAP expiry check must run the whole scan.
The tool's stated coverage is broad and cohesive for the domain: email auth, DNS infrastructure, web security, registration, and brand protection, plus a cross-cutting critical_issues summary. Minor gaps exist around per-category invocation, batch/multi-domain checks, and any comparison or history of prior reports.
Available Tools
1 tooldomain_diagnoseDomain Health DiagnoseAInspect
Runs a comprehensive health check on a public domain: SPF / DKIM / DMARC for the headline score, plus optional details on email-auth adjacent records (MX, BIMI, MTA-STS, TLS-RPT, DKIM key length), DNS infrastructure (NS, DNSSEC, CAA, AAAA, SOA, TXT), web security (HTTPS, certificate, HSTS, HTTP/2-3, CT log), domain registration (RDAP expiry, registrar lock, DS chain), and brand protection (typosquatting, TLD parity). Returns a structured report with per-category scores, individual diagnostic items, and a critical_issues cross-cut summary. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to diagnose, e.g. `example.co.jp`. A URL, an email address, a trailing dot, a port, or an internationalised name are all accepted and resolved to the registrable host — `https://日本語.jp/path`, `info@example.co.jp` and `xn--wgv71a119e.jp` reach the same diagnosis. Names with no public suffix (`localhost`, an IP literal) are rejected. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states that no authentication is required and that the tool 'returns a structured report' with a well-defined shape. It does not explicitly say the operation has no side effects, but the health-check framing and the non-mutating language make that clear enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, with the primary purpose front-loaded and category details packed into a single structured sentence. The final sentence about the report shape and authentication earns its place. It could be slightly more scannable, but every clause adds useful scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description supplies all essential context: input normalization, domain scope, categories checked, report structure, and authentication requirements. An agent has enough information to select the tool and interpret the expected result without additional lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, and the description dramatically enriches the 'domain' parameter: it explains that URLs, email addresses, trailing dots, ports, and internationalized names are all normalized to the registrable host, and it names rejected inputs. This is far beyond the schema's basic type string description and removes real invocation ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Runs a comprehensive health check on a public domain.' It then enumerates the exact categories covered (SPF/DKIM/DMARC, DNS infrastructure, web security, registration, brand protection), which tells an agent precisely what the tool does and distinguishes it from narrower diagnostic tools even without siblings listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is explicit that this is for comprehensive domain health diagnosis and limits applicability to 'public domain' inputs; the schema further clarifies that localhost and IP literals are rejected. There are no sibling tools or alternative paths to contrast, so the lack of explicit 'when not to use' guidance is understandable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
domain_diagnose
Related MCP Connectors
Remote MCP server: 19 domain-hygiene and email-auth tools (DNS, SPF, DMARC, DKIM, TLS).
Domain checks: SPF, DKIM, DMARC, BIMI, MTA-STS, SSL/TLS and HTTP security headers.
SPF, DKIM, DMARC, MTA-STS and domain-expiry checks for any domain, with SPF lookup counts.
SEO MCP server — backlinks, domain authority, tech stack, and 18+ tools via Common Crawl.
Related MCP Servers
- AlicenseAqualityAmaintenanceMCP server for IntoDNS.ai providing 36 free tools for DNS, DMARC, SPF, DKIM, BIMI, DNSSEC, MTA-STS, FCrDNS, blacklist and email security checks. Citation-grade report snapshots with content hashes. No API key required.45723 npm2MIT
- AlicenseAqualityBmaintenanceAn MCP server that checks SPF, DKIM, DMARC, and MX records for a domain, returning a health verdict and specific DNS fixes to improve email deliverability.1MIT
- FlicenseNot gradedqualityBmaintenanceMCP server for inspecting email domains and addresses, providing objective domain-level email infrastructure answers such as MX, SPF, DMARC, MTA-STS, and disposable-domain evidence.-
- AlicenseNot gradedqualityAmaintenanceMCP server for Technical SEO DNS record auditing, SOA expiry health checks, SSL/TLS inspection, and HTTP security header analysis. Enables comprehensive security audits and scoring via 10 tools.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.