# admintoolkit.io — Full Tool Reference > admintoolkit.io provides 24 read-only browser diagnostics for IP, DNS, mail, HTTP headers, TLS certificates, subnets, EDID, and agent- and AI-web metadata. This optional English companion provides self-contained technical context for agents and reviewers. The concise `/llms.txt` file remains the primary discovery and navigation document. admintoolkit.io is a free, public suite of 24 browser-based, read-only diagnostic tools for DNS, email security, TLS, HTTP, networking, and agent-discovery metadata; it is not a monitoring, automatic-remediation, or configuration-management service. Each result is point-in-time diagnostic evidence for the exact target and input from the matching canonical tool page and published contract; limitations remain part of the result rather than a guarantee. Results exist only for checks the user explicitly ran; nothing is precomputed or inferred. Network-backed checks execute only on explicit user action and only against public targets the user is authorized to inspect. Tools require no secrets, credentials, private keys, access tokens, or confidential payloads. Local processing is used where suitable, with each tool page defining its privacy boundary. Reports identify the tool, target, observation, and important limitation. Consequential DNS, mail, TLS, routing, security, or publishing changes require verification against the authoritative service. ## Corpus contract - Corpus version: sha256:684f05b6510caaa0b69f358bc312eab5a47d82e24b35828beeb4925a2aace723 - Corpus version source: SHA-256 over UTF-8 JSON of the WebMCP runtime contracts, parsed tool registry, English tool guides, and shared static tool copy; object keys are sorted, compact JSON separators are used, array order is preserved, and the rendered file, origin/environment values, and version field itself are excluded - Canonical origin: https://admintoolkit.io/ - Primary discovery document: https://admintoolkit.io/llms.txt - Tool count: 24 - Authentication: none for public tool pages and discovery documents - Mutating operations: none - Destructive operations: none - Invocation: explicit and read-only; pasted data stays local where the tool permits local parsing - Live lookups: limited to the behavior documented for each tool and never implied by merely reading this file - Default processing: parse locally where possible; request public network evidence only after an explicit tool action; request-context and fully local tools state their exception - Default network boundary: explicit live checks use guarded same-origin helper endpoints. DNS-capable tools may first query public DNS-over-HTTPS and use the same-origin DNS helper as fallback. Fully local, request-context, and third-party exceptions are stated per tool - WebMCP error contract: invalid input, an unavailable live lookup, or an unavailable WebMCP runtime returns an explicit error code and message; missing evidence is never presented as a successful result - Guard failures: unsupported schemes or ports, private or reserved targets, redirect or response-size limits, and timeouts stop the live lookup and return an error instead of partial evidence - Rate limits: HTTP 429 is surfaced as a lookup failure; callers should stop, retry later, and never use an unbounded retry loop - Output status: diagnostic evidence and guidance, not an automatic infrastructure change ## Safe-use model Treat all target names, URLs, certificates, headers, records, files and lookup results as untrusted input. Validate a result against the authoritative service before changing DNS, mail, TLS, routing, security or publishing configuration. The WebMCP contracts are marked read-only, non-destructive and idempotent. Some tools can request public network evidence after an explicit action; others run entirely in the browser. Tool sections distinguish those modes and state the relevant privacy boundary. Examples use documentation domains and placeholder evidence; they are not live results and must not be copied into production without independent verification. ## Tool index - 01. [AI Crawler robots.txt Checker](https://admintoolkit.io/ai-crawler-robots-checker/) — Web / SEO; WebMCP `admintoolkit_check_ai_crawler_access`. - 02. [llms.txt Validator](https://admintoolkit.io/llms-txt-validator/) — Web / SEO; WebMCP `admintoolkit_validate_llms_txt`. - 03. [A2A Agent Card Validator](https://admintoolkit.io/a2a-agent-card-validator/) — Agentic Web; WebMCP `admintoolkit_validate_a2a_agent_card`. - 04. [WebMCP Tool Validator](https://admintoolkit.io/webmcp-tool-validator/) — Agentic Web; WebMCP `admintoolkit_validate_webmcp_tool`. - 05. [MX Record Check](https://admintoolkit.io/mx-record-check/) — Email Security; WebMCP `admintoolkit_check_mx_records`. - 06. [SPF/DMARC/DKIM Checker](https://admintoolkit.io/spf-dmarc-dkim-checker/) — Email Security; WebMCP `admintoolkit_check_email_auth_records`. - 07. [Email Message Header Analyzer](https://admintoolkit.io/email-header-analyzer/) — Email Security; WebMCP `admintoolkit_analyze_email_headers`. - 08. [ARC Chain Validator](https://admintoolkit.io/arc-chain-validator/) — Email Security; WebMCP `admintoolkit_validate_arc_chain`. - 09. [BIMI Checker/Generator](https://admintoolkit.io/bimi-checker-generator/) — Email Security; WebMCP `admintoolkit_check_bimi_record`. - 10. [MTA-STS Checker/Generator](https://admintoolkit.io/mta-sts-checker-generator/) — Email Security; WebMCP `admintoolkit_check_mta_sts_policy`. - 11. [TLS-RPT Checker/Generator](https://admintoolkit.io/tls-rpt-checker-generator/) — Email Security; WebMCP `admintoolkit_check_tls_rpt_policy`. - 12. [SMTP TLS Handshake / Mail Domain Delivery Readiness](https://admintoolkit.io/smtp-tls-readiness-checker/) — Email Security; WebMCP `admintoolkit_check_smtp_tls_readiness`. - 13. [DNSSEC Validator](https://admintoolkit.io/dnssec-validator/) — DNS Security; WebMCP `admintoolkit_validate_dnssec_records`. - 14. [TLSA Record Checker/Generator](https://admintoolkit.io/tlsa-record-checker-generator/) — DNS Security; WebMCP `admintoolkit_generate_tlsa_record`. - 15. [DANE Validator](https://admintoolkit.io/dane-validator/) — DNS Security; WebMCP `admintoolkit_validate_dane_records`. - 16. [CAA Record Checker/Generator](https://admintoolkit.io/caa-record-checker-generator/) — DNS Security; WebMCP `admintoolkit_check_caa_records`. - 17. [HTTP Header Analyzer](https://admintoolkit.io/http-header-analyzer/) — Web Security; WebMCP `admintoolkit_analyze_http_headers`. - 18. [SSL Certificate Decoder](https://admintoolkit.io/ssl-cert-decoder/) — Web Security; WebMCP `admintoolkit_decode_ssl_certificate`. - 19. [security.txt Validator/Generator](https://admintoolkit.io/security-txt-validator-generator/) — Web Security; WebMCP `admintoolkit_validate_security_txt`. - 20. [TLS Configuration Checker](https://admintoolkit.io/tls-configuration-checker/) — Web Security; WebMCP `admintoolkit_check_tls_configuration`. - 21. [Redirect / Canonical / Indexability Checker](https://admintoolkit.io/redirect-canonical-indexability-checker/) — Web / SEO; WebMCP `admintoolkit_check_redirect_indexability`. - 22. [What is my IP?](https://admintoolkit.io/what-is-my-ip/) — Network; WebMCP `admintoolkit_show_public_ip_context`. - 23. [CIDR/Subnet Calculator](https://admintoolkit.io/cidr-subnet-calculator/) — Network; WebMCP `admintoolkit_calculate_cidr_subnet`. - 24. [HDMI EDID Decoder](https://admintoolkit.io/edid-decoder/) — Hardware / AV; WebMCP `admintoolkit_decode_edid_data`. ## 01. AI Crawler robots.txt Checker - Canonical English page: https://admintoolkit.io/ai-crawler-robots-checker/ - Canonical tool ID: `ai-crawler-robots-checker` - WebMCP tool name: `admintoolkit_check_ai_crawler_access` - Category: Web / SEO - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only RFC 9309 robots.txt access report for AI and search crawlers. Accepts robots.txt text or a public robots.txt URL plus an optional path. Includes merged matching groups, octet-normalized longest-match decisions, per-crawler evidence, transport status, crawler-registry provenance and policy snippets. ["robots.txt has quietly become the place where a site states its relationship with machine visitors, and that audience has changed. Alongside classic search crawlers there are now training crawlers collecting corpus data, retrieval bots answering live user questions, and user-triggered agents fetching a single page on someone's behalf. Each category reads the same file, but blocking one is a completely different decision from blocking another — cutting off search indexing costs visibility, while cutting off training crawlers is a licensing stance.", 'This checker evaluates robots.txt with RFC 9309 matching: it selects the most specific matching product token, merges every group carrying that same token, and uses the wildcard group only when no specific token matches. Path comparison is case-sensitive and octet-normalized; the longest rule wins, with Allow winning an equal-length tie. Every decision keeps the matched groups, winning directive and source line.'] ### Processing and invocation - Input mode: `paste_or_url` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `url` (string; format uri; one-of alternative): Robots.txt URL or bare domain to fetch, e.g. 'https://example.com/robots.txt'. - `path` (string; optional): Path to evaluate against robots.txt rules, e.g. '/' or '/tools/'. - `content` (string; one-of alternative): Pasted robots.txt content to validate locally, e.g. 'User-agent: GPTBot'. - `crawlers` (array of string values; optional): Crawler tokens to evaluate as an array, e.g. ['GPTBot','Google-Extended']. ### Result model - `crawler_decisions` (array of objects) - `matched_groups` (array of objects) - `matched_directives` (array of objects) - `crawler_categories` (array of strings) - `findings` (array of objects) - `fix_snippets` (object) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Start with pasted content, not a live fetch. The paste path analyses the file locally in the browser, which makes it the right place for drafts that are not published yet — a policy change can be rehearsed before any crawler sees it. Add a concrete path such as / or /tools/ to test the rules against the URL shapes that matter, and pass a custom crawler list when the default set does not include the bot you care about.', 'Read the three categories separately before publishing. Search, training and user-triggered agents have different operational meaning, but those labels never alter RFC matching. The registry exposes its source URLs and update date, while custom product tokens are tested independently without an inferred category. A live URL fetch then reports redirects, status, media type and size separately from the parsed policy.'] ### Privacy and data handling Pasted robots.txt stays local. Live fetches use the guarded same-origin helper for public /robots.txt URLs only when requested. ### Limits and non-claims Pasted robots.txt never leaves the browser; the URL mode sends only a public /robots.txt address to the same-origin helper after an explicit request. The parser accepts UTF-8 with an optional BOM and at least 500 KiB, preserves Sitemap and unknown fields separately, and applies RFC 9309 redirect, 4xx-unavailable and temporary 5xx/unreachable semantics without inventing a durable allow or block from a temporary fetch failure. robots.txt remains guidance for compliant crawlers, not access control. ### Safe example example.com/robots.txt -> GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, CCBot, Google-Extended, and user-triggered agents with matched rules. ### Frequently asked questions - **Which crawlers are in the default set?** The dated registry covers documented tokens from OpenAI, Google, Anthropic, Perplexity and Common Crawl, with source links shown as metadata. Search, training and user-triggered labels are explanatory only; any custom product token can be passed and is evaluated independently. - **Does blocking a training crawler remove my content from existing models?** No. robots.txt controls future access by compliant crawlers. Content collected before the block, or gathered by operators that ignore the convention, is outside what this file can influence. - **Why does the report separate Search, Training, and User-triggered categories?** Because they answer different business questions. Blocking search indexing trades away visibility, blocking training is a data-licensing position, and blocking user-triggered agents affects people asking an assistant about your site right now. - **Why does a rule I expected to match not apply?** A crawler selects the most specific matching product token and merges all groups with that same token. Nonmatching groups, including a wildcard group when a specific token matched, are ignored. Within the merged rules, the longest octet match wins and Allow wins an equal-length tie. - **Can I test rules for a path that is not deployed yet?** Yes. Path evaluation is string matching against the pasted or fetched rules, so a planned URL layout can be tested before the first page exists. - **Is a missing robots.txt a problem?** A missing file simply means everything is allowed for compliant crawlers. That is a legitimate policy — it only becomes a problem when it is an accident rather than a decision, which is exactly what a deliberate check makes visible. ## 02. llms.txt Validator - Canonical English page: https://admintoolkit.io/llms-txt-validator/ - Canonical tool ID: `llms-txt-validator` - WebMCP tool name: `admintoolkit_validate_llms_txt` - Category: Web / SEO - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Validate the required initial H1, optional summary and project details, and any H2 resource lists with link titles, URLs, optional descriptions, findings, and source-line evidence. ['llms.txt is a community convention from llmstxt.org, not an IETF or W3C standard and not a guarantee that a model will read the file. Its required structural core is deliberately small: the first structural element is one H1 title, using ATX (#) or Setext (= underline) Markdown syntax. An optional blockquote summary and optional detail text may follow, and the document may contain zero or more H2 sections.', 'H2 sections are not restricted to link-only file lists. They may contain ordinary Markdown, nested headings, prose, lists, relative links, fragments, reference links, and Unicode. The validator checks the required H1 and Markdown boundary cases, inventories sections and links as evidence, and keeps grammar findings separate from fetch status, redirects, media type, and size.'] ### Processing and invocation - Input mode: `paste_or_url` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `url` (string; format uri; one-of alternative): llms.txt URL or bare domain to fetch, e.g. 'https://example.com/llms.txt'. - `content` (string; one-of alternative): Pasted llms.txt Markdown content to validate locally, e.g. '# Example'. - `detail` (string; allowed: `compact`, `full`; optional): Optional response size: 'compact' (default) returns findings, counts, section summaries and bounded link evidence; 'full' also returns the raw llms.txt source and the complete per-section and per-link document model, e.g. 'full'. ### Result model - `title` (string) - `summary` (string) - `section_count` (integer) - `link_count` (integer) - `required_link_count` (integer) - `optional_link_count` (integer) - `findings` (array of objects) - `source_preview` (string) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Validate drafts locally first. Pasted Markdown is analysed entirely in the browser, which means an unpublished llms.txt can be checked without exposing it anywhere. Fix structural findings such as a missing or duplicated initial H1, an H2 before the H1, an unclosed fenced block, or an unresolved reference link. H2 resource entries are parsed as Markdown links; other H2 content remains visible as raw evidence and is reported as partially or not interpreted.', 'Then check the published reality. The URL mode fetches a live /llms.txt through the same-origin helper and answers a different question: not whether your draft is well-formed, but whether what the site actually serves matches what you meant to publish. Deployment pipelines, redirects, and content negotiation all sit between the repository and the wire, and the second check regularly catches what the first one cannot.'] ### Privacy and data handling Pasted content stays in the browser. URL fetches run only after clicking and use the guarded same-origin helper with public-host checks and size limits. ### Limits and non-claims Pasted content stays in the browser. URL fetches go through /api/admin-tools-live.php with public-host, port, timeout, path, and response-size guards. HTTP status, redirects, Content-Type, and size are reported as transport evidence separately from Markdown grammar. The validator does not grade prose quality and cannot promise that any crawler or model reads or honors the file. ### Safe example Paste a draft or fetch https://example.com/llms.txt, then check the title, summary, project details, sections, resource titles, URLs, optional descriptions, findings, and source lines. ### Frequently asked questions - **What is the minimum valid llms.txt shape?** Only the initial H1 is required. A file may also contain a blockquote summary and additional project details before its H2 sections. If H2 sections are present, their resource entries contain Markdown links and may include an optional description after a colon. - **Can I validate a draft without publishing it?** Yes — that is the intended first step. Paste the draft and run the local validation; no fetch happens and nothing leaves the browser until you explicitly request a URL check. - **Why is the URL fetch routed through a same-origin helper?** Because browsers cannot read arbitrary cross-origin text files under CORS. The helper performs one narrow, size-limited fetch of a public /llms.txt after your click and hands the bytes back for analysis. - **What belongs in the Optional section?** The convention gives a section named Optional special meaning for material that may be skipped when context is scarce. The section itself is optional, and other H2 sections may use normal Markdown rather than a prescribed list-only grammar. - **Does a valid llms.txt guarantee that AI systems use it?** No. The convention is an offer, not a contract. Validation removes the structural reasons for a crawler to ignore the file; whether an operator reads it remains that operator's decision. - **How does llms.txt relate to robots.txt and sitemap.xml?** They answer different questions: robots.txt states access policy, the sitemap enumerates URLs for indexing, and llms.txt curates what a language model should read first. A coherent site keeps the three consistent instead of treating them as substitutes. ## 03. A2A Agent Card Validator - Canonical English page: https://admintoolkit.io/a2a-agent-card-validator/ - Canonical tool ID: `a2a-agent-card-validator` - WebMCP tool name: `admintoolkit_validate_a2a_agent_card` - Category: Agentic Web - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only version-aware A2A Agent Card validation report. Includes v0.2, v0.3 and v1.0 structure plus discovery-path evidence without claiming endpoint, authentication or signature conformance. ['In the A2A protocol, an Agent Card is the entire first impression: a JSON document at a well-known URL that tells other agents who you are, which skills you offer, which endpoints and transports you speak, and how callers must authenticate. Consuming agents parse it mechanically. A missing required field, a skill without a description, or auth metadata that contradicts your actual deployment does not produce a friendly error on the other side — it produces silent incompatibility, and the calling agent simply moves on.', "This validator first recognizes the card shape as A2A v0.2, v0.3, or v1.0, and reports an ambiguous version instead of forcing mixed fields through an arbitrary schema. It then applies that version's identity, transport/interface, skill, capability, security, and discovery-path rules while preserving unknown extension fields."] ### Processing and invocation - Input mode: `paste_or_url` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `url` (string; format uri; one-of alternative): Agent Card URL or bare domain to fetch, e.g. 'https://example.com/.well-known/agent-card.json'. - `json` (string; one-of alternative): Pasted Agent Card JSON to validate locally, e.g. '{"name":"Agent"}'. ### Result model - `agent_name` (string) - `version` (string) - `skills` (array of objects) - `interfaces` (array of objects) - `capabilities` (object) - `security_schemes` (object) - `findings` (array of objects) - `fix_snippets` (object) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['While drafting, paste the JSON directly and fix errors before warnings: errors are the fields a conforming consumer is entitled to rely on, warnings are where interoperability gets quietly worse. Pay particular attention to skill descriptions — they are what a selecting agent, or the model behind it, reasons over. A vague skill description is the agent-world equivalent of a broken link: syntactically fine, practically useless.', 'After deployment, fetch the card from its public well-known URL rather than pasting from your repository, because the interesting bugs live in the serving path: a redirect that strips the path, a proxy rewriting content types, an old version cached at the edge, or TLS terminating on a name the card does not mention. The fetched card is the one every other agent sees; validating anything else is validating a hope.'] ### Privacy and data handling Pasted JSON stays local. Live fetches use the guarded same-origin helper for the public well-known Agent Card URL only when requested. ### Limits and non-claims ["Pasted JSON stays in the browser, and live fetches run through the same-origin helper against the public card URL only. The validator never contacts the agent behind the card: no skill invocation, no task submission, no JSON-RPC traffic, no callback execution. It checks the practical fields this page can verify locally — treat a pass as a solid preflight, then confirm conformance against the official A2A schema and your implementation's own tests."] ### Safe example https://agent.example/.well-known/agent-card.json -> required fields, skills, protocol bindings, capabilities, and security metadata. ### Frequently asked questions - **Where does the card have to live?** For v0.2 the historical well-known path is /.well-known/agent.json. v0.3 and v1.0 use /.well-known/agent-card.json. An explicit card URL can also be validated, but that is reported separately from successful well-known discovery. - **Does validating the card test my agent?** No. A valid result proves only the checked JSON structure and retrieval evidence. It does not invoke an endpoint, prove authentication, validate protocol behavior, or cryptographically verify a declared signature. - **What belongs in the card and what must never be in it?** Identity, skills, transports, endpoint URLs, and authentication requirements belong. Secrets never do: no API keys, no tokens, no internal hostnames. The card is public by definition — write it assuming adversaries read it too. - **How granular should skills be?** Granular enough that a consuming agent can choose between them by description alone. One do-everything skill forces callers to guess; a dozen near-identical skills force them to disambiguate. Skill boundaries are API design, with a model as the reader. - **Why declare authentication in the card at all?** So callers can decide whether they can talk to you before the first request fails. Declared schemes must match the deployment exactly — advertising OAuth while enforcing API keys costs every consumer one confusing round-trip, or the integration entirely. - **How often should the card change?** Whenever skills, endpoints, transports, or auth change — atomically with the deployment, treated as an API contract under version control. A stale card teaches other agents wrong facts about you, and they act on those facts. ## 04. WebMCP Tool Validator - Canonical English page: https://admintoolkit.io/webmcp-tool-validator/ - Canonical tool ID: `webmcp-tool-validator` - WebMCP tool name: `admintoolkit_validate_webmcp_tool` - Category: Agentic Web - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only WebMCP report for pasted or fetched source. Includes declarative and imperative static-source evidence separately from caller-provided runtime observation; pasted JavaScript is never executed and active runtime tools are never inferred from source alone. ['WebMCP lets a page offer its capabilities to agents as named tools, and the metadata is the entire interface: an agent sees a name, a description, and parameter definitions — not your source code and not your intentions. Vague descriptions, unnamed parameters, or side-effect wording that hides a mutation behind a harmless verb do not merely look untidy; they cause an agent to call the wrong tool, with the wrong arguments, at the wrong moment, while a human approves the call based on the same misleading words.', 'This validator inspects declarative form metadata and statically attributable document.modelContext.registerTool calls without evaluating JavaScript or a DOM. Static source evidence is kept separate from actual runtime observation: active tools are reported only when a caller-provided browser hook really observes them.'] ### Processing and invocation - Input mode: `paste_or_url` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `url` (string; format uri; one-of alternative): Public page URL to fetch for WebMCP validation, e.g. 'https://example.com/'. - `source` (string; one-of alternative): Pasted HTML or JavaScript source to validate locally, e.g. 'data-tool-name=demo'. - `detail` (string; allowed: `compact`, `full`; optional): Optional response size: 'compact' (default) returns findings, counts and static-source evidence; 'full' also returns the complete fetched page text in metadata.text, e.g. 'full'. ### Result model - `declarative_forms` (array of objects) - `imperative_registrations` (array of objects) - `parameter_quality` (array of objects) - `labels` (array of strings) - `security_findings` (array of objects) - `fix_snippets` (object) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ["Paste the smallest fragment that reproduces the question: one form, one registration block, one component's markup. Static analysis has no execution context anyway, so surrounding boilerplate adds noise rather than signal. Fix the blunt problems first — missing tool names, descriptions that could describe anything, parameters without labels — because those defeat agents before any subtle issue matters.", 'Then distinguish errors from observability limits. Missing required names, descriptions, or execute handlers are structural errors; indirect schemas, aliases, object spreads, dynamic registration, and removal lifecycles may be impossible to prove statically and are reported as such. Nested JSON Schema constructs such as $ref, oneOf, anyOf, arrays, and enums are not rejected merely because they are complex.'] ### Privacy and data handling Pasted HTML and JavaScript stay local and are never executed. Live fetches use the guarded same-origin helper for public pages only when requested. ### Limits and non-claims Pasted HTML and JavaScript stay in the browser and are never executed; fetched source is also inspected statically. Comments and string literals are masked to avoid false detections, and unrelated registerTool methods are not treated as WebMCP. Static inspection cannot prove an active registration or call behavior. Runtime tools are reported only when actually observed by an explicit browser hook. ### Safe example Paste WebMCP markup or fetch page source for static evidence; active runtime tools remain not observed unless an explicit browser hook supplies them. ### Frequently asked questions - **Does the validator execute pasted JavaScript?** No. Pasted code is treated purely as text to search for registration patterns and metadata. Nothing is evaluated, and no network request results from pasting. - **Does description quality decide validity?** No. A missing or empty required description is structural; keyword length or style is not a conformance gate. Any side-effect wording signal is informational and cannot prove runtime behavior. - **Why do parameter labels matter so much?** Labels are how humans and agents map a field to an intent without guessing. An unlabeled parameter forces every caller to infer meaning from the variable name — and that inference is exactly what tool metadata exists to remove. - **What counts as risky side-effect wording?** Descriptions that hide mutation behind neutral verbs — a delete presented as manage, a payment presented as confirm. The check flags wording where the action an agent would predict diverges from the action actually implied. - **Which registration style should a page prefer?** The current proposal uses document.modelContext.registerTool. navigator.modelContext is treated only as a compatibility pattern, and aliases derived from either modelContext can be recognized without executing the source. - **Can this validate every WebMCP runtime?** No. It is a static preflight for markup and recognizable registration hints. Runtime behavior, permission prompts, and actual call semantics need a live agent test — ideally after the static findings are already clean. ## 05. MX Record Check - Canonical English page: https://admintoolkit.io/mx-record-check/ - Canonical tool ID: `mx-record-check` - WebMCP tool name: `admintoolkit_check_mx_records` - Category: Email Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only MX routing report for a mail domain. Accepts a domain name. Includes exchanger hosts, preferences, Null MX, CNAME risk, address resolution and actionable mail-routing warnings. ['MX records are the routing table of email: they name the hosts willing to receive mail for a domain and the order in which senders should try them. Almost every delivery mystery starts here, because MX is where DNS intent and mail reality first touch — a domain can have perfect SPF and DMARC and still lose mail to a stale exchanger, a CNAME target that violates the standard, or a forgotten Null MX that politely tells the world the domain accepts nothing.', 'This check reads the published MX set, sorts it by preference, resolves the first exchangers to A and AAAA addresses, and calls out the routing patterns that cause real incidents: missing records, Null MX, CNAME targets, and dead hostnames. It is deliberately a DNS-only view — no SMTP connection is opened — which makes it fast, safe, and honest about which layer it examines.'] ### Processing and invocation - Input mode: `form` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `domain` (string; required): Mail domain to check via DNS MX lookup, e.g. 'example.com'. ### Result model - `mx_records` (array of objects) - `resolved_addresses` (array of objects) - `warnings` (array of objects) - `lookup_timestamp_utc` (string) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Enter the domain and read the interpretation before the raw records: the ordering, the preference values, and the warnings often answer the actual question directly. Lower preference wins; equal preferences distribute across hosts. Then check whether the first exchangers resolve — both IPv4 and IPv6 — because a hostname without addresses, or one that only resolves in one address family, produces exactly the kind of intermittent delivery failure that is miserable to debug from the outside.', "For delivery incidents, pair this result with evidence from the other direction: the Received chain of a real message shows which exchanger actually accepted the mail, and the domain's SPF, DKIM, and DMARC records govern whether it was trusted after arrival. Routing and authentication fail differently — MX problems tend to lose or delay mail wholesale, authentication problems file it in spam — and knowing which family you are in halves the search space."] ### Privacy and data handling The domain is sent only after you start the lookup. Browser DNS-over-HTTPS is tried first, with same-origin DNS fallback if needed. The tool does not open SMTP connections. ### Limits and non-claims The domain is sent only after you start the lookup; the browser tries Cloudflare DNS-over-HTTPS first and falls back to the same-origin DNS helper if that path fails. The tool does not open SMTP sessions, does not test STARTTLS, and cannot prove delivery from any particular sender — it shows what DNS currently instructs senders to do, which is a necessary truth but not the whole one. The page keeps no lookup history, though resolvers and hosting infrastructure keep their own operational logs. ### Safe example example.com -> MX preference, exchanger host, first A and AAAA answers, and Null MX or CNAME warnings. ### Frequently asked questions - **What does a lower MX preference mean?** Lower values are tried first; senders only move to higher-preference hosts when the preferred ones fail. Equal values let the sender pick freely, which is how simple load distribution across exchangers is done. - **What is Null MX and when is it right?** A single MX record with preference 0 and a target of just a dot declares that the domain accepts no mail at all. For genuinely mail-free domains it is the correct, explicit signal — much better than leaving senders to time out against nonexistent servers. - **Why is a CNAME as MX target flagged?** Because the standards require MX targets to be hostnames with address records, not aliases. Many receivers tolerate CNAME chains, but tolerant is not the same as reliable — some sending implementations mishandle them, producing failures that only certain peers ever see. - **Why does the tool show A and AAAA records?** To confirm the advertised exchangers actually exist as addresses, and in which address families. A host that resolves only over IPv4 while a sender prefers IPv6 is a classic source of asymmetric delivery behavior. - **A backup MX looks dead — is that urgent?** Sooner rather than later, yes. In quiet times nobody notices, but senders fall back to higher-preference hosts exactly when the primary struggles — the moment a dead backup turns a partial outage into lost mail. - **Are queried domains stored by this app?** The page does not save a lookup history. The DNS provider and normal hosting infrastructure may still keep their own operational logs, like any network service. ## 06. SPF/DMARC/DKIM Checker - Canonical English page: https://admintoolkit.io/spf-dmarc-dkim-checker/ - Canonical tool ID: `spf-dmarc-dkim-checker` - WebMCP tool name: `admintoolkit_check_email_auth_records` - Category: Email Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only SPF, DMARC and DKIM report for a mail domain. Accepts a domain plus optional pasted TXT values. Includes syntax, policy strength, alignment, DNS evidence and record-specific warnings. ['SPF, DKIM, and DMARC are usually configured at different moments, by different tools, under different amounts of time pressure — and mail authentication only works when the three of them tell one coherent story. SPF names the servers allowed to send for the envelope domain, DKIM proves that a signing domain vouched for the message, and DMARC decides what receivers should do when neither of those aligns with the visible From address. Most real-world delivery incidents live in the seams: a second SPF record pasted in by a well-meaning platform guide, a DKIM selector that quietly rotated, a DMARC policy that promises reject while alignment silently fails.', 'This checker reads all three record families for a domain and highlights value-level problems: syntax faults, weak or contradictory policy tags, malformed keys, duplicate records, and owner names that do not match the convention. It works from pasted TXT values when you have zone data in front of you, or from live DNS when what matters is what the world currently resolves.'] ### Processing and invocation - Input mode: `form` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `domain` (string; required): Mail domain to check, e.g. 'example.com'. - `selector_mode` (string; allowed: `manual`, `auto`, `none`; optional): DKIM selector mode: 'auto', 'manual', or 'none', e.g. 'auto'. - `selector` (string; optional): DKIM selector to query, e.g. 's1' or 'default'. - `policy` (string; allowed: `none`, `quarantine`, `reject`; optional): Expected DMARC policy value, e.g. 'reject'. - `spf_record` (string; optional): Pasted SPF TXT record, e.g. 'v=spf1 redirect=spf.example.com'. - `dmarc_record` (string; optional): Pasted DMARC TXT record, e.g. 'v=DMARC1; p=reject'. - `dkim_record` (string; optional): Pasted DKIM TXT value, e.g. 'v=DKIM1; k=rsa; p=...'. ### Result model - `spf_record` (string) - `dmarc_record` (string) - `dkim_owner_name` (string) - `dkim_record_summary` (object) - `dns_lookup_result` (object) - `warnings` (array of objects) - `recommendations` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Paste known records first when you are editing a zone: the parser works locally, so a draft SPF or DMARC value can be corrected before publication. For a live review, enter the domain and — if DKIM is part of the question — the selector your sending platform actually uses; the lookup builds the selector._domainkey names from it. Setting the expected DMARC policy makes the report opinionated in the right way: it shows the distance between what you intend and what is published.', 'Read warnings in order of blast radius. Duplicate SPF records are permerror territory and come first. Then DMARC: policy tag, alignment expectations, reporting addresses. DKIM key shape follows — algorithm, key length, empty or revoked keys. Publish changes one record family at a time and re-run the check after DNS has settled, so a regression stays attributable to the change that caused it.'] ### Privacy and data handling Pasted records stay in the browser. Live TXT lookups send only the DNS names needed for the lookup. ### Limits and non-claims Pasted records are parsed entirely in the browser. Live lookups start only on the button press and send just the DNS names required — the domain, the _dmarc owner, and selector-derived names — using DNS-over-HTTPS first with the same-origin DNS helper as fallback. The tool inspects published records; it does not send test messages, cannot observe your real sending path, and therefore cannot prove that a delivered mail will pass DMARC alignment. ### Safe example Check one SPF record, _dmarc policy tags, and selector._domainkey ownership before publishing changes. ### Frequently asked questions - **Can this prove my mail will pass DMARC?** No. It inspects the published records, which is a precondition, not the verdict. A real DMARC pass also depends on the sending path, the envelope domain, the header From domain, the DKIM signature actually applied, and how all of those align. - **Why is a second SPF record such a serious warning?** Because the standard requires exactly one SPF record per name, and many receivers respond to duplicates with a permanent evaluation error — which can fail authentication outright. It typically happens when a SaaS platform's setup guide is followed without checking what already exists. - **Which DKIM selector should I enter?** The one your sending platform configured — s1, default, or a dated selector are common. The lookup queries selector._domainkey.domain, so a wrong selector proves nothing except that this particular name has no key. - **What does alignment actually mean?** That the domain a receiver validated — via SPF's envelope domain or DKIM's signing domain — matches the domain the human sees in From. DMARC only counts authentication that aligns; a valid DKIM signature from an unrelated domain does not help. - **Should I go straight to p=reject?** Not by default. Start with p=none and aggregate reports, remediate legitimate senders, then choose enforcement for the domain's purpose and indirect-mail exposure. RFC 9989 warns that p=reject can be unsuitable for general-purpose user-mail domains; tightly controlled sending domains or subdomains are different. - **Are my pasted records uploaded anywhere?** No. Pasted values stay in the browser session. Only a live DNS lookup sends anything — namely the queried DNS names — to the resolver path. ## 07. Email Message Header Analyzer - Canonical English page: https://admintoolkit.io/email-header-analyzer/ - Canonical tool ID: `email-header-analyzer` - WebMCP tool name: `admintoolkit_analyze_email_headers` - Category: Email Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only email message header report. Accepts pasted RFC 5322 headers. Includes raw Received order, recorded Authentication-Results and caller-configured authserv-id trust; it does not perform cryptographic authentication or reverse-DNS verification. ['Full message headers answer most questions people ask about a suspicious or misbehaving mail — who really handed it over, which systems it crossed, what the receiving side concluded about SPF, DKIM, and DMARC, and where time was lost. The catch is that headers are written for machines, stacked newest-first, rewritten by intermediate systems, and salted with fields that look meaningful but are trivially forgeable. Read naively, they mislead more often than they inform.', 'This analyzer turns a pasted RFC 5322 header block into structured recorded evidence: Received fields in raw newest-first order plus a separate chronological view, Authentication-Results with authserv-id, method versions, properties and caller-configured trust classification, DKIM and ARC field presence, list headers, and parser findings. Recorded pass or fail values are not fresh authentication results. Everything runs locally in the browser — nothing is uploaded.'] ### Processing and invocation - Input mode: `paste` - Processing: fully local; no network path. - Network boundary: none; all diagnostic logic runs entirely in the browser. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `headers` (string; one-of alternative): Full email headers to analyze, e.g. 'Authentication-Results: ...'. - `trusted_authserv_ids` (array of string values; optional): Optional authserv-id values explicitly trusted by the caller; without them, Authentication-Results remain unverified recorded claims. ### Result model - `header_summary` (object) - `received_chain` (array of objects) - `authentication_results` (array of objects) - `spf_dkim_dmarc_findings` (array of objects) - `timeline` (array of objects) - `security_findings` (array of objects) - `raw_parsed_fields` (array of objects) - `warnings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Start with the summary, then read Authentication-Results and the Received chain side by side. Each relay prepends its entry, so the raw newest-first order and the chronological view are shown separately. Configure only authserv-id values you actually trust; without an explicit trust anchor, even the closest candidate is labelled unverified and lower claims are treated as potentially sender-injected.', 'Use the timeline hints to see where latency actually accrued — queueing at one relay looks very different from slow DNS at another. For authentication questions, compare what Authentication-Results states with the DKIM and ARC fields actually present: a missing signature, a broken chain, or a result recorded for a different domain than expected is usually the whole answer. When headers come from a forwarded or list-processed mail, rewrites are normal — read the findings with that context in mind.'] ### Privacy and data handling The pasted header block is parsed locally in the browser. It is not uploaded by this tool. ### Limits and non-claims The pasted header block is parsed entirely in the browser and is not sent to any server by this tool — worth knowing, because headers often carry personal data, internal hostnames, relay IPs, and message IDs. The parser extracts and organizes; it does not fetch DKIM keys, does not verify signatures cryptographically, and is not a forensic mail gateway. Its statements are readings of recorded evidence, not fresh validation. ### Safe example Paste full RFC 5322 headers to inspect raw and chronological hops, recorded SPF/DKIM/DMARC outcomes, trust classification, and parser findings. ### Frequently asked questions - **Why is the Received chain sometimes confusing?** Each relay prepends its own header, and some systems rewrite or omit details for privacy or architecture reasons. The chain is a set of claims of varying trustworthiness — which is why the parser pairs it with timestamps and findings instead of taking it at face value. - **What exactly does Authentication-Results tell me?** What a named authserv-id recorded for SPF, DKIM, DMARC, or ARC at delivery time. The value becomes receiver evidence only when that authserv-id and its header position belong to a trust boundary you control; otherwise it remains an unverified claim. The tool performs neither fresh DNS authentication nor cryptographic verification. - **Does the tool verify DKIM signatures cryptographically?** No. It parses DKIM and ARC fields and reports on their shape and consistency, but it does not fetch public keys or recompute signatures. Cryptographic verification is what the receiving system's own validation is for. - **Is it safe to paste sensitive headers?** The tool does not upload them — parsing stays in this browser session. The judgment call is about your screen and your machine, not about a server: treat headers as the private routing data they are. - **Which header fields are trustworthy?** Only fields anchored in systems and header boundaries you control. Configure the trusted authserv-id explicitly; topmost-looking Authentication-Results are otherwise only candidates, not automatically trusted. From, Subject, Date, Message-ID, lower Received fields, and unanchored authentication claims can be forged. - **What are ARC headers for?** ARC preserves authentication results across forwarding steps that would otherwise break SPF or DKIM — mailing lists are the classic case. The analyzer shows the chain, so you can see whether an intermediary vouched for results it observed earlier. ## 08. ARC Chain Validator - Canonical English page: https://admintoolkit.io/arc-chain-validator/ - Canonical tool ID: `arc-chain-validator` - WebMCP tool name: `admintoolkit_validate_arc_chain` - Category: Email Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only ARC structural validation report. Accepts pasted ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results fields. Includes structural completeness, instance continuity and recorded cv state; cryptographic validation and sealer trust are not evaluated. ['Mail forwarding breaks the two pillars of sender authentication in different ways. SPF fails because the forwarder sends from its own servers, which the original domain never authorized. DKIM often survives — until a mailing list adds a subject tag or a footer, at which point the signature dies too. The receiving system then sees a DMARC failure on a message that was, at its origin, perfectly authentic.', 'ARC exists to carry the evidence across those hops. Each intermediary adds a numbered set of three headers: ARC-Authentication-Results records what the hop observed, ARC-Message-Signature signs the message as it looked at that hop, and ARC-Seal seals the chain so later hops can tell whether it was extended honestly. This validator parses pasted headers into those sets and checks what can be checked structurally: instance numbering, required tags, chain-validation values, and continuity from one hop to the next.'] ### Processing and invocation - Input mode: `paste` - Processing: fully local; no network path. - Network boundary: none; all diagnostic logic runs entirely in the browser. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `headers` (string; one-of alternative): Message headers containing ARC fields, e.g. 'ARC-Seal: i=1; ...'. ### Result model - `arc_instances` (array of objects) - `arc_seal_tags` (array of objects) - `arc_message_signature_tags` (array of objects) - `arc_authentication_results` (array of objects) - `chain_continuity` (object) - `findings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Paste the complete header block of the delivered message, not a fragment. Read the instance sequence first: sets must count 1, 2, 3 without gaps, each instance needs all three members, and the first seal must carry cv=none. Every later seal records cv=pass or cv=fail. A recorded cv=fail is valid syntax and reports that the sealer judged the prior chain failed; it does not by itself make the ARC tag list malformed.', 'Then look at who signed. The d= domains in the chain tell you which infrastructure actually handled the message, which is often more interesting than the validation state itself. A chain is only as useful as the trustworthiness of its sealers: cv=pass from a domain you have never heard of is a claim, not a credential. Cross-reading with the Received chain in the Email Header Analyzer shows whether the ARC story and the transport story agree.'] ### Privacy and data handling Pasted headers are parsed locally in the browser. This tool does not upload message headers. ### Limits and non-claims ["Headers stay in the browser; nothing is uploaded. The validator checks structure, required tags, ordering, and continuity — the failure modes that account for most real-world ARC breakage. It does not fetch DNS keys or verify the signatures cryptographically, because honest verification requires resolver access and exact canonicalization of the message body, which a pasted header block cannot provide. For a final verdict, check what your receiving MTA's authentication results say about the same chain."] ### Safe example Paste headers to distinguish structural completeness and recorded cv=pass/cv=fail from cryptographic validation, which is not performed. ### Frequently asked questions - **Does a structurally valid chain mean the mail is trustworthy?** No. It means the parsed fields satisfy the structural rules. The tool does not verify signatures or sealer identity, and a structurally valid chain may legitimately record cv=fail. Trust requires separate cryptographic validation and receiver policy. - **Can ARC make a failing DMARC message deliverable?** Sometimes. Large receivers may override a DMARC failure when a sealer they trust attests that authentication passed upstream. That is a per-receiver policy decision, not a protocol guarantee, and small receivers often ignore ARC entirely. - **What does cv=fail in the middle of a chain tell me?** That the seal at that instance could not validate the chain before it. Everything after that point inherits the failure; ARC has no repair mechanism. The hop to investigate is the one just before the first fail. - **Why do mailing lists show up so often in ARC chains?** Because they are the classic case that breaks both SPF and DKIM at once: they resend from their own infrastructure and modify the message. Lists were a major motivation for ARC, so chains sealed by list providers are extremely common. - **The instance numbers jump from 1 to 3. What happened?** An intermediary either stripped a set or numbered its own set wrongly. Both invalidate the chain as evidence, because continuity is exactly what the numbering is supposed to guarantee. - **Do I need to publish anything in DNS to receive ARC mail?** No. ARC sealing is done by intermediaries with their own keys. You only need DNS records for ARC if your infrastructure seals messages itself — receiving and evaluating chains requires nothing. ## 09. BIMI Checker/Generator - Canonical English page: https://admintoolkit.io/bimi-checker-generator/ - Canonical tool ID: `bimi-checker-generator` - WebMCP tool name: `admintoolkit_check_bimi_record` - Category: Email Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only BIMI readiness report for a mail domain. Accepts a domain, selector and optional BIMI, DMARC, logo or certificate evidence. Includes TXT syntax, DMARC dependency, asset URL findings and a conservative BIMI draft. ["BIMI is the visible payoff for invisible work: a brand logo next to your mail, granted by receivers only after a domain has proven itself. That proof is the part people underestimate — the logo display generally depends on an enforced DMARC policy, and often on a Verified Mark Certificate as evidence for the logo's legitimacy. The BIMI TXT record itself is almost trivial; the deployment fails or succeeds on everything it points at and everything it presumes.", "This checker reads a domain's BIMI readiness as a whole: the record under its selector owner name, tag syntax, the logo URL and its reachability, optional VMC or CMC evidence, and — because nothing works without it — the DMARC dependency. It also drafts a conservative DNS value, so the record you publish is derived from checked inputs rather than assembled from a blog post."] ### Processing and invocation - Input mode: `paste_or_dns` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `domain` (string; required): BIMI domain to check, e.g. 'example.com'. - `selector` (string; optional): BIMI selector to query, e.g. 'default'. - `record` (string; optional): Pasted BIMI TXT record, e.g. 'v=BIMI1; l=https://example.com/logo.svg'. - `dmarc` (string; optional): Pasted DMARC TXT record for BIMI policy review, e.g. 'v=DMARC1; p=reject'. - `logo_url` (string; format uri; optional): BIMI SVG logo URL to inspect, e.g. 'https://example.com/logo.svg'. - `evidence_url` (string; format uri; optional): BIMI VMC or evidence URL to inspect, e.g. 'https://example.com/vmc.pem'. ### Result model - `bimi_owner_name` (string) - `record_tags` (array of objects) - `logo_url` (string) - `evidence_url` (string) - `dmarc_readiness` (object) - `generator_draft` (object) - `findings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Start with domain and selector — default._bimi is the usual owner name — and fetch the current BIMI and DMARC records, or paste both when working from zone data. Read the DMARC readiness verdict first: with p=none, most receivers will not display a logo regardless of how perfect the rest is, so tightening DMARC is usually the actual project and BIMI is its final step.', 'Then review what the record points at. The logo must be an SVG in the Tiny Portable/Secure profile, served over HTTPS from a stable URL — treat that URL as production infrastructure, because receivers fetch it on their own schedule. Publish the a= evidence tag only when a real certificate exists; an evidence URL that returns errors is worse than no evidence tag at all. When the findings are clean, take the generated DNS value, publish it, and re-run the check against live DNS to close the loop.'] ### Privacy and data handling Pasted records stay local. Live DNS queries only the BIMI and DMARC owner names when requested. A VMC/CMC evidence URL is optional and should be published only when a real certificate exists. ### Limits and non-claims Pasted records stay in the browser. Live DNS queries only the BIMI and DMARC owner names, using DNS-over-HTTPS first with the same-origin DNS helper as fallback, and only when you request them. SVG profile conformance and VMC/CMC evidence are assessed as readiness signals, not cryptographically verified — final logo display remains each receiver's decision, applying its own policy on top of everything this page can see. ### Safe example default._bimi.example.com -> v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem. ### Frequently asked questions - **Which owner name does BIMI use?** selector._bimi.domain — with default as the customary selector, so default._bimi.example.com in most deployments. Multiple selectors are possible when different mail streams should present different marks. - **Why does DMARC matter so much for BIMI?** Because the logo is a trust statement, and receivers only extend it to domains that enforce authentication. An enforced DMARC policy — quarantine or reject — is the practical entry ticket; p=none rarely results in logo display. - **What are VMC and CMC evidence for?** The optional a= tag can point to a Verified Mark Certificate or Common Mark Certificate that attests your right to the logo. Some large receivers require it for display; without it, BIMI remains self-asserted and treated more cautiously. - **Why must the logo be SVG Tiny Portable/Secure?** Because receivers render it in security-sensitive mail contexts and demand a strict profile: no scripts, no external references, no animations. An ordinary SVG export usually fails the profile even though it looks identical. - **Is my logo uploaded by this check?** No. The record and URLs are analyzed, and the browser loads a preview only when the URL is public and reachable. Nothing is stored or submitted anywhere by the page. - **My record is valid — why does no logo appear?** Because display is the receiver's decision, not the record's. Common causes: DMARC not enforced, missing VMC where required, an unreachable or non-conformant SVG, or a sender reputation that has not earned display yet. The record is necessary, never sufficient. ## 10. MTA-STS Checker/Generator - Canonical English page: https://admintoolkit.io/mta-sts-checker-generator/ - Canonical tool ID: `mta-sts-checker-generator` - WebMCP tool name: `admintoolkit_check_mta_sts_policy` - Category: Email Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only MTA-STS deployment report for a mail domain. Accepts a domain plus optional TXT, policy, MX and TLS-RPT evidence. Includes mode, max-age, syntax, id consistency, MX coverage, conformance findings and remediation warnings. ['MTA-STS closes a real gap: SMTP falls back to plaintext or unauthenticated TLS by default, and a network attacker can exploit exactly that downgrade. The mechanism is simple to describe and easy to misdeploy, because it lives in three places that must agree — a _mta-sts TXT record whose id announces policy changes, an HTTPS policy file at a fixed well-known URL on the mta-sts subdomain, and mx entries in that policy which must cover the hosts your MX records actually point at. Any one of the three drifting turns a security control into a delivery risk.', 'This checker reads all three surfaces for a domain and reports them as one deployment: TXT syntax and id, policy mode and max-age, MX coverage against your real MX set, and optional TLS-RPT context. It also produces a conservative starter draft for a staged rollout, so the first published policy is one that observes rather than enforces.'] ### Processing and invocation - Input mode: `domain_or_paste` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `domain` (string; required): Mail domain for MTA-STS checks, e.g. 'example.com'. - `dns_txt` (string; optional): Pasted _mta-sts TXT value, e.g. 'v=STSv1; id=20260713'. - `policy` (string; optional): Pasted MTA-STS policy text, e.g. 'version: STSv1'. - `mode` (string; allowed: `testing`, `enforce`, `none`; optional): Generated MTA-STS policy mode: 'testing', 'enforce', or 'none', e.g. 'testing'. - `mx_hosts` (string; optional): Known MX hostnames, one per line, e.g. 'mail.example.com'. - `tls_rpt` (string; optional): Pasted TLS-RPT TXT value, e.g. 'v=TLSRPTv1; rua=mailto:tls@example.com'. ### Result model - `dns_txt_id` (string) - `policy_mode` (string) - `policy_max_age` (integer) - `mx_coverage` (object) - `tls_reporting_context` (object) - `generator_draft` (object) - `findings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Work from pasted values while designing: TXT record, policy text, and known MX hosts can all be checked locally before anything is published. The coverage comparison is the part to take seriously — enforce mode with an MX host missing from the policy is the classic self-inflicted outage, and it is precisely the mistake a pre-publication diff catches.', 'Roll out in the proven order: publish in testing mode with TLS-RPT reporting, watch the reports long enough to trust that legitimate senders reach covered hosts over verifiable TLS, then switch to enforce and raise max-age gradually. Every policy change needs a new TXT id — senders cache the policy for max-age, and the id is the only signal telling them to refresh. Re-run the check after each step; the live mode shows what senders currently resolve and fetch.'] ### Privacy and data handling Pasted records stay local. Live checks use browser DNS-over-HTTPS first and the same-origin DNS/policy fallback only when requested. ### Limits and non-claims Pasted records and policy text stay local. Live checks resolve DNS through Cloudflare DNS-over-HTTPS from the browser first, with the same-origin DNS fallback if that path fails, and fetch the policy only from the fixed mta-sts./.well-known/mta-sts.txt URL through the same-origin helper. No SMTP session is opened and no delivery test is performed — the tool verifies the published policy surfaces, not your mail server's TLS handshake, which is the SMTP TLS readiness checker's job. ### Safe example example.com -> _mta-sts TXT id, https://mta-sts.example.com/.well-known/mta-sts.txt, MX coverage, and starter policy. ### Frequently asked questions - **What does the TXT id actually do?** It is a cache-busting version marker. Senders cache the HTTPS policy for max-age seconds and only refetch early when the id changes — so a policy edit without a new id can go unnoticed until caches expire. - **Which mode should the first published policy use?** Testing. It asks senders to evaluate the policy and report failures without changing delivery behavior, which turns misconfigurations into report lines instead of bounced mail. - **Why is MX coverage the critical check?** Because the policy's mx entries define which receiving hosts are legitimate. If your real MX hosts are not covered, an enforcing sender treats delivery to them as a policy failure — and in enforce mode that mail stops. - **How should max-age be chosen?** Short at first — long enough to be honored, short enough that a broken policy ages out quickly. Once enforce has been stable, raising max-age hardens the domain against downgrade windows between fetches. - **Is TLS-RPT required for MTA-STS?** No, but running MTA-STS without it means enforcing policy blind. TLS-RPT delivers aggregate failure reports — the only routine feedback channel that shows senders failing your policy before users notice missing mail. - **How does MTA-STS relate to DANE?** Both defeat SMTP downgrade attacks. DANE anchors trust in DNSSEC-signed TLSA records; MTA-STS anchors it in HTTPS and the web PKI. They can coexist — senders that support DANE typically prefer it, and MTA-STS covers the large sender population that does not. ## 11. TLS-RPT Checker/Generator - Canonical English page: https://admintoolkit.io/tls-rpt-checker-generator/ - Canonical tool ID: `tls-rpt-checker-generator` - WebMCP tool name: `admintoolkit_check_tls_rpt_policy` - Category: Email Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only SMTP TLS Reporting report for a mail domain. Accepts a domain plus optional TLS-RPT TXT or RUA values. Includes version syntax, reporting destinations, external-provider use, conformance findings and remediation warnings. ['TLS-RPT is the reporting half of modern SMTP transport security: MTA-STS and DANE state what senders must require, and TLS-RPT is how those senders tell you when the requirement fails. Without it, an enforcing policy fails silently — mail from affected senders simply stops, and the first report you get is a human asking where their message went. One small _smtp._tls TXT record turns that silence into aggregate reports naming the failure classes and the affected sending infrastructure.', 'This checker validates the record end to end: version syntax, the rua destination list, mailto versus HTTPS endpoint shape, and the informational question of whether reporting flows to an external provider. It also drafts a conservative starter record when none exists, so the reporting channel can be live before the first policy tightening makes it indispensable.'] ### Processing and invocation - Input mode: `domain_or_paste` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `domain` (string; required): Mail domain for TLS-RPT checks, e.g. 'example.com'. - `dns_txt` (string; optional): Pasted _smtp._tls TXT value, e.g. 'v=TLSRPTv1; rua=mailto:tls@example.com'. - `rua` (string; optional): Generated TLS-RPT rua destination, e.g. 'mailto:tls@example.com'. ### Result model - `dns_txt_status` (string) - `rua_destinations` (array of strings) - `external_reporting_notes` (array of strings) - `generator_draft` (object) - `findings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ["Paste a proposed TXT value while designing, or query live DNS to see what the world resolves right now. Then treat the destinations as the real subject of the review: a syntactically valid rua pointing at an unmonitored mailbox is functionally no reporting at all. Verify that the mailbox exists, survives the domain's own mail filtering, and is actually read — or that the HTTPS endpoint accepts report submissions.", 'Publish exactly one _smtp._tls record and list multiple destinations comma-separated inside it, rather than publishing multiple records. Once reports arrive, read them for trends rather than singletons: one sender failing once is network weather, one failure class persisting across senders is a configuration problem on your side — an expired certificate, a policy that no longer matches your MX set, a host still negotiating legacy TLS. Re-check the record after every mail-infrastructure change; reporting is cheap insurance only while the destination keeps working.'] ### Privacy and data handling Pasted records stay local. Live DNS checks use browser DNS-over-HTTPS first and the same-origin DNS fallback only when requested. ### Limits and non-claims Pasted records stay local; live DNS lookups use Cloudflare DNS-over-HTTPS from the browser first, with the same-origin DNS fallback if that path fails, and send only the queried names. The tool validates syntax and destination shape — it does not send test reports, cannot confirm that a provider accepts submissions, and does not judge the quality of a provider's parsing. Whether reports ultimately arrive depends on sender behavior and the destination's operation, both outside this page's view. ### Safe example example.com -> _smtp._tls TXT with v=TLSRPTv1 and mailto or HTTPS rua destinations. ### Frequently asked questions - **What is TLS-RPT actually used for?** It lets sending mail systems report SMTP TLS policy failures — most usefully alongside MTA-STS or DANE deployments, where it is the routine feedback channel showing that a policy blocks legitimate senders before users notice missing mail. - **Can I point rua at an external reporting provider?** Yes, and it is common — parsing aggregate reports is genuine work. The tool marks external destinations as informational findings: a trust decision to make consciously, since the provider sees your failure telemetry. - **Should I publish several TLS-RPT TXT records?** No. Publish one _smtp._tls record and put multiple destinations in a comma-separated rua list inside it. Multiple records create ambiguity that some senders resolve by ignoring them. - **Does a valid record prove reports will arrive?** No. The record is the invitation; delivery depends on senders that implement TLS-RPT and on the destination accepting mail or submissions. Large operators send reliably, so a working destination usually sees traffic within a day or two. - **Do I need TLS-RPT without MTA-STS or DANE?** It still works — senders can report opportunistic TLS failures too — but its main value is as the observability layer for an enforced policy. Deploying it first is the sensible order: reporting before enforcement. - **What should alarm me in a report?** Persistent failure classes: certificate-validation failures after a renewal, STARTTLS suddenly unavailable on an MX host, or policy-fetch errors senders keep repeating. Those patterns describe your infrastructure, not the sender's — they are the reason this channel exists. ## 12. SMTP TLS Handshake / Mail Domain Delivery Readiness - Canonical English page: https://admintoolkit.io/smtp-tls-readiness-checker/ - Canonical tool ID: `smtp-tls-readiness-checker` - WebMCP tool name: `admintoolkit_check_smtp_tls_readiness` - Category: Email Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only SMTP TLS delivery readiness report for a mail domain. Accepts a domain and optional MTA-STS, TLS-RPT, DANE and FCrDNS checks. Includes MX, STARTTLS, certificate, policy-alignment and downgrade-risk findings. ['When another operator asks whether your domain is ready to receive mail securely, the honest answer spans half a dozen mechanisms: MX routing, STARTTLS on the exchangers, certificates that match the right names, and — where deployed — MTA-STS, TLS-RPT, DANE, and forward-confirmed reverse DNS. Each has its own tool; delivery problems, however, arise from their combination. A valid MTA-STS policy pointing at an exchanger whose certificate does not match is two green checks and one broken deployment.', "This checker runs the combination as one readiness report: it resolves effective MX targets, including RFC 5321 implicit MX when no MX RRset exists, and attempts a separate STARTTLS session to every resolved public A and AAAA address for each selected exchanger. It preserves per-address certificate evidence and — when enabled — layers strict MTA-STS WebPKI/SAN validation, TLS-RPT record validity, DANE/TLSA comparison from each address session, and canonical-IP FCrDNS round trips on top. The trust modes remain separate: a green layer never erases another layer's failure."] ### Processing and invocation - Input mode: `domain` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `domain` (string; required): Mail domain for SMTP TLS readiness checks, e.g. 'example.com'. - `check_mta_sts` (boolean; optional): Include MTA-STS checks; pass true or false, e.g. true. - `check_tls_rpt` (boolean; optional): Include TLS-RPT checks; pass true or false, e.g. true. - `check_dane` (boolean; optional): Include DANE/TLSA checks; pass true or false, e.g. true. - `check_fcrdns` (boolean; optional): Include forward-confirmed reverse DNS checks; pass true or false, e.g. true. ### Result model - `mx_records` (array of objects) - `starttls_hosts` (array of objects) - `certificate_match` (object) - `mta_sts_alignment` (object) - `tls_rpt_status` (object) - `dane_evidence` (object) - `delivery_readiness_findings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Run the base check first: MX plus STARTTLS gives bounded diagnostic transport evidence. Enable MTA-STS when the question requires WebPKI chain and SAN identity proof, and enable only the other layers that are actually in scope. An absent unselected policy is not a failure: a domain without DANE is not broken, it merely has not deployed DANE, and the report keeps that distinction visible.', 'Read findings as a sender would experience them. A certificate mismatch on the first MX host blocks MTA-STS and other WebPKI identity checks, while DANE treatment depends on certificate usage; a missing TLSA record affects only DANE-validating senders, and a reverse-DNS mismatch mostly costs reputation points at large providers. That ordering is your priority list. After any change — new certificates, new MX hosts, a policy edit — re-run the full set, because these layers reference each other by name and drift between them is the standard failure mode.'] ### Privacy and data handling Live checks use guarded DNS, HTTPS policy, and SMTP probing helpers only when requested. Every resolved public IPv4 and IPv6 address of each selected MX host is attempted; unchecked addresses remain incomplete and are not converted into protocol failures. ### Limits and non-claims Live checks run only on request through guarded helpers: DNS lookups, the fixed no-redirect MTA-STS policy URL, and SMTP probes to public MX hosts on port 25 with short timeouts, limited to the first three exchangers to keep the check bounded. Within those selected exchangers, every resolved public IPv4 and IPv6 address is attempted. An unattempted address keeps coverage incomplete without inventing a STARTTLS, certificate, MTA-STS, DANE, or FCrDNS failure; an attempted address with a real protocol failure is reported as that failure. TLS-RPT validates one usable record and its destination syntax but cannot prove report delivery. The probe observes one network path at one moment and never proves end-to-end mail delivery. ### Safe example example.com -> MX hosts, STARTTLS banner and certificate match, MTA-STS policy alignment, TLS-RPT, optional DANE hints, and FCrDNS confirmation. ### Frequently asked questions - **Why are the policy checks optional?** Because not every domain publishes MTA-STS, TLS-RPT, DANE, or clean FCrDNS, and their absence is a deployment status, not a defect. Making them explicit keeps a pure STARTTLS check from looking broken when a domain simply has not adopted a layer. - **Does a passing STARTTLS probe prove my mail delivers securely?** No. It proves the probed host advertised and negotiated TLS on this path at this moment. Real senders may take different routes, retry differently, or enforce policies this probe did not exercise — the result is strong evidence, not a delivery guarantee. - **Why must the certificate match the MX host?** MTA-STS requires a trusted WebPKI chain and a matching SAN DNS identity for the selected MX host. DANE identity requirements depend on certificate usage; a valid DANE-EE usage 3 association does not require PKIX or certificate-name validation. - **What does FCrDNS add to mail readiness?** It confirms that the PTR names of your MX addresses resolve forward to the same addresses. Nothing in TLS depends on it, but large receivers use it as a reputation signal, and a mismatch is a cheap thing to fix before it costs deliverability. - **How many MX hosts does the probe test?** The live helper deliberately limits probing to the first few exchangers by preference, with short timeouts. That keeps the check bounded and polite while still covering the hosts real senders would try first. - **The report is green but mail still fails — where next?** Then transport is probably not your problem. Move to the authentication layer — SPF, DKIM, DMARC and their alignment — and to real evidence: message headers from a failed delivery and your TLS-RPT reports, which name failure classes this snapshot cannot see. ## 13. DNSSEC Validator - Canonical English page: https://admintoolkit.io/dnssec-validator/ - Canonical tool ID: `dnssec-validator` - WebMCP tool name: `admintoolkit_validate_dnssec_records` - Category: DNS Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only DNSSEC evidence report for a domain. Accepts a domain plus optional DS, DNSKEY, RRSIG and resolver-status data. Includes chain readiness, algorithms, missing records, validation findings and warnings. ['DNSSEC failures have a signature symptom: the domain works for some users and is dead for others. Validating resolvers answer SERVFAIL for a broken chain while non-validating resolvers happily serve the records, so the outage follows resolver choice rather than geography or network. Whoever is on Quad9 sees an outage; whoever is on a legacy ISP resolver sees nothing wrong. These partial outages are confusing precisely because the zone data itself is fine.', "Behind every such incident is a chain with one broken link. The parent zone publishes a DS record — a digest of the child's key-signing key. The child publishes its DNSKEY set and signs its record sets with RRSIGs. Validation walks from the trust anchor through each delegation, and every link must hold: DS must match a live DNSKEY, signatures must be current, algorithms must line up. This tool fetches that evidence for a domain — DS, DNSKEY, RRSIG, and the resolver's own verdict — and shows where the story stops adding up."] ### Processing and invocation - Input mode: `form` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `domain` (string; required): DNSSEC domain to validate, e.g. 'example.com'. - `ds_records` (string; optional): DS records for the domain, one per line, e.g. '12345 13 2 '. - `dnskey_records` (string; optional): DNSKEY records for the zone, one per line, e.g. '257 3 13 '. - `rrsig_records` (string; optional): RRSIG records for validation context, one per line, e.g. 'example.com. RRSIG ...'. - `status` (string; allowed: ``, `secure`, `bogus`; optional): Resolver validation status: '', 'secure', or 'bogus', e.g. 'secure'. ### Result model - `ds_records` (array of objects) - `dnskey_records` (array of objects) - `rrsig_records` (array of objects) - `resolver_status` (string) - `chain_status` (object) - `findings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Start from the resolver status, because it defines the class of problem. Secure means the chain validates end to end. Insecure means no DS exists at the parent — the zone is simply unsigned, which is a policy state rather than an error. Bogus is the acute case: signed, but broken, and validating resolvers will refuse to answer. Only bogus takes the domain down, and that distinction decides whether you are firefighting or planning.', "For a bogus result, check the two classic culprits in order. First signature freshness: RRSIGs carry explicit expiry timestamps, and an expired signature almost always means the re-signing automation died some days ago — the outage begins when the last signature lapses, not when the tooling broke. Second, the DS-to-DNSKEY match: after a key rollover, a DS at the parent still digesting the retired key breaks everything, which is why the old key must remain published until the parent's update has propagated past its TTL."] ### Privacy and data handling Pasted evidence stays local. Live DNS runs only when requested, using browser DNS-over-HTTPS first and the same-origin DNS fallback if needed. ### Limits and non-claims ["Pasted records stay local, and live queries run only on request, using browser DNS-over-HTTPS with a same-origin fallback. The page presents the named resolver's validation verdict and structural chain inventory; it does not itself recompute every signature, and it displays NSEC and NSEC3 material as context without re-deriving full denial-of-existence proofs. Bare SERVFAIL, timeout, or generic failure is unavailable evidence, not proof of bogus; explicit resolver verdict or DNSSEC-specific EDE evidence is required for that classification. For an authoritative offline verdict, a local validating resolver remains the reference."] ### Safe example example.com -> DS at parent, DNSKEY at child, RRSIG evidence, and secure/bogus resolver status. ### Frequently asked questions - **Users on some networks reach the domain, others get errors. DNSSEC?** That pattern can be consistent with DNSSEC validation failure, but it is not proof. Bare SERVFAIL remains unavailable because many other failures produce it. Require an explicit bogus resolver verdict or DNSSEC-specific EDE evidence before classifying the chain as bogus. - **What is the difference between insecure and bogus?** Insecure means the parent has no DS record: the zone is unsigned and resolvers do not expect signatures. Bogus means the zone claims to be signed but validation fails. Insecure is a choice; bogus is an outage. - **How do RRSIG expiry times cause outages?** Signatures are only valid within their inception and expiration window. Zones re-sign automatically, and when that automation fails, nothing visible happens until the first signature expires — then validating resolvers drop the zone. Monitoring RRSIG expiry is monitoring your signing pipeline. - **Why did my domain break after a key change?** Most likely the DS at the parent still matches the old key, or the old DNSKEY was withdrawn before the parent update propagated. Rollovers must keep both keys live through the overlap window; skipping that step turns a routine rotation into a bogus zone. - **Do KSK and ZSK matter for reading the output?** Yes. The DS at the parent corresponds to the key-signing key, which in turn signs the zone-signing key that signs ordinary records. When the DS matches no visible DNSKEY, compare it against the KSK specifically — that is the link the parent anchors. - **Is a shown algorithm number a security assessment?** No, it is inventory. It helps spot deprecated algorithms and mismatches between DS and DNSKEY, but the display does not prove the cryptography was independently verified by this page. ## 14. TLSA Record Checker/Generator - Canonical English page: https://admintoolkit.io/tlsa-record-checker-generator/ - Canonical tool ID: `tlsa-record-checker-generator` - WebMCP tool name: `admintoolkit_generate_tlsa_record` - Category: DNS Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only DANE TLSA record report. Accepts host, port, protocol, usage, selector, matching type and optional certificate data. Includes owner name, digest, generated TLSA data and DNS comparison findings. ['A TLSA record is three small decisions and one digest, and each decision changes how the record behaves operationally. Certificate usage decides what you pin — the end-entity credential itself (DANE-EE) or a trust anchor above it (DANE-TA). The selector decides what gets hashed: the whole certificate, which changes on every renewal, or only the SubjectPublicKeyInfo, which stays stable for as long as you keep the key pair. The matching type picks the digest algorithm. The popular 3 1 1 profile is popular for a reason: it survives routine certificate renewals untouched, provided the key does not change.', 'This tool does the assembly work precisely: it derives the association data from a pasted or uploaded certificate — or from the live certificate a public host currently presents — builds the correctly formed owner name from port, protocol, and host, and can immediately compare the generated value against what DNS actually answers. That generate-then-diff loop is the fastest way to see whether the record you are about to publish, or the one already published, matches cryptographic reality.'] ### Processing and invocation - Input mode: `form` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `host` (string; required): TLS service host for TLSA generation, e.g. 'mail.example.com'. - `port` (string; optional): TLS service port number, e.g. '25' or '443'. - `protocol` (string; allowed: `tcp`, `udp`; optional): TLSA transport protocol: 'tcp' or 'udp', e.g. 'tcp'. - `usage` (string; allowed: `0`, `1`, `2`, `3`; optional): TLSA certificate usage: 0=PKIX-TA, 1=PKIX-EE, 2=DANE-TA, 3=DANE-EE. - `selector` (string; allowed: `0`, `1`; optional): TLSA selector: 0=full certificate or 1=SPKI, e.g. '1'. - `matching` (string; allowed: `0`, `1`, `2`; optional): TLSA matching type: 0=full, 1=SHA-256, 2=SHA-512. - `pem` (string; optional): Certificate PEM, DER base64, or hex input, e.g. '-----BEGIN CERTIFICATE-----'. - `file` (string; optional): Certificate file content to parse, e.g. PEM text from a .crt file. ### Result model - `owner_name` (string) - `tlsa_record` (string) - `digest` (string) - `warnings` (array of objects) - `dns_lookup_result` (object) - `live_certificate_generated_record` (object) - `tlsa_dns_comparison` (object) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Decide the parameter profile before touching digests, because it encodes your operational model. If certificates renew automatically but the key pair persists, 3 1 1 makes renewals invisible to DANE. If your automation rotates keys on every renewal, either fix that or accept that every renewal becomes a coordinated DNS change with TTL discipline. Full-certificate hashing (selector 0) ties the record to one exact certificate and is best reserved for setups where that is genuinely intended.', "Then generate and compare. For a planned deployment, produce the record and check it against DNS to confirm nothing stale answers under the owner name. For a live service, let the endpoint fetch the presented certificate and diff both sides in one pass. For rollovers, publish the next key's TLSA association alongside the current one at least two relevant TLSA TTLs before the credential change, allow publication and cache propagation, switch and verify every endpoint, then retire the old record only after the old credential is nowhere in use. Whether the whole deployment satisfies DANE end to end, including DNSSEC, is the DANE validator's question."] ### Privacy and data handling Local generation stays in the browser. Browser DNS and same-origin live TLSA checks run only when requested. ### Limits and non-claims ['Certificate parsing and digest generation run locally in the browser; pasted or uploaded certificate material is not sent anywhere by the generation step. DNS comparison uses DNS-over-HTTPS first with the same-origin helper as fallback, and the live-certificate endpoint accepts public hostnames on permitted ports only, supporting direct TLS and SMTP STARTTLS. The tool builds and compares association data; it does not validate DNSSEC chains, judge policy coherence, or assess sender behavior — evaluation is deliberately left to the DANE validator.'] ### Safe example _25._tcp.mail.example.com with usage 3, selector 1, matching 1 generates a DANE-EE SPKI SHA-256 record. ### Frequently asked questions - **Which certificate do I paste — leaf, intermediate, or root?** For usage 3 profiles, the leaf: DANE-EE pins the end-entity credential. Intermediates and roots only become the hashed subject when you deliberately build a DANE-TA (usage 2) record that pins a trust anchor. - **Why did my TLSA record stay valid after a certificate renewal?** Because with selector 1 the digest covers only the public key, and your renewal kept the key pair. That is the designed behavior of 3 1 1, not an oversight — the record follows the key, not the paper around it. - **What is the \# wire-format notation the DNS comparison sometimes shows?** RFC 3597 generic encoding, used by some DNS APIs for record types they do not model natively. The tool decodes the raw bytes back into usage, selector, matching type, and association data before comparing, so the notation itself is harmless. - **Can several TLSA records coexist at one owner name?** Yes. Within one exact usage, selector, and matching-type group, any current association may match; that permits old and new data to overlap during a rollover. Different parameter groups have client-selection semantics and must remain consistent — one digest algorithm's match does not prove success for every client. - **Which TTL should TLSA records use?** Short enough that a planned change propagates within your maintenance window, long enough to be cache-friendly — commonly some minutes to an hour. What matters more than the exact number: every rollover step must respect the previous TTL before the next dependent change. - **Do submission ports 465 and 587 need their own records?** If you offer DANE for those services, yes — each port and protocol combination has its own owner name and record. The ecosystem's enforcement pressure is on MX-to-MX port 25, but per-service records follow the same construction shown here. ## 15. DANE Validator - Canonical English page: https://admintoolkit.io/dane-validator/ - Canonical tool ID: `dane-validator` - WebMCP tool name: `admintoolkit_validate_dane_records` - Category: DNS Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only DANE service validation report. Accepts service host, port, protocol, TLSA records, DNSSEC status and optional certificate evidence. Includes owner names, TLSA syntax, DNSSEC dependency and certificate-match findings. ['DANE answers a question classic PKI cannot: is the certificate this server just presented the one its operator intended, as stated in DNS under DNSSEC protection? For SMTP transport this matters structurally, because port-25 TLS is opportunistic by default — a downgrade attacker between two MTAs can simply strip STARTTLS unless the sending side has an independent reason to insist on TLS with a specific key. A DNSSEC-signed TLSA record is that reason, and sending MTAs configured for DANE enforce it hard.', 'Enforcement cuts both ways: a wrong TLSA record does not degrade gracefully, it makes DANE-validating senders refuse delivery. This validator therefore judges a deployment the way a validating sender would, as a whole: the service owner name must be formed from the actual MX host, the TLSA parameter combination must be coherent, the DNSSEC context must authenticate the answer, and — on request — the live certificate must actually match the published association data. Any single miss breaks the entire promise.'] ### Processing and invocation - Input mode: `form` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `host` (string; required): DANE service host to validate, e.g. 'mail.example.com'. - `port` (string; optional): DANE service port number, e.g. '25' or '443'. - `protocol` (string; allowed: `tcp`, `udp`; optional): DANE transport protocol: 'tcp' or 'udp', e.g. 'tcp'. - `mode` (string; allowed: `smtp`, `tls`; optional): DANE validation mode: 'smtp' or 'tls', e.g. 'smtp'. - `tlsa_records` (string; optional): TLSA records to validate, one per line, e.g. '3 1 1 '. - `dnssec` (string; allowed: ``, `secure`, `bogus`; optional): DNSSEC validation status: '', 'secure', or 'bogus', e.g. 'secure'. ### Result model - `service_owner_name` (string) - `tlsa_records` (array of objects) - `usage_selector_matching` (array of objects) - `dnssec_context` (object) - `certificate_comparison` (object or null) - `findings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Evaluate in the order a sender validates. First the owner name: for mail, TLSA lives at _25._tcp under the MX hostname — the host receiving connections, not the recipient domain. Then the parameter sanity: certificate-usage, selector, and matching type must form an operationally sensible combination, with DANE-EE over SPKI with SHA-256 (3 1 1) as the widely deployed default. Then the DNSSEC verdict, because an unsigned TLSA answer is decorative: without authentication, an attacker who can spoof DNS can substitute records, which is exactly the attack DANE exists to close.', 'Finish with the live comparison against the presented certificate, and read a mismatch operationally: the classic incident is a certificate renewal that changed the public key while the TLSA record kept the old digest — from the outside indistinguishable from an attack, and validating senders treat it as one. For a rollover, publish the next association alongside the current one at least two relevant TLSA TTLs before the credential change, allow publication and cache propagation, switch and verify every endpoint, then retire the old record only after the old credential is nowhere in use.'] ### Privacy and data handling Pasted TLSA records stay local. Live comparison uses the existing guarded TLSA endpoint only when requested. ### Limits and non-claims ["Pasted TLSA records stay in the browser; live checks use the guarded same-origin endpoint for public hosts on permitted ports. The validator assesses one service binding at a time. Within each exact usage, selector, and matching-type group, any current association may match, permitting an old/new rollover; a clean cross-client result requires every supported published group to match. Mixed digest groups are not a universal OR. This host-level check does not authenticate the recipient domain's MX RRset or alias-routing chain. DANE-TA usage 2 is reported unsupported because this path does not build the full chain to the selected trust anchor and validate the SMTP reference identity. It does not audit sending-MTA policy, trust-store configuration, or monitoring, and it does not build records."] ### Safe example _25._tcp.mail.example.com -> 3 1 1 plus secure DNSSEC context and live certificate comparison. ### Frequently asked questions - **Which name carries the TLSA record for mail?** The MX hostname, not the recipient domain: _25._tcp.mail.example.com when mail for example.com is received by mail.example.com. Records published under the bare domain are a common and completely ineffective misplacement. - **Why is TLSA without validated DNSSEC worthless?** Because the record's whole role is to be the trustworthy statement of the expected key. Unsigned, it can be spoofed by the same attacker DANE is meant to stop — a sender that cannot authenticate the answer rightly ignores it. - **What breaks most DANE deployments in practice?** Renewals. The certificate or key changes, the TLSA record does not, and DANE-validating senders start refusing mail. Choosing SPKI-based association (selector 1) and keeping the key pair across renewals makes routine renewals a non-event. - **Should I evaluate 2 x x records differently from 3 x x?** Yes. Usage 3 (DANE-EE) pins the end-entity credential itself; self-signed, WebPKI name, and expiry state do not negate a matching DNSSEC-secure association. Usage 2 (DANE-TA) requires the full chain, association to the selected trust anchor, and SMTP reference-identity validation. This validator reports usage 2 unsupported until all of those checks are available. - **Does DANE protect my users' browsers?** Effectively no. Mainstream browsers validate the web PKI, not TLSA. DANE's production habitat is MTA-to-MTA SMTP, where a meaningful share of validating senders enforce it and delivery genuinely depends on the records being right. - **How does DANE relate to MTA-STS?** Same threat, different trust roots: DANE anchors in DNSSEC, MTA-STS in HTTPS and the web PKI, and each covers senders the other cannot. Well-run mail domains publish both; this page judges only the DANE half. ## 16. CAA Record Checker/Generator - Canonical English page: https://admintoolkit.io/caa-record-checker-generator/ - Canonical tool ID: `caa-record-checker-generator` - WebMCP tool name: `admintoolkit_check_caa_records` - Category: DNS Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only CAA certificate-authority policy report for a domain. Accepts a domain plus optional CAA records and issuer details. Includes issue, issuewild, iodef, ACME parameters, policy gaps and record-generation guidance. ['Any publicly trusted certificate authority can, in principle, issue a certificate for your domain — unless you say otherwise. CAA is where you say otherwise: a DNS record the CA must check at issuance time, naming the authorities you authorize. It is the control that turns a mis-issuance from an open possibility into a policy violation with an audit trail, and it is the control that catches the well-meaning colleague ordering a certificate from a vendor your PKI strategy retired two years ago.', "The record's grammar is small but exact. The issue tag authorizes a CA for host certificates, issuewild separately governs wildcards, and iodef names a reporting address for policy violations. RFC 8657 adds sharper pins for ACME: accounturi restricts issuance to one specific ACME account, and validationmethods restricts which challenge types are acceptable. This tool validates existing records — pasted or fetched live — and drafts a conservative policy when none exists yet."] ### Processing and invocation - Input mode: `paste_or_dns` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `domain` (string; required): CAA domain to check, e.g. 'example.com' (no scheme). - `records` (string; optional): CAA records to inspect, one per line, e.g. '0 issue letsencrypt.org'. - `ca` (string; optional): CA domain for generated CAA records, e.g. 'letsencrypt.org'. - `iodef` (string; optional): CAA iodef report destination, e.g. 'mailto:security@example.com'. - `methods` (string; optional): CAA validationmethods value, e.g. 'dns-01'. - `issuemail` (string; optional): CAA issuemail issuer-domain value from RFC 9495, optionally followed by issuer parameters, e.g. 'letsencrypt.org; validationmethods=dns-01'. ### Result model - `caa_records` (array of objects) - `issue_tags` (array of objects) - `issuewild_tags` (array of objects) - `iodef_tags` (array of objects) - `accounturi_tags` (array of objects) - `validationmethods_tags` (array of objects) - `issuemail_tags` (array of objects) - `generated_draft` (object) - `findings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['For an audit, run the live lookup and read issue and issuewild first: they carry the actual authorization. Remember the lookup semantics — a CA starts at the requested name, follows aliases as required, and climbs parent by parent until it finds the first relevant CAA RRset. A CAA RRset on a child name therefore applies to that exact name and descendant names that do not publish a closer RRset; it does not universally replace the apex policy. An empty issuer value denies issuance.', 'When drafting, authorize exactly the CAs you use, and check the operational path before you publish: your certificate automation must still succeed after the record goes live, and adding a CA must become a documented step of any future vendor change — CAA-caused renewal failures surface weeks later, at the worst possible moment, as expired certificates. If you operate ACME at scale, accounturi is the strongest cheap upgrade, because a stolen domain validation no longer suffices without your account key.'] ### Privacy and data handling Pasted records stay local. Live DNS only queries CAA owner names when requested. ### Limits and non-claims ['Pasted records stay in the browser. Live lookups use DNS-over-HTTPS first with a same-origin fallback, and RFC 3597 generic wire-format answers are decoded before validation. The tool judges record syntax and policy coherence at lookup time. It cannot see what any CA actually logged at issuance, does not scan Certificate Transparency for certificates that predate or violate your policy, and cannot verify that a CA honors iodef reports. Pair a CAA policy with CT monitoring for the full picture.'] ### Safe example example.com -> issue letsencrypt.org; issuewild ; iodef mailto:hostmaster@example.com; validationmethods dns-01. ### Frequently asked questions - **Does publishing CAA invalidate certificates that already exist?** No. CAA is evaluated only at issuance. Existing certificates run to their natural expiry regardless of policy changes — which also means CAA is not a revocation tool; it only shapes the future. - **Which CAA set applies to a name several labels deep?** The first relevant RRset found by RFC 8659 discovery: start at the requested name, follow aliases where required, then climb parent by parent. A child RRset applies to that name and descendants without a closer RRset; sibling names and the apex keep their own discovery paths. - **What happens if issuewild is absent?** Wildcard issuance then follows the issue tags. Publish issuewild only when wildcard policy should differ — for instance, allowing host certificates broadly while forbidding wildcards entirely. - **What does accounturi actually protect against?** Issuance by the right CA but the wrong hands. With accounturi, the CA additionally requires the request to come from your named ACME account, so an attacker who can pass domain validation still fails without your account key. - **Is iodef worth setting?** Set it — an address that receives violation reports costs nothing and occasionally catches a misconfiguration early. But treat it as best-effort: reporting behavior varies between CAs, so it complements CT monitoring rather than replacing it. - **Can CAA break my own renewals?** Yes, and that is the most common self-inflicted CAA incident: switching CA vendors without updating the record. The old certificates keep working, the first renewal through the new CA fails, and the failure surfaces as an expiry alert weeks later. ## 17. HTTP Header Analyzer - Canonical English page: https://admintoolkit.io/http-header-analyzer/ - Canonical tool ID: `http-header-analyzer` - WebMCP tool name: `admintoolkit_analyze_http_headers` - Category: Web Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only HTTP response-header report for a public endpoint. Accepts pasted headers or a public URL. Includes security, cache, framing, duplicate/conflicting header fields, prioritized findings and remediation notes. ['Almost everything a browser is told about how to treat a site travels in response headers: whether transport security is mandatory, what content may execute, whether the page may be framed, how cookies are scoped, how long caches may hold a response. That makes headers the fastest honest audit surface there is — and also a place where policies rot quietly, because a header removed during a debugging session or duplicated by a second proxy layer rarely announces itself.', 'This analyzer reads a response-header set and organizes it into practical groups: security headers, caching, content typing, cookies, isolation and framing policy. It flags what is missing, what is contradictory, and what is duplicated — the duplicate case matters more than people expect, because when a CDN and an origin both set the same header, what the browser enforces may be neither of the two values you intended.'] ### Processing and invocation - Input mode: `form` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `url` (string; format uri; one-of alternative): Public URL to fetch for HTTP header analysis, e.g. 'https://example.com/'. - `headers` (string; one-of alternative): Pasted HTTP response headers, e.g. 'Strict-Transport-Security: max-age=31536000'. ### Result model - `status_code` (integer or null) - `final_url` (string) - `redirect_chain` (array of objects) - `headers` (array of objects) - `security_header_findings` (array of objects) - `cache_findings` (array of objects) - `warnings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Paste headers when you already have them — from curl, browser developer tools, or a proxy — since that keeps the analysis fully local and works for responses the public internet cannot reach. Use the live fetch for the outside view of a public URL: it also records the redirect chain and the final URL, which is often where the interesting surprises live, because each hop in a redirect chain carries its own header set.', 'Work the findings by leverage. Transport and execution policy first: HSTS and Content-Security-Policy decide entire attack classes. Then cookie attributes and framing, then cache correctness — miscached personalized content is a security incident wearing a performance costume. Treat warnings as prompts rather than verdicts, and after every fix, re-run against the deployed site: header changes have a habit of passing review and then being absorbed by a middlebox on the way to production.'] ### Privacy and data handling Pasted headers stay local. Live fetches use /api/http-headers.php for public HTTP/HTTPS URLs on ports 80 and 443. ### Limits and non-claims Pasted headers stay in the browser. Live fetches go through /api/http-headers.php, which accepts full http or https URLs on ports 80 and 443 only, rejects embedded credentials, blocks private, loopback, link-local, multicast, and reserved resolved addresses, follows a small redirect chain, and sends no request body. The analyzer evaluates response headers — it does not parse page content, execute scripts, or replace a full vulnerability scan, and header policy is always judged against what the specific application needs. ### Safe example Paste headers from curl or fetch https://example.com to inspect CSP, HSTS, X-Content-Type-Options, cookies, and cache policy. ### Frequently asked questions - **Why not fetch every URL directly from the browser?** Because CORS deliberately prevents a page from reading response headers of arbitrary other sites. The same-origin endpoint performs one guarded fetch on your request and returns the headers for local analysis. - **Does a warning mean the site is insecure?** Not automatically. Header policy is application-dependent — an API responds differently than an HTML page, and an intranet tool differently than a shop. A warning marks a decision worth checking, not a proven defect. - **Why do duplicate headers get their own findings?** Because they are usually a symptom of layered infrastructure — CDN, load balancer, origin — each adding its own policy. Browsers resolve duplicates in ways that vary by header, so the effective policy can silently differ from every individual layer's intent. - **What should I look at first on a typical site?** Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, and cookie attributes. Those four decide the biggest attack classes; most of the remaining findings are refinement on top. - **Can the live fetch scan internal URLs?** No. The endpoint requires public DNS names and rejects private and reserved resolved addresses. For internal systems, capture the headers there and use the paste path — the analysis itself is identical. - **Why does the redirect chain matter for a header audit?** Because each hop is a separate response with its own headers, and protections missing on an early hop are missing for real users. An HSTS header only on the final HTTPS response, but not on the redirecting hosts, is the classic gap this view exposes. ## 18. SSL Certificate Decoder - Canonical English page: https://admintoolkit.io/ssl-cert-decoder/ - Canonical tool ID: `ssl-cert-decoder` - WebMCP tool name: `admintoolkit_decode_ssl_certificate` - Category: Web Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only X.509 TLS certificate report. Accepts PEM text or public TLS host details. Includes subject, issuer, SANs, validity, fingerprints, key usage, extensions, hostname and certificate-health findings. ['A TLS certificate is a dense bundle of claims — who the subject is, which names are covered, who vouched for it, with which algorithms, until when — and most outages caused by certificates come down to one field nobody looked at: a SAN list missing the one hostname that matters, an expiry date on a certificate everyone thought was auto-renewed, a chain that serves the leaf without its intermediate. The information is always there; it is just encoded in formats built for machines.', 'This decoder accepts exact CERTIFICATE PEM, certificate chains, strict Base64 DER, and strict hexadecimal DER and turns them into a readable X.509 report: version, serial, both signature-algorithm fields, subject, issuer, validity, SPKI, SAN, KU, EKU, Basic Constraints, SKI, AKI, AIA, CRL distribution points, policies, name constraints, SCT inventory, and unknown critical extensions. It can also fetch the certificate and presented chain a public implicit-TLS service is serving right now.'] ### Processing and invocation - Input mode: `paste_or_host` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `host` (string; one-of alternative): TLS certificate host to connect to, e.g. 'example.com'. - `port` (string; optional): TLS certificate port number, e.g. '443'. - `protocol` (string; allowed: `TLS`; optional): Certificate protocol value, currently 'TLS', e.g. 'TLS'. - `pem` (string; one-of alternative): Certificate PEM text to decode, e.g. '-----BEGIN CERTIFICATE-----'. ### Result model - `subject` (string) - `issuer` (string) - `serial_number` (string) - `valid_from` (string) - `valid_to` (string) - `subject_alt_names` (array of objects) - `key_algorithm` (string) - `signature_algorithm` (string) - `fingerprints` (object) - `chain_summary` (array of objects) - `warnings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Paste the certificate when you have it — from a file, a ticket, an ACME log — and read the verdict and findings before diving into extensions. The SAN match against your intended hostname and the validity window resolve the majority of practical questions. Hex and base64 input exist precisely because certificates arrive in inconvenient shapes: a blob from a log pipeline decodes just as well as a tidy PEM file.', 'For a live question, fetch the certificate the host actually presents and compare it with what you expected to be deployed — after renewals this is the moment mismatches surface, and the chain table shows whether intermediates are being served rather than assumed. The SPKI hash output is the bridge to DANE work: it is the value TLSA records with selector 1 pin, so the decoder doubles as the fact-checking step before touching TLSA or CAA records.'] ### Privacy and data handling Pasted certificates stay local. Live certificate retrieval uses the same-origin TLS endpoint for public DNS hosts and allowed ports. Chain inspection does not claim trust-store or revocation validation. ### Limits and non-claims Pasted certificate material stays in the browser. Live retrieval sends host and port to /api/tls-cert.php, which resolves public DNS names only, blocks private and reserved targets, allows only common implicit-TLS/HTTPS ports, and captures the peer certificate and presented chain when OpenSSL exposes it. Hostname matching follows RFC 9525-style SAN-only identity: no Common Name fallback, IP literals match only iPAddress SANs, and a wildcard covers one complete left-most label. Chain order and issuer/subject or AKI/SKI linkage are structural evidence only; cryptographic chain signatures, a trust anchor, revocation, and CT-log inclusion are not verified. ### Safe example Paste a PEM chain or fetch a public host certificate, then review SAN matching, expiry, issuer, algorithms, EKU, AIA/OCSP, CRL, policies, SCT count, fingerprints, and SPKI hashes. ### Frequently asked questions - **Which certificate does the live fetch capture?** The peer certificate the public host presents on the chosen port, plus the served chain when available. It is designed for inspecting the deployed leaf — the thing renewals and load balancers most often get wrong. - **Why is decoding not the same as verification?** Decoding reads what the certificate claims. Verification decides whether to believe it — chain building, trust stores, hostname policy, revocation, and timing all participate. This tool gives you the claims and their internal consistency. - **Does the decoder fall back to the certificate Common Name?** No. DNS identity is matched against dNSName SAN entries only, and IP literals only against iPAddress SAN entries. A Common Name is displayed as certificate content but never used as a successful identity fallback. - **What should I check after a renewal?** Serial number and validity window to confirm the new certificate is actually being served, the SAN list against every name in use, and the chain table for missing intermediates — the three renewal classics, in that order. - **Why are SPKI hashes shown?** Because the SubjectPublicKeyInfo hash is what key-based pinning uses — DANE TLSA records with selector 1 in particular. Reading it here means the value you publish elsewhere is derived from the certificate, not transcribed by hand. - **Why is a SHA-1 fingerprint still displayed?** Purely as an identifier: plenty of operational systems still reference certificates by SHA-1 fingerprint. Its presence is for cross-referencing, not an endorsement of SHA-1 for any cryptographic purpose. - **Can it inspect internal or private hosts live?** No. The live endpoint accepts public DNS names on a small set of TLS ports. For internal systems, export the certificate and use the paste path — the analysis is the same. ## 19. security.txt Validator/Generator - Canonical English page: https://admintoolkit.io/security-txt-validator-generator/ - Canonical tool ID: `security-txt-validator-generator` - WebMCP tool name: `admintoolkit_validate_security_txt` - Category: Web Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only RFC 9116 security.txt report. Accepts pasted content or a public security.txt URL plus optional contact fields. Includes contact, expiry, canonical, encryption, policy, language fields, findings and draft output. ["When an external researcher finds a vulnerability in your infrastructure, the next thirty minutes decide whether you get a responsible report or a public write-up. RFC 9116's security.txt exists for exactly that moment: a machine-readable file at a well-known URL that says who to contact, in which language, under which policy, and with which PGP key to encrypt. It is one of the cheapest security controls available — and one of the most commonly botched.", "The most frequent failure is quiet expiry. The RFC makes the Expires field mandatory precisely because stale contact files were the norm, and an expired security.txt reads as an unmaintained security function. The second failure is unreachable or misplaced files: served from the root but not from /.well-known/, redirected to a marketing page, or blocked by an overzealous WAF rule. This tool validates a fetched or pasted file against the RFC's field rules and generates a clean draft when you are starting fresh."] ### Processing and invocation - Input mode: `paste_or_url` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `url` (string; format uri; one-of alternative): Public security.txt URL or bare domain, e.g. 'https://example.com/.well-known/security.txt'. - `content` (string; one-of alternative): Pasted security.txt content, e.g. 'Contact: mailto:security@example.com'. - `contact` (string; optional): Generated Contact field value, e.g. 'mailto:security@example.com'. - `encryption` (string; format uri; optional): Generated Encryption URL value, e.g. 'https://example.com/pgp.txt'. - `policy` (string; format uri; optional): Generated Policy URL value, e.g. 'https://example.com/security-policy'. - `pgp_key` (string; optional): Generated PGP key identifier, e.g. 'openpgp4fpr:ABCD...'. ### Result model - `contacts` (array of strings) - `expires` (string) - `canonical` (string) - `encryption` (array of strings) - `policy` (array of strings) - `hiring` (array of strings) - `preferred_languages` (array of strings) - `generated_draft` (string) - `findings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['For an existing deployment, fetch the live file and read the findings in order of severity: a missing or past Expires date first, malformed Contact entries second, then Canonical mismatches. Contact entries are listed in preference order, so put the mailbox you actually monitor first, and remember that mailto and https URIs each have syntax rules the RFC enforces strictly.', 'When generating, resist the temptation to fill in every optional field. A short honest file — Contact, Expires within a year, Canonical, Encryption if you can handle PGP mail — beats a long aspirational one. If you sign the file, the Canonical field becomes load-bearing: it binds the signature to the URL, so it must exactly match where the file is served. Sign locally with your own key; the page provides the gpg commands but never touches private key material.'] ### Privacy and data handling Pasted files stay in the browser. Live fetches use the guarded same-origin helper with public-host and size limits. ### Limits and non-claims ['Pasted content stays in the browser, and URL fetches run through the same-origin helper against public hosts. The validator proves structure: that fields parse, dates conform to RFC 3339, and URIs are well-formed. It cannot prove that anyone reads the mailbox, that the PGP key referenced under Encryption is the one your team can actually decrypt with, or that your process responds within a reasonable time. Syntax is the entry ticket; the process behind it is yours.'] ### Safe example https://example.com/.well-known/security.txt -> Contact, Expires, Canonical, Encryption, Policy, Hiring, and Preferred-Languages. ### Frequently asked questions - **Why is Expires mandatory when most metadata files have no expiry?** Because contact information rots silently. An enforced expiry forces a periodic review, and researchers treat a current date as a signal that someone still owns the process. Keep validity at a year or less and renew it like a certificate. - **Does the file belong at /.well-known/ or at the site root?** The canonical location is /.well-known/security.txt. Serving it additionally at /security.txt is a widely practiced legacy courtesy. If you serve both, keep them byte-identical — diverging copies are worse than a missing legacy copy. - **Is signing the file worth the operational overhead?** If you list a PGP key under Encryption anyway, signing is consistent and cheap: it lets a researcher verify the contact data was published by the key holder. If your team has no PGP workflow, an unsigned but current and accurate file is far better than a signed stale one. - **Can I list several Contact entries?** Yes, and order matters: the RFC defines earlier entries as preferred. A common pattern is a monitored security mailbox first, then a web form as fallback. Every listed channel must actually be monitored — each one is an implicit promise. - **What does the Canonical field protect against?** Copies. If your file is mirrored or scraped to another URL, Canonical states where the authoritative version lives, and for signed files it binds the signature to that location. Without it, a stale copy elsewhere is indistinguishable from your real one. - **Does a valid security.txt improve my security rating?** Several external scanners and rating services check for it, and it appears in agent-readiness and security-hygiene scoring. But the real payoff is operational: it removes every excuse for a finder not to contact you first. ## 20. TLS Configuration Checker - Canonical English page: https://admintoolkit.io/tls-configuration-checker/ - Canonical tool ID: `tls-configuration-checker` - WebMCP tool name: `admintoolkit_check_tls_configuration` - Category: Web Security - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only public TLS configuration report for a host. Accepts host and port plus optional HSTS evidence. Includes separate exact-version probes, a distinct verified default handshake, SAN identity/trust evidence, negotiated cipher and ALPN evidence, and HTTPS-only HSTS checks; it does not claim cipher or ALPN enumeration. ["When TLS breaks, it rarely breaks loudly. A certificate renewed for the wrong hostname, a load balancer that still accepts TLS 1.0, or an h2 offer that negotiates only HTTP/1.1 may surface later as browser warnings, failed API clients, performance investigations, or an auditor's finding.", 'This checker runs separate exact-version probes for TLS 1.0, 1.1, 1.2, and 1.3, plus a distinct peer- and hostname-verifying default handshake. It reports supported, rejected, locally unsupported, connection-failed, and otherwise inconclusive outcomes separately. The negotiated version, cipher, certificate SAN match, and ALPN describe only their individual handshakes; no full cipher or ALPN enumeration is claimed. HSTS and HTTP/2/3 evidence are evaluated only for a DNS-name HTTPS endpoint on port 443.'] ### Processing and invocation - Input mode: `form` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `host` (string; required): Public TLS DNS host or IP literal to check, e.g. 'example.com' or '1.1.1.1' (no scheme; private/reserved targets are rejected). - `port` (string; optional): TLS port number to check, e.g. '443'. - `hsts` (string; optional): Optional pasted HSTS header, e.g. 'max-age=31536000; includeSubDomains'. ### Result model - `valid` (boolean) - `host` (string) - `port` (integer) - `targetType` (string) - `protocols` (object) - `protocolProbes` (object) - `selectedProtocol` (string) - `alpn` (array of strings) - `h2_verified` (boolean or null) - `h2_evidence` (object) - `alt_svc_h3_advertised` (boolean or null) - `alt_svc_h3_raw` (string) - `http3_verified` (boolean or null) - `http3_evidence` (object) - `ciphers` (array of strings) - `certificate` (object) - `certificateEvidence` (object or null) - `hsts` (string) - `hstsPolicy` (object) - `findings` (array of objects) - `counts` (object) - `grade` (string) - `evidenceScope` (string) - `summary` (string) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Use the DNS hostname for ordinary virtual-host testing because the checker sends SNI for DNS names. A public IP literal is accepted only for explicit IP-endpoint checks and is matched against iPAddress SAN entries without SNI; it may therefore expose a default virtual host rather than the certificate users receive by name.', 'Read the results as a set. A successful exact TLS 1.0 probe points at appliance or load-balancer defaults. A SAN mismatch after a migration usually means the new frontend presents the wrong certificate. A failed h2 probe proves only that h2 was not negotiated for that offered protocol and handshake; it does not enumerate every ALPN combination. Missing HSTS on a DNS-name HTTPS endpoint is a separate HTTP policy gap, not a property of the TLS handshake.'] ### Privacy and data handling The host is sent only to the same-origin TLS helper when requested. Pasted evidence stays local. ### Limits and non-claims ['The same-origin endpoint restricts targets to public DNS names or globally routable IP literals and common implicit-TLS/HTTPS ports. It runs four exact-version capability handshakes plus separate presented and peer/hostname-verified default handshakes from one vantage point. It does not enumerate ciphers or all ALPN offers, check revocation, validate against every trust store, or provide multi-vantage coverage. A clean result is bounded evidence, not a compliance statement.'] ### Safe example example.com:443 -> separate exact-version probe outcomes, verified certificate identity, negotiated cipher/ALPN evidence, and HTTPS-only HSTS evidence. ### Frequently asked questions - **The browser shows a different certificate than this probe. Why?** Usually SNI or routing: the server picks certificates per requested name, and a CDN may route this probe to a different edge than your browser. Both observations are real; the difference tells you certificate selection depends on the path, which is worth knowing. - **Is TLS 1.0 or 1.1 support still a real problem?** Yes, as a policy and audit matter. Modern clients will not use them, but accepting them signals unmaintained configuration, fails common compliance baselines, and leaves the door open for downgrade tricks against legacy clients. - **Does the cipher shown represent everything the server supports?** No. It is only the cipher negotiated by the reported default handshake. The checker does not enumerate the server's cipher suites, so an unobserved weak cipher is neither proved enabled nor proved disabled. - **What does a missing ALPN value prove?** It proves only that the reported handshake did not negotiate an application protocol. The checker offers h2 separately under TLS 1.2 and TLS 1.3 on HTTPS port 443; it does not claim to enumerate every protocol the server could negotiate with other offers or clients. - **Should every site send HSTS?** Every production HTTPS site should send a sensible max-age. Be deliberate with includeSubDomains and especially with preload: preloading is close to irreversible and has broken subdomains that quietly still needed HTTP. - **Can I check an internal host with this?** No. The live endpoint only accepts public DNS names or globally routable IP literals. For internal endpoints, run a local probe from a machine that can reach them; the same reading order applies. ## 21. Redirect / Canonical / Indexability Checker - Canonical English page: https://admintoolkit.io/redirect-canonical-indexability-checker/ - Canonical tool ID: `redirect-canonical-indexability-checker` - WebMCP tool name: `admintoolkit_check_redirect_indexability` - Category: Web / SEO - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only redirect, canonical and indexability report for a public URL. Accepts a URL. Includes bounded per-hop status and SSRF evidence, final URL, HTML and HTTP canonical hints, robots meta and scoped X-Robots-Tag directives, hreflang, separate sitemap reachability and membership, and evidence completeness. ['Most indexing problems are not penalties. They are plumbing: a redirect chain that grew one hop per migration, a canonical tag still pointing at the old domain, a leftover noindex directive that survived the go-live, or an X-Robots-Tag header added by a proxy nobody remembers configuring. Each signal on its own looks harmless. Together they can tell a crawler four slightly different stories about the same page, and crawlers respond to contradictions by trusting the page less.', 'This checker follows a public URL the way a crawler would and lays the evidence side by side: the full redirect chain with status codes, the final URL, the canonical link, robots directives from both the meta tag and the HTTP header, hreflang annotations, and whether the sitemap that should announce the page is actually reachable. The value is not any single field. It is seeing at a glance whether all of them agree.'] ### Processing and invocation - Input mode: `url` - Processing: default. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `url` (string; format uri; required): Public URL to check for redirects and indexability, e.g. 'https://example.com/'. ### Result model - `status_chain` (array of objects) - `final_url` (string) - `canonical_url` (string) - `robots_meta` (string) - `x_robots_tag` (string) - `hreflang` (array of objects) - `sitemap_status` (object) - `indexability_findings` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Start with the exact URL you expect users and crawlers to request, including scheme and trailing slash, because those details are precisely where chains hide. Read the redirect evidence first: more than one hop is an optimization opportunity, while 301, 302, 303, 307 and 308 each have valid semantics. A temporary redirect is not inherently wrong; judge it against the intended routing or migration.', 'Then compare every HTML and HTTP Link canonical with the final URL. A canonical is a consolidation hint, not a command, so a different or cross-domain target can be intentional; conflicting canonicals, a target that redirects, or a non-success target deserve review. Finish with all robots metadata: multiple general directives combine restrictively, while user-agent-scoped X-Robots-Tag values remain separate evidence rather than universal rules.'] ### Privacy and data handling Live fetches use the guarded same-origin helper for public HTTP/HTTPS URLs only when requested. ### Limits and non-claims ['Live fetches run through the same-origin helper with public-host validation, DNS pinning on every hop, bounded redirects and bounded response size. The checker reads served HTML and headers only and never executes JavaScript. It resolves relative canonical and hreflang URLs, but it does not load hreflang targets, so reciprocal annotations are explicitly not evaluated. Sitemap reachability and membership are reported separately from robots and canonical hints.'] ### Safe example https://example.com/page -> status chain, final URL, canonical link, robots meta, X-Robots-Tag, hreflang and sitemap reachability. ### Frequently asked questions - **Is one redirect hop acceptable?** Usually yes. The pattern to avoid is chains: http to https to www to trailing slash to CDN rewrite. Every hop adds latency, dilutes signals, and raises the chance one link in the chain breaks unnoticed during the next migration. - **What is the practical difference between 301 and 302 here?** A 301 expresses a permanent move; a 302 expresses a temporary one. Both can be correct. The checker preserves that evidence and reports a temporary status as informational because only the operator knows whether the routing or migration is intended to be temporary. - **My page has a canonical tag. Why is it still not indexed?** A canonical is a hint, not a command. If the page also carries noindex, returns a non-200 status, sits behind a robots.txt block, or the canonical target contradicts other signals, the hint loses. Check the whole evidence row, not the one tag. - **Where does an unexpected X-Robots-Tag header usually come from?** From infrastructure rather than the page: reverse proxies, CDN rules, security plugins, or an obsolete configuration that was copied to production. The page template looks clean, so header-level directives are the first place to look when the meta tag says index but the page stays out. - **Should my sitemap list URLs that redirect?** No. A sitemap should contain final, canonical, 200-status URLs only. Listing redirecting or noindexed URLs wastes crawl budget and muddies the signal about which version of a page you consider authoritative. - **Does hreflang affect indexability?** Indirectly. This checker validates the supplied language tags, resolves relative targets and recommends a self-reference. It does not load every language target, so it makes no claim about reciprocal annotations unless that evidence is explicitly available. ## 22. What is my IP? - Canonical English page: https://admintoolkit.io/what-is-my-ip/ - Canonical tool ID: `what-is-my-ip` - WebMCP tool name: `admintoolkit_show_public_ip_context` - Category: Network - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only same-origin IP context report for the current request. Requires no input. Includes the canonical primary address, directly observed peer, trusted-proxy decision, preserved forwarded-header claims and observed address family; one request path does not prove dual-stack capability and no third-party Geo-IP lookup is performed. ['Behind a VPN, a corporate proxy, carrier-grade NAT, or a dual-stack connection, the question "what is my IP" stops having an obvious answer — different services may legitimately see different addresses for the same machine at the same moment. What this page shows is one precisely defined truth: the public address from which this site received your request, together with the request context that arrived with it.', 'Around that primary answer, the page assembles the metadata that makes it interpretable: the observed address family, the directly observed peer, trusted-proxy decision, forwarded-header claims, browser language, time zone, and user agent. Geo-IP, ASN details, and the map are separate click-gated actions, because the same-origin address answer does not require a third-party lookup.'] ### Processing and invocation - Input mode: `implicit_request` - Processing: page-load request-context reflection plus third-party Geo-IP enrichment; ASN details and map loading remain separate actions. - Network boundary: page load calls same-origin `/api/ip.php` and third-party `https://api.ip.sb/geoip`; ASN details and Google Maps requests occur only after their separate user actions. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - No user-supplied input is required; the tool reports the request context visible to its public page. ### Result model - `public_ip` (string) - `ip_version` (string) - `user_agent` (string) - `accept_language` (string) - `forwarded_headers_if_available` (object) - `geo_city_region_country` (object) - `asn_org_timezone_coordinates` (object) - `click_gated_map` (object) - `timestamp_utc` (string) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Take the primary IP first — it answers the common cases: is the VPN actually engaged, does the office exit where you think, which address should go into an allowlist. Then read the context around it. The IP version matters more than it looks: a dual-stack client can reach one service over IPv6 and another over IPv4, which produces exactly the confusing situation where two IP checkers disagree and both are right.', 'Use the deeper layers when the question warrants them. Forwarded headers show what proxies and CDNs claimed about the original client — displayed as claims, not as trusted identity, because that is what they are. Geo-IP places the address approximately; the ASN detail answers whose network it belongs to, which is often the operationally interesting fact. The map is last and loads only on click, as a separate Google Maps iframe — coordinates from Geo-IP data are neighborhood-accurate at best.'] ### Privacy and data handling Only the same-origin public IP endpoint runs on page load. Geo-IP/ASN data requires one click, and Google Maps requires a second separate click. ### Limits and non-claims The primary answer comes from the same-origin /api/ip.php endpoint on page load. REMOTE_ADDR remains the directly observed peer; CF-Connecting-IP becomes primary only when that peer belongs to the verified Cloudflare network list and the claim is a canonical public address. X-Forwarded-For and other proxy claims are preserved but not trusted. Geo-IP/ASN is requested from api.ip.sb only after the Geo button, and the Google Maps iframe only after its own second opt-in. One request path observes one address family and does not prove dual-stack capability. ### Safe example Open the tool to see the same-origin address evidence, then request Geo-IP/ASN or map details separately only if needed. ### Frequently asked questions - **Why does this differ from another IP checker?** Different checkers sit behind different CDNs, resolver paths, IPv4/IPv6 preferences, and proxy-header interpretations. Each reports what it sees; this page reports what this site saw for this request — with the surrounding context to explain disagreements. - **Does this page expose local private addresses?** No. Modern browsers do not reveal local or private addresses to a web page. What you see is the public remote address from the web server's perspective — your router's outside face, typically. - **When exactly is the map loaded?** Only after coordinates exist and you press the map button. The map is a separate Google Maps iframe, deliberately excluded from the initial page render so the basic check involves no maps provider at all. - **How accurate is Geo-IP?** City-level at best, and honestly wrong at times: VPN exits, mobile carriers, corporate egress points, and recently reassigned prefixes all mislead it. Country is usually reliable; street-level precision is a myth. - **What are forwarded headers, and can I trust them?** Entries like X-Forwarded-For that proxies and CDNs add to describe the original client. They are useful diagnostic claims, but any hop can set them to anything — which is why this page displays rather than trusts them. - **Why do I see an IPv6 address when I expected IPv4?** Dual-stack connections prefer IPv6 when it is available end to end. Another service without IPv6 would see your IPv4 address — both observations are correct, each for its own path. ## 23. CIDR/Subnet Calculator - Canonical English page: https://admintoolkit.io/cidr-subnet-calculator/ - Canonical tool ID: `cidr-subnet-calculator` - WebMCP tool name: `admintoolkit_calculate_cidr_subnet` - Category: Network - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only local IPv4 or IPv6 CIDR report. Accepts a CIDR block plus optional split prefix and address family. Includes exact BigInt-derived boundaries and address counts, RFC 3021 /31 and host-route /32 semantics, no IPv6 broadcast claim, embedded-IPv4 parsing and a capped subnet preview. ['Subnet arithmetic is unforgiving in a way little else in networking is: an off-by-one in a boundary or a mask misread by one bit ends up in a firewall rule, a routing table, or a DHCP scope, and produces the sort of outage that gets diagnosed at midnight. The math itself is mechanical — which is precisely the argument for not doing it in your head during a change window.', 'This calculator takes an IPv4 or IPv6 CIDR block and returns the facts a plan is built from: exact network boundaries and address counts, IPv4 broadcast or RFC 3021 point-to-point roles, first and last addresses, and IPv4 netmask and wildcard mask. Given a target prefix, it also previews a bounded sample of smaller subnets — the everyday operation of carving a /24 into /26s or a /48 into /64s, done by rules instead of by habit.'] ### Processing and invocation - Input mode: `form` - Processing: fully local; no network path. - Network boundary: none; all diagnostic logic runs entirely in the browser. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `cidr` (string; required): CIDR block to calculate, e.g. '192.0.2.0/24'. - `target` (string; optional): Split target prefix length, e.g. '26' for /26 subnets. - `family` (string; allowed: `auto`, `ipv4`, `ipv6`; optional): Address family: 'auto', 'ipv4', or 'ipv6', e.g. 'ipv4'. ### Result model - `network_address` (string) - `broadcast_address` (string or null) - `first_usable` (string) - `last_usable` (string) - `prefix_length` (integer) - `netmask` (string) - `wildcard_mask` (string) - `total_addresses` (integer or decimal string) - `subnets` (array of objects) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ['Enter the address with its prefix and read the boundaries first — network plus first and last address. For IPv4, the broadcast or /31-/32 role and wildcard mask are explicit; IPv6 correctly has no broadcast field. IPv4 and IPv6 are detected automatically, including embedded dotted IPv4 in IPv6; forcing the family is only needed for ambiguous shorthand.', 'Add a target prefix when you need the split. The preview is intentionally capped: a /16 into /29s is over eight thousand subnets, and IPv6 splits reach numbers with no operational meaning — the first entries plus the per-subnet size are what a plan actually requires. For allocation work, note the counts more than the list: how many subnets the split yields and how many addresses each carries is the decision-relevant pair.'] ### Privacy and data handling All calculations run locally. No address, subnet plan, or split request is sent anywhere by this tool. ### Limits and non-claims Every calculation runs locally in the browser — no address, subnet plan, or split request is sent anywhere by this tool, which makes it safe for private and internal addressing plans. IPv6 math uses integer arithmetic throughout, so large prefixes stay exact rather than floating-point-approximate; the subnet list display is capped to keep the browser responsive. The calculator computes address structure — it does not know your routing policy, VLAN layout, or reservation conventions, and it cannot tell you whether a technically valid split is operationally wise. ### Safe example 192.168.10.42/24 with a /26 split shows exact network math and a capped preview; /31 follows RFC 3021, while IPv6 has no broadcast address. ### Frequently asked questions - **Why are /31 and /32 IPv4 networks treated specially?** Because the traditional network-plus-broadcast model does not apply: a /31 is a two-address point-to-point link per RFC 3021, and a /32 is a single host. The calculator reports them that way instead of pretending they contain unusable addresses. - **Why is the subnet list capped?** Because splits scale exponentially — thousands of rows for modest IPv4 cases, astronomically more for IPv6. The first subnets establish the pattern; rendering the rest would freeze the page without adding information. - **Does IPv6 have a broadcast address?** No. IPv6 replaced broadcast with multicast, so the result shows first and last address of the block instead. The last address is a perfectly ordinary assignable address in IPv6. - **What is the wildcard mask for?** It is the bit-inverted netmask, used by ACL syntax on many routers and firewalls. Having it computed next to the netmask removes the manual inversion step where ACL errors classically originate. - **Why does a /64 seem excessive for one LAN?** Because IPv6 was designed around subnet size uniformity rather than address conservation: SLAAC requires a /64, and features across the ecosystem assume it. Address scarcity thinking from IPv4 mostly does not transfer. - **Is it safe to enter private network plans?** Yes, for this calculator: the math runs entirely locally and nothing is transmitted. The general caution stands — keep internal plans out of URLs, analytics, and third-party tools — and this page is built to respect exactly that. ## 24. HDMI EDID Decoder - Canonical English page: https://admintoolkit.io/edid-decoder/ - Canonical tool ID: `edid-decoder` - WebMCP tool name: `admintoolkit_decode_edid_data` - Category: Hardware / AV - Read-only: yes - Destructive: no - Authentication: none - Idempotent contract: yes ### Purpose and scope Return a read-only share-safe local EDID capability report. Includes strict hex or local file text decoding, checksum and trust state, a readable timing/VIC/Y420 matrix, CTA audio and speaker topology, qualified HDMI Forum transport, HDR and DisplayID evidence, coverage and byte provenance. WebMCP omits display identifiers, serials, filenames, physical addresses, raw bytes and vendor payload values; it does not infer Atmos, DTS:X, HDMI certification, cable capability or source mode selection. ["Every HDMI handshake starts with the sink handing the source an EDID: a compact binary self-description containing declared timings, audio format codes, static HDR metadata, and identity data. When a setup falls back to 1080p, loses an audio format, or loses HDR after a chain change, the relevant evidence may be in the blob the source received. That blob may not be the display's own: AVRs, matrices, splitters, and EDID emulators can merge, limit, or replace it.", 'This decoder accepts strict EDID hex or a local binary or text file and builds one evidence-first report. It covers EDID 1.3/1.4 base data, registered CTA video modes, full Short Audio Descriptor occurrences, three distinct speaker maps, HDMI VSDB context, supported HDMI Forum SCDS transport fields such as FRL, DSC, VRR, ALLM, QMS and FVA, qualified static and dynamic HDR records, Dolby Video, HDR10+, SBTM, and supported DisplayID 1.3 and 2.x sections. Unsupported, malformed, truncated, conflicting, or checksum-untrusted data stays explicitly marked with byte provenance instead of becoming an affirmative capability claim.'] ### Processing and invocation - Input mode: `paste_or_file` - Processing: fully local; no network path. - Network boundary: none; all diagnostic logic runs entirely in the browser. - WebMCP runtime: `document.modelContext.registerTool` ### Inputs - `file` (string; one-of alternative): Local EDID file content represented as strict hexadecimal text; binary file selection is available in the visible browser UI. - `edid_hex` (string; one-of alternative): Pasted strict EDID hexadecimal text, e.g. '00ffffffffffff00...'. ### Result model - `manufacturer` (string) - `product_code` (integer) - `serial` (integer) - `manufacture_week_year` (object) - `display_size` (object) - `preferred_timing` (object) - `supported_timings` (array of objects) - `timing_capability_matrix` (array of objects) - `cta_extensions` (array of objects) - `ycbcr420_modes` (array of objects) - `audio_formats` (array of objects) - `speaker_topology` (object) - `hdmi_transport` (array of objects) - `hdr_capabilities` (object) - `displayid_sections` (array of objects) - `checksum_status` (array of objects) - `coverage` (object) - `byte_provenance` (object) - `warnings` (array of objects) - `privacy_safe_exports` (object) - Response contract: WebMCP responses identify the tool and tool ID, include bounded status and `ok` fields, and keep `readOnly` true. ### Recommended workflow ["Capture the EDID at the exact point you are troubleshooting — from the display itself, from the AVR's output, from behind the matrix — because every device in the chain may present a different one, and decoding the wrong blob answers the wrong question. Check identity and checksums first: a vendor string that does not match the display, or a failing checksum, tells you immediately that you are looking at an emulator, an override, or corruption.", 'Then read the structured evidence in order: conformance findings, advertised video modes, every audio descriptor occurrence, speaker and room maps, HDMI transport, HDR, DisplayID, and finally coverage and raw byte evidence. The renderer distinguishes encoded JOC or codec-dependent flags from broad proprietary playback claims, keeps static and dynamic HDR separate, and shows negative or malformed fields instead of silently upgrading them. Decode captures one at a time and compare the exported share-safe summaries manually if needed; built-in side-by-side comparison, source-mode choice, and signal-chain feasibility analysis are not implemented.'] ### Privacy and data handling Input, decoding, reports, and exports stay in this third-party-free browser route. Its route-specific policy blocks network connections and form submission; default exports omit identity and raw/vendor payload values. ### Limits and non-claims The EDID route is intentionally third-party-free and its route policy disables network access; parsing, rendering, clipboard output, and downloads stay local. The on-screen forensic report may show identity and raw evidence. Default JSON, Markdown, clipboard, redacted-hex, and WebMCP results use an explicit share-safe projection that omits identity, topology, filenames, raw values, unknown vendor payloads, and stable fingerprints. Exact original bytes require a separate one-shot sensitive-data confirmation. Side-by-side comparison, source-mode choice, and end-to-end feasibility analysis are not implemented, so the report cannot prove which mode a source will select or whether the full signal chain can carry it. Nothing here writes or modifies an EDID. ### Safe example Paste EDID hex from the exact point in the HDMI chain and inspect timing/Y420, audio/speakers, HDMI transport, HDR, DisplayID, checksums, and byte provenance. ### Frequently asked questions - **What size should EDID data be?** EDID comes in 128-byte blocks: a base block plus optional extension blocks, so 128, 256, or more bytes in complete multiples. The decoder expects whole blocks and verifies each block's checksum. - **Why does my AVR show different EDID data than the TV?** Because devices in the chain actively manage EDID: an AVR merges its audio capabilities into the display's video capabilities, and matrices or splitters often present the lowest common denominator or a fixed table. That is normal — and precisely why capture point matters. - **Can this tool change or write an EDID?** No. It only decodes what you paste or load — it does not program emulators, flash displays, or set driver overrides. Use it to verify what an override should contain, and to check what one actually contains afterwards. - **What does a checksum or trust failure mean?** Each 128-byte EDID block must sum to zero modulo 256, and DisplayID adds its own section framing and checks. A failure can indicate truncation, a copy-paste error, malformed length data, an inconsistent extension count, or genuine corruption. The report retains the evidence but suppresses or qualifies claims that depend on untrusted bytes. - **Why is a capability missing even though the display supports it?** The source only sees the EDID it receives, not the display's specification sheet. An intermediate device may strip a declaration, an override may be active, the relevant block may be malformed, or the field may be outside the decoder's pinned public registry. Missing evidence is not proof that hardware lacks the feature. - **Does the decoder compare captures or choose a mode?** No. It decodes one active source at a time. It does not compare two EDIDs, model link budgets, account for cable or repeater limits, apply a source's selection policy, or prove end-to-end playback. - **Does EDID contain private data, and what is safe to export?** It can carry manufacturer and product identity, manufacture date, serial-like values, HDMI topology, DisplayID identification, and unknown vendor bytes. Default exports and WebMCP omit those fields through an allowlisted share-safe report. Redacted hex is evidence text rather than a loadable EDID; the exact original is available only after a separate one-shot confirmation. ## Interpretation boundary The reference describes what each public read-only tool accepts, returns and does not claim. It is not a promise that every external resolver, server, certificate chain, mail path, crawler or browser will behave identically. Re-run time-sensitive checks and preserve the returned evidence when making an operational decision. For discovery and current route navigation, use the smaller primary document: [admintoolkit.io llms.txt](https://admintoolkit.io/llms.txt).