Loading ToolBench
Read-only MCP server for fyzno.com. Three free reports on any domain: mail security (SPF, DKIM, DMARC, MTA-STS, live STARTTLS), website security (headers, CSP, TLS, cookies) and DNS hygiene (name servers, CAA, SOA). Zero dependencies.
Fyzno MCP demonstrates solid definition quality with consistent naming patterns, comprehensive descriptions, and proper JSON Schema. All 17 tools follow verb_noun conventions (site_status, mail_health_check, check_spf). Descriptions are detailed (100-300 chars typical), explaining WHAT each tool does and WHEN to use it. Input schemas are present and properly typed. However, parameter descriptions lack depth, most only state 'The domain to check, e.g. example.com' without explaining validation rules, format constraints, or error cases. Output schemas are undocumented in the visible code, forcing LLMs to infer response structure. Error handling is present but generic. No tool annotations (readOnlyHint, destructiveHint) despite all tools being read-only.
BIMI: the default._bimi TXT record, v=BIMI1, the logo URL, whether the logo is served as SVG, and whether a verified mark (a=) backs it. Optional; never moves the score.
The mail server's certificate: validity period, hostname match, issuer, key strength. Not tested when this machine cannot reach the mail server.
DKIM: the selectors receivers try first, the key behind them, its length, and the canonicalization tags.
DMARC: the policy (p), the subdomain policy (sp), alignment (adkim, aspf), the reporting addresses (rua, ruf), and pct.
The apex AAAA record and whether advertised mail hosts answer over IPv6. Optional; never moves the score.
MTA-STS: the _mta-sts TXT record, the policy fetched over HTTPS from mta-sts.<domain>, its mode, MTA-STS-ID, and max_age.
Output schemas undocumented. Tool descriptions explain what each returns (e.g., '0-100 score, verdict, findings') but no formal JSON Schema is visible in code. LLMs cannot reliably parse responses or plan downstream operations without documented output structure.
Parameter descriptions lack validation rules and format constraints. All domain parameters state only 'The domain to check, e.g. example.com' without explaining accepted formats, length limits, or what happens if invalid.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
The sending server's IP against Spamhaus ZEN. ZEN only; no other blocklists.
The MX records: present, resolvable, no duplicates, a null MX only as a deliberate sink, and the fallback when there are none.
A live STARTTLS handshake with the mail servers: TLS supported, the protocol and cipher negotiated. Reported as not tested when this machine cannot reach port 25.
The SPF record: present, syntactically valid, the mechanism walk (a, mx, ip4, ip6, include, ptr), the DNS lookup count, and whether the list actually closes.
TLS-RPT: the _smtp._tls TXT record and where TLS failure reports between servers are sent (rua).
Run the free DNS hygiene check for a domain: name servers (present, resolvable, no duplicates, no single points of failure), SOA record (present, reasonable TTL and retry values), DNSSEC (signed, valid chain, no algorithm warnings), and CAA records (present, restrictive, no wildcards). Returns a 0-100 score, a verdict, and one finding per check.
Run the free mail health check for a domain: mail routing, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, a live SMTP STARTTLS handshake, the mail server's certificate, and the sending server's Spamhaus ZEN listing. Returns a 0-100 score, a verdict, and one finding per check with sub-checks. Optional checks (BIMI, IPv6, web security headers) are informational and never move the score. For a single check use the check_* tools (check_spf, check_dkim, ...) instead.
The pages of the site with one line on what each contains. Use it to find where a specific fact lives.
The public facts an agent needs to represent the site: who we are, what we do and what we refuse, how to reach a human, and the list of pages and endpoints. Everything is already public on a page.
Current status of the Fyzno infrastructure: what is running, measured uptime, and the incident record. Read-only.
Run the free website security check for a domain: HTTP security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection), TLS version and cipher strength, certificate validity and hostname match, and cookie security (Secure, HttpOnly, SameSite). Returns a 0-100 score, a verdict, and one finding per check.
No tool annotations despite all tools being read-only. MCP spec supports readOnlyHint annotation to signal safe tools. This helps agents reason about side effects and retry safety. All 17 tools should carry readOnlyHint: true.
Error handling is present but generic. Code shows errors returned as { isError: true, content: [...] } but descriptions do not guide LLMs on recovery.
No pagination or result limits documented. Tools like site_data and pages may return large lists, but no limit, offset, or cursor parameters are visible.