The shohei server provides AI-accessible infrastructure diagnostics tools for DNS, TLS, email security, and network analysis:
check_dns: Query DNS records (A, AAAA, MX, TXT, CNAME, NS, etc.) for a domain.
check_tls_chain: Inspect TLS certificate chains, including full chain validation, expiry warnings, issuer verification, and optional DANE/TLSA record checking (configurable port, default 443).
check_email_security: Validate a domain's email security posture by checking MX records, SPF, DKIM, and DMARC configurations with a 0–100 compliance score.
check_propagation_global: Verify DNS consistency for a domain across 6 global resolvers (Google, Cloudflare, Quad9, OpenDNS, 1.1.1.1, 8.8.8.8).
benchmark_latency: Measure and compare DNS query latency across multiple transport protocols (System, DoH, DoT, DoQ) for a given domain.
Enables DNS queries via Cloudflare's 1.1.1.1 resolver, supporting DNS-over-HTTPS, DNS-over-TLS, and DNS-over-QUIC.
Provides DNS diagnostics, DNSSEC chain validation, and DANE/TLSA checks using Cloudflare's DNS infrastructure.
Enables DNS queries via Google Public DNS (8.8.8.8), supporting DNS-over-HTTPS and DNS-over-QUIC.
SHOHEI — Security Host Observation & Healthy Evaluation Instrument
shohei v2.5.1 — Rust infrastructure diagnostics library with 168 MCP tools across 62 modules. Comprehensive security, OSINT, threat intelligence, and governance coverage. DNSSEC chain validation, DANE/TLSA, modern protocols, IPv6 dual-stack, security headers, technology fingerprinting, CVE lookup, typosquatting detection, and redirect analysis built in. 0 API keys required — all free/open APIs. Use in Rust projects or hand to Claude for autonomous diagnosis.
MCP server for Claude — 168 diagnostic tools; ask "Check example.com's TLS certificate, DNSBL status, IPv6 support, technology stack, CVE vulnerabilities, typosquatting variants, and redirect chain" for autonomous analysis
TLS certificate inspection — DANE/TLSA validation (RFC 6698), chain analysis, OCSP responder detection, IPv6 support, OCSP stapling detection, TLS version probing (1.0–1.3), cipher suite enumeration
Email security scoring — MX records, SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT validation with 0–100 compliance score + issue linting
IP reputation — DNSBL checks against Spamhaus, Barracuda, SORBS; reverse DNS (PTR) + forward-confirmed reverse DNS (FCrDNS)
CDN/WAF detection — Identify Cloudflare, AWS CloudFront, Fastly, Akamai, Vercel, Netlify, Imperva via HTTP headers
DNS delegation audit — SOA serial consistency check, lame delegation detection across authoritative NS
Domain health report — Composite scoring across MX, SPF, DMARC, TLS, DNSSEC
Security headers audit — CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy with risk scoring
DNS propagation checker — Verify domain consistency across 6 global resolvers (Google, Cloudflare, Quad9, OpenDNS, 1.1.1.1, 8.8.8.8)
DNSSEC chain tree — see every DS, DNSKEY, and trust step from . to your domain; per-zone validation runs in parallel; add -v for key tags and algorithm names
Iterative resolution trace — watch queries travel from root servers to TLD to authoritative NS
Latency benchmarking — Multi-transport timing: System, DoH, DoT, DoQ across multiple rounds
Reverse DNS — PTR lookups for IPv4/IPv6 with FCrDNS validation
Subdomain enumeration — Check common subdomains (www, mail, api, staging, dev, etc.) with DNS resolution + HTTP status + TLS validity
Port reachability — TCP connectivity test for 15 common ports (SSH/22, HTTP/80, HTTPS/443, SMTP/25, MySQL/3306, etc.) with banner grab
IPv6 dual-stack checker — Verify AAAA records, IPv6 TCP/TLS/HTTP reachability, dual-stack completeness
DNS amplification potential — Measure UDP query/response size ratio, DDoS attack risk assessment
Wildcard DNS detection — Probe random subdomains to detect misconfigured *.domain records
Traceroute / hop analysis — Multi-platform hop-by-hop latency measurement (Linux/macOS/Windows)
DoH, DoT, and DoQ — DNS-over-HTTPS, DNS-over-TLS, and DNS-over-QUIC built in
Zone transfer (AXFR) — dump an entire zone from an authoritative server; detect critical misconfiguration
N-way server comparison — diff any number of resolvers simultaneously with --compare
Multiple record types — --type a --type aaaa --type mx queries all types concurrently in a single invocation
Stdin and file batch mode — pipe a list of domains or use -f domains.txt
JSON output — pipe-friendly for scripting and automation
Watch mode — auto-refresh at a set interval with --watch
Interactive TUI — browse records, DNSSEC chain, and trace in a single terminal window (--features tui)
HTTP protocol detection — Automatically detect HTTP/1.1, HTTP/2, HTTP/3 version in responses
RPKI/ROA validation — BGP origin authorization checks via Cloudflare API
ARC authentication — Email chain authentication record validation (DNS-level)
TLS-RPT checking — SMTP TLS Reporting Policy record discovery and parsing
Technology stack fingerprinting — Identify web server, language runtime, CMS (WordPress/Drupal), frameworks from HTTP headers
CVE lookup via NVD API — Search for known vulnerabilities (no API key required); integrates with tech fingerprinting
Typosquatting detection — Generate 200+ domain variants (TLD swap, missing char, transposition, homoglyph, etc.); parallel DNS resolution to find live squats
URL redirect chain tracing — Follow HTTP redirects hop-by-hop; detect HTTPS→HTTP downgrades and redirect loops
Parked domain detection — Identify domains parked for sale via header signatures (Sedo, GoDaddy, Bodis, etc.)
Most infrastructure tools are CLI-only. shohei is built for AI agents:
MCP Server Ready: Expose all diagnostics to Claude, ChatGPT, and custom AI agents without writing integration code
Claude Desktop Integration: Ask Claude "Check example.com's TLS certificate" → get automated diagnosis with full chain analysis
Structured Async APIs: Every function returns serializable types (DnsCheckResult, TlsCheckResult, EmailSecurityResult) — perfect for agents
No CLI, No Python: Pure Rust library + MCP server; scales from single checks to automated monitoring
Library-first design: Import into Rust projects, CI/CD pipelines, or automation frameworks
Trust chain validation: The only open-source library that validates DNS → DNSSEC → TLS → DANE/TLSA in one call
Modern protocols: DoH, DoT, DoQ, DNSSEC, DANE/TLSA all built in
Automation-friendly: Concurrent queries, batching, multi-resolver checks, and programmatic APIs
Compared to alternatives (dig, dog, drill): shohei is composable—use it in tests, monitoring, CI/CD, or hand it to Claude for autonomous diagnosis.
Feature | shohei | dig | dog | doggo | q | delv | drill |
Colored output | ✓ | ✓ | ✓ | ✓ | |||
DNSSEC chain-of-trust tree | ✓ | ||||||
DNSSEC validation | ✓ | ✓ | ✓ | ✓ | |||
Iterative resolution trace (visual) | ✓ | ||||||
Authority + Additional sections | ✓ | ✓ | ✓ | ✓ | |||
N-way server comparison ( | ✓ | ||||||
Zone transfer (AXFR) | ✓ | ✓ | ✓ | ||||
Watch / auto-refresh ( | ✓ | ||||||
Script-friendly output ( | ✓ | ||||||
Multiple record types ( | ✓ | ✓ | |||||
Reverse DNS shorthand ( | ✓ | ✓ | ✓ | ||||
Force TCP ( | ✓ | ✓ | ✓ | ||||
Disable recursion ( | ✓ | ✓ | ✓ | ✓ | |||
Query latency display | ✓ | ✓ | ✓ | ✓ | |||
DNS-over-HTTPS (DoH) | ✓ | ✓ | ✓ | ✓ | ✓ | ||
DNS-over-TLS (DoT) | ✓ | ✓ | ✓ | ✓ | ✓ | ||
DNS-over-QUIC (DoQ) | ✓ | ✓ | |||||
JSON output | ✓ | ✓ | ✓ | ✓ | ✓ | ||
Interactive TUI | ✓ | ||||||
Technology stack fingerprinting | ✓ | ||||||
CVE lookup (no API key) | ✓ | ||||||
Typosquatting detection | ✓ | ||||||
URL redirect chain tracing | ✓ | ||||||
Parked domain detection | ✓ |
dig = BIND utils 9.16+; q = natesales/q; delv = BIND DNSSEC-validating resolver; drill = ldns-based
v2.4.0 additions: 168 MCP tools across 62 modules, robots.txt/OAuth/OIDC/API exposure, unauthenticated DB/container detection, subdomain takeover (30+ services), DGA risk scoring, DKIM key strength, attack surface composite score, RIPE Stat passive DNS, Azure AD exposure.
v2.5.1 security patch: 9 CRITICAL/HIGH SSRF fixes (VMC fetch, TCP port scan, MX connect, redirect-follow without per-hop validation across 8 modules), 15+ bug fixes (IPv6 DNSBL trailing-dot, Levenshtein panic on IDN, crypto stubs returning
valid=true, hardcoded year comparisons, SPFallqualifier never populated, sequential awaits parallelised), 4× performance improvement on trust/threat scoring viatokio::join!.
Related MCP server: intodns-mcp
shohei v2.5.1 stands out as the most comprehensive free, API-key-free MCP security server:
Feature | shohei | honeylabs | kastell | unphurl | cloud-audit | maigret |
MCP Tools | 168 | ~25 | ~30 | ~15 | ~20 | ~35 |
Modules | 62 | ~8 | ~10 | ~5 | ~7 | ~12 |
DNS/DNSSEC | ✓ | ✓ | ✓ | |||
TLS/Certificate | ✓ | ✓ | ✓ | |||
Email Security | ✓ | |||||
OSINT/Recon | ✓ | ✓ | ✓ | ✓ | ||
Threat Intel | ✓ | |||||
WHOIS/Domain | ✓ | ✓ | ||||
Port/Service | ✓ | |||||
IP Reputation | ✓ | ✓ | ||||
Compliance/Governance | ✓ | ✓ | ||||
Crypto/Blockchain | ✓ | |||||
Web Headers | ✓ | ✓ | ✓ | |||
API Keys Required | 0 | Multiple | Multiple | Some | Multiple | Multiple |
Free/Open APIs Only | ✓ | Partial | Partial | Partial | Partial | Partial |
Active Maintenance | ✓ | ✓ | ||||
Open Source | ✓ (MIT) | ✓ |
Key Advantages:
168 MCP tools — largest comprehensive security toolkit (v2.5.1)
0 API keys — all tools use free/open public APIs
62 modules — DNS, TLS, email, OSINT, threat intel, governance, crypto, web security, supply chain, compliance
Zero setup cost — no vendor API accounts or authentication required
Pure library + MCP — Rust library for CI/CD + MCP server for Claude Desktop/agents
Add to your Cargo.toml:
[dependencies]
shohei = "2.4"Then import and use:
use shohei::resolver::standard::query;
#[tokio::main]
async fn main() {
let result = query("example.com", "A").await;
println!("{:?}", result);
}For full API documentation: cargo doc --open or docs.rs/shohei.
cargo install shoheiOr download a pre-built binary from the releases page.
For the interactive TUI mode:
cargo install shohei --features tuishohei is designed to be imported and composed in Rust projects. See the examples/ directory:
propagation_check.rs — Check if a domain is propagated globally
tls_chain_verify.rs — Validate TLS certificate chains (Phase 2)
email_security.rs — Check email security records (Phase 1)
Run examples:
cargo run --example propagation_check -- example.com
cargo run --example tls_chain_verify -- example.com
cargo run --example email_security -- example.comThe CLI is a convenient wrapper around the library for manual inspection and testing.
shohei google.com # A records (default)
shohei google.com --type AAAA # AAAA records
shohei google.com --type NS # Nameservers
shohei gmail.com --type MX # Mail exchangers
# Multiple record types in one command
shohei google.com --type a --type aaaa --type mx# Security / DNSSEC-related record types
shohei google.com --type caa # Certificate Authority Authorization
shohei github.com --type sshfp # SSH fingerprints
shohei _443._tcp.example.com --type tlsa # DANE TLSAResolve the PTR record for an IP address. IPv4 and IPv6 are both supported.
shohei -x 1.1.1.1 # → one.one.one.one
shohei -x 2606:4700:4700::1111 # IPv6 reverse lookupValidate the full DNSSEC chain from the root trust anchor down to the target domain. Each zone's DS and DNSKEY records are checked individually.
shohei cloudflare.com --dnssec
# Verbose: show key tags, algorithm names, and KSK/ZSK roles
shohei cloudflare.com --dnssec --verboseStep through the full resolution path — root servers → TLD nameservers → authoritative nameservers.
shohei google.com --trace# DNS-over-HTTPS
shohei google.com --doh https://dns.google/dns-query
# DNS-over-TLS
shohei google.com --dot 1.1.1.1:853
# DNS-over-QUIC
shohei google.com --doq 8.8.8.8
# Custom resolver
shohei google.com --server 8.8.8.8When querying an authoritative server directly, shohei displays the Authority Section (NS referrals) and Additional Section (glue A/AAAA records) — matching dig's default behavior.
# Query the .com TLD nameserver for google.com — shows NS referral + glue records
shohei google.com -s 192.5.6.30 --no-recurse
# Query an authoritative nameserver directly
shohei example.com -s 199.43.135.53 --no-recurse --type nsForce DNS queries over TCP instead of UDP. Useful for large responses that get truncated (TC bit set) or environments that block UDP/53.
shohei example.com -s 8.8.8.8 --tcpStrip all decoration and return just the record data — one value per line. Ideal for shell scripting.
shohei gmail.com --type MX --shortQuery the same domain from multiple DNS servers simultaneously and diff the results. Useful for detecting CDN anycast differences or verifying a new resolver. Repeat --compare for N-way comparison.
# Show that both servers return the same NS records
shohei cloudflare.com --type NS --server 8.8.8.8 --compare 1.1.1.1
# Reveal CDN-induced A record differences
shohei google.com --server 8.8.8.8 --compare 1.1.1.1
# N-way comparison across three resolvers
shohei google.com --server 8.8.8.8 --compare 1.1.1.1 --compare 9.9.9.9Fetch the complete zone from an authoritative server. Requires -s to specify the authoritative nameserver.
shohei zonetransfer.me --axfr -s 81.4.108.41Pipe a newline-separated list of domains and shohei queries each one in sequence.
Lines starting with # are ignored as comments. You can also read targets from a file with -f.
echo -e "google.com\nexample.com\ncloudflare.com" | shohei
cat domains.txt | shohei --type mx --short
shohei -f domains.txt --type mx --shortRepeat the query every N seconds and auto-refresh the display. Press Ctrl+C to stop.
shohei google.com --watch 5 # refresh every 5 seconds
shohei google.com --type A --watch 10shohei google.com --output json # JSON for scripting
shohei google.com --output plain # No colors (CI-friendly)--features tui)Pre-loads records, DNSSEC chain, and trace in parallel, then presents all three as navigable views.
shohei google.com --tui shohei — google.com
┌─ Records ──────────────────────────────────────────────────────────┐
│ Query: google.com (A IN) │
│ │
│ NAME TTL TYPE DATA │
│ ────────────────────────────────────────────────────────────────── │
│ google.com. 120 A 142.250.x.x │
│ ... │
└────────────────────────────────────────────────────────────────────┘
[r] Records [d] DNSSEC [t] Trace [↑↓/jk] Scroll [q] QuitKey | Action |
| Records view |
| DNSSEC chain view |
| Iterative trace view |
| Scroll up |
| Scroll down |
| Quit |
Flag | Short | Description |
|
| Record type (repeatable): |
|
| Reverse DNS — auto-converts IP to PTR query (IPv4 and IPv6) |
|
| Read domains from a file (one per line), like |
|
| DNSSEC chain-of-trust validation tree |
|
| Show verbose detail (key tags, algorithms) in DNSSEC chain |
| Iterative resolution path from root servers | |
| Clear RD bit — query authoritative servers directly; shows Authority + Additional sections | |
| Full zone transfer from the server specified with | |
| Force TCP instead of UDP (requires | |
| DNS query timeout in seconds (default: 5, max: 60) | |
| Output data values only, one per line (script-friendly) | |
| Repeat query every N seconds; Ctrl+C to stop | |
| Query an additional server and diff; repeat for N-way comparison | |
| DNS-over-HTTPS (e.g. | |
| DNS-over-TLS (e.g. | |
| DNS-over-QUIC (e.g. | |
|
| Custom DNS server ( |
| Force queries over IPv4 transport | |
| Force queries over IPv6 transport | |
|
|
|
| Interactive TUI (requires |
Badge | Meaning |
| DNSSEC-validated, full chain of trust verified |
| Zone unsigned, but parent has no DS delegation (expected) |
| Validation failed — signature mismatch or broken chain |
| DNSSEC not requested, or result unclear |
MCP (Model Context Protocol) Server with 168 tools lets Claude Desktop and other AI agents call shohei diagnostics directly:
# 1. Install shohei
cargo install shohei
# 2. Register MCP server in Claude Desktop config:
# ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"shohei": {
"command": "/path/to/shohei-mcp"
}
}
}
# 3. Restart Claude Desktop
# 4. Ask Claude: "Check example.com's TLS certificate"168 Tools Available to Claude (62 modules):
DNS & DNSSEC (10+ tools) — Query records, DNSSEC validation, propagation checks, zone transfers, latency benchmarking
TLS & Certificates (8+ tools) — Chain inspection, DANE/TLSA validation, certificate transparency (CT) logs, OCSP checks, cipher suites
Email Security (6+ tools) — SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT validation with compliance scoring
IP & Network (10+ tools) — IP reputation, reverse DNS, ASN/GeoIP, port scanning, traceroute, IPv6 dual-stack checks
Web Security (12+ tools) — Security headers audit, WAF/CDN detection, technology fingerprinting, HTTP/2/3 detection, redirect analysis
OSINT & Recon (15+ tools) — WHOIS, domain age, subdomain enumeration, typosquatting detection, parked domain detection, brand name checker
Threat Intelligence (10+ tools) — CVE lookup, VirusTotal integration, URLhaus checking, Shodan queries, breach database lookups
Governance & Compliance (8+ tools) — BGP/RPKI validation, GDPR compliance checking, email authentication chain (ARC), DNS amplification risk
Crypto & Blockchain (10+ tools) — Ethereum address validation, cryptocurrency holder detection, blockchain WHOIS
Advanced Analysis (19+ tools) — Entity relationship graphs, brand detection, URL analysis, redirect domain age, compliance reports, HASSH fingerprinting, cloud exposure, network reputation
URL Intelligence (4 tools) — URL parsing, security intelligence, defacement detection, analytics
Cloud Exposure (4 tools) — Cloud provider asset detection, misconfiguration scanning, cloud infrastructure analysis
OSINT Expansion (4 tools) — Advanced recon techniques, infrastructure mapping, historical data queries
Network Reputation (3 tools) — ISP reputation, network behavior analysis, threat scoring
Cloud Infrastructure (4+ tools) — AWS/GCP/Azure resource exposure, misconfigured storage detection, IAM policy analysis
Credential Security (4+ tools) — Leaked credential checks, API key exposure scanning, secret detection in public resources
Supply Chain Security (4+ tools) — Dependency vulnerability analysis, package registry integrity checks, typosquatting in package names
Web Intelligence (5 tools) — robots.txt analysis, .well-known discovery, OAuth/OIDC audit, cert pinning, API debug endpoint exposure
Service Exposure (4 tools) — Unauthenticated database access (Redis/MongoDB/Elasticsearch), Docker/Kubernetes API exposure, service fingerprinting, DGA risk scoring
Subdomain Takeover (3 tools) — 30+ service signatures (GitHub Pages, Heroku, Netlify, Vercel, Azure, AWS, Shopify…), RIPE Stat passive DNS, Azure AD tenant exposure
Email Advanced (2 tools) — DKIM key strength (1024 vs 2048 vs Ed25519), MX server STARTTLS deep audit
Attack Surface (1 tool) — Composite CVSS-like score aggregating TLS + web headers + email + network exposure
Example: Claude diagnoses a domain autonomously:
"Check if example.com's mail configuration is correct, and verify its TLS certificate chain" → Claude calls check_email_security + check_tls_chain → returns full analysis
Rust Library: use shohei; in your projects — structured async APIs
CLI: Manual inspection: shohei example.com --dnssec --trace
JSON output: Scripting and tooling: shohei example.com --output json
See docs/INTEGRATIONS.md for full details.
hickory-dns — DNSSEC, DoH, DoT support
clap — CLI argument parsing
ratatui — TUI framework (optional tui feature)
owo-colors — Terminal colors
comfy-table — Record table rendering
MIT — see LICENSE
Benchmark DNS latency across transports
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to benchmark | |
| transports | No | Transports to test (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the tool benchmarks latency but does not reveal that it makes network requests, potential rate limits, or whether it is read-only. For a benchmark tool, these gaps are significant.
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 extremely concise at 5 words, front-loaded with key information. It earns its place but could add a bit more context without becoming verbose. Still very efficient.
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 (benchmark, 2 params, no output schema, no dependencies), the description is too sparse. It does not explain return values, valid transport values, duration of benchmark, or how it differs from check_dns. Incomplete for confident use.
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 100% with both parameters described ('Domain to benchmark', 'Transports to test'). The description adds no extra meaning beyond what the schema provides—it does not specify transport formats (e.g., UDP/TCP/DoH) or latency units. Baseline 3 is appropriate.
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 'Benchmark DNS latency across transports' uses a specific verb (benchmark) and resource (DNS latency) with scope (across transports). It clearly distinguishes from sibling tools like check_dns, which likely checks DNS resolution status rather than performance.
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 implies usage for performance testing but does not explicitly state when to use benchmark_latency versus alternatives like check_dns. No exclusions or conditional guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check DNS records for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to query | |
| record_types | No | Record types (A, AAAA, MX, TXT, etc) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal behavioral info; with no annotations, the description should disclose side effects, errors, or operational details (e.g., query method, rate limits), but none are provided.
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?
Description is a single sentence, which is concise but could benefit from additional context without being verbose.
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?
With no output schema and no annotations, the description should explain return values or results; it only states a generic action, leaving the agent uninformed about output.
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 100%, so the description adds no extra meaning beyond the schema definitions; baseline score applies.
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?
Description clearly states verb 'check' and resource 'DNS records for a domain', distinguishing it from sibling tools like benchmark_latency or check_tls_chain.
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?
No guidance on when to use this tool versus alternatives; lacks context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check email security (MX, SPF, DKIM, DMARC)
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool checks DNS-based email security records but does not mention side effects, rate limits, or that it performs external DNS queries. Adequate but not comprehensive.
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 a single, concise sentence (8 words) with no filler. Every word is essential and the primary verb 'Check' is front-loaded.
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 no output schema, the description should indicate what the tool returns (e.g., results for each check). It only states what it checks, leaving the agent to infer return format. Adequate for a simple tool but incomplete.
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?
The input schema already describes the 'domain' parameter as 'Domain to check', achieving 100% coverage. The tool description adds no additional meaning beyond what the schema provides.
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 clearly states the tool checks email security, listing specific components MX, SPF, DKIM, DMARC. This distinguishes it from sibling tools like check_dns (generic DNS) and check_tls_chain (TLS).
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 implies usage for checking email security but provides no explicit guidance on when to use this tool vs alternatives like check_dns or benchmark_latency. No exclusion criteria or alternative mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check DNS propagation across 6 global resolvers
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'check DNS propagation across 6 global resolvers', but does not describe if it is read-only, what the resolvers are, rate limits, or any side effects. This is minimal transparency.
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 a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded and efficient, though slightly terse.
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 has one parameter and no output schema, the description is somewhat adequate. However, it does not explain what the output looks like or any error conditions, leaving gaps for an agent to fully understand the tool's behavior.
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 description coverage is 100% (the only parameter 'domain' has a description 'Domain to check'). The description does not add additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
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 'Check DNS propagation across 6 global resolvers' uses a specific verb 'Check' and resource 'DNS propagation' with a clear scope 'across 6 global resolvers'. This distinguishes it from sibling tools like check_dns, which likely checks a single DNS record.
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 does not provide explicit guidance on when to use this tool vs alternatives. It implies usage from the name and description but lacks explicit when-to-use or when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect TLS certificate chain for a hostname
| Name | Required | Description | Default |
|---|---|---|---|
| check_dane | No | Check DANE/TLSA records | |
| hostname | Yes | Hostname to inspect | |
| port | No | Port (default 443) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the basic 'inspect' action. It omits details on mutability, authentication needs, rate limits, or error behavior, which is a significant gap for a tool with zero annotation coverage.
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 a single, front-loaded sentence with no wasted words. It is concise and to the point.
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?
For a security inspection tool with no output schema and no annotations, the description lacks details on return values, error conditions, or behavioral context like certificate validation depth. It feels incomplete.
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 description coverage is 100%, so the schema already documents all parameters (hostname, port, check_dane). The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
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 'Inspect TLS certificate chain for a hostname' clearly states the specific verb (inspect) and resource (TLS certificate chain), and is distinct from sibling tools like check_dns or check_email_security.
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?
No guidance on when to use this tool versus alternatives such as check_dns or check_email_security. The description does not mention use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0benchmark_latencycheck_dnscheck_email_securitycheck_propagation_globalcheck_tls_chainScored across 5 tools
Each tool has a distinct purpose: DNS latency benchmarking, DNS record checking, email security checks, DNS propagation, and TLS certificate inspection. No overlapping functionality.
All tools use snake_case with a verb_noun pattern: 'benchmark_latency' and 'check_*' variants. Consistent and predictable.
5 tools is a well-scoped set for a DNS/network diagnostic server, covering key operations without excessive overload.
Covers DNS benchmarking, records, propagation, email security, and TLS chains. Minor gaps like reverse DNS or DNSSEC, but sufficient for typical diagnostics.
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
Remote MCP server: 19 domain-hygiene and email-auth tools (DNS, SPF, DMARC, DKIM, TLS).
Monitors TLS/SSL certificate expiry, DNS resolution, and TCP port status for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.