TLS cert verdict (OK/WARN/CRITICAL/UNKNOWN) from the served chain: expiry, revocation, alerts
Scored across 7 tools
check_certificate and check_expiry overlap in certificate status/expiry reporting, but one is a single-domain deep diagnostic and the other a batch inventory for CI/inventories. check_dns vs check_dns_propagation are clearly separated (facts vs resolver comparison), and the remaining tools target distinct actions (security posture, offline error explanation, monitoring subscription).
All tool names use consistent snake_case with a verb_noun pattern (check_certificate, check_dns, check_dns_propagation, check_expiry, check_security, explain_tls_error, watch_expiry). There are no casing or style deviations.
Seven tools for a certificate/DNS/security checking service is well-scoped. Each tool covers a distinct capability without obvious redundancy or filler.
The surface covers detailed certificate checks, DNS facts, DNS propagation, batch expiry verdicts, security posture, TLS error explanation, and monitoring subscription. Minor gaps exist: no way to list or cancel watch_expiry subscriptions, and no standalone revocation-only or CT-log query, but core workflows are present.
Check one domain's TLS certificate and return a verdict: status OK | WARN | CRITICAL | UNKNOWN, judged from the certificate chain the server actually serves — measured from Korean point A (full chain and CRL revocation) plus Korean point B and an overseas point on the Globalping public measurement network (per-point results in measuredFrom; disagreement between points is a WARN) — verification (expired, not yet valid, hostname mismatch, self-signed, untrusted root, missing intermediate, revoked via CRL), days left, renewal point, a newer certificate issued but not deployed (CT logs), the served chain and the issuing CA's incident history. If the server cannot be measured the status is UNKNOWN and CT logs are shown only as an estimate — never as OK. Set detail=true to include the full chain in the text output.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | TLS port (default 443). Implicit TLS: 8443 4443 9443 6443 636 465 993 995 853 5061 3269 8883; STARTTLS: 25 587 (SMTP), 143 (IMAP), 110 (POP3), 389 (LDAP). Or pass domain as host:port | |
| detail | No | Include the full certificate chain in the text output (default false) | |
| domain | Yes | Domain name, e.g. example.com | |
| critDays | No | Days before expiry that count as CRITICAL "expiring soon" (default 15; must be < warnDays) | |
| warnDays | No | Days before expiry that count as WARN (default 30; the default shrinks for short-lived certificates) |
| Name | Required | Description |
|---|---|---|
| domain | Yes | |
| status | Yes | UNKNOWN = could not be measured (never treat as OK) |
| reasons | Yes | |
| headline | Yes | One-line verdict (Korean) |
DNS and hosting facts for a domain: nameservers with DNS provider, A/AAAA with IP owner (ASN), CNAME, MX, CAA (which CAs may issue), SPF/DMARC, DNSSEC, registrar and domain expiry (RDAP).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, openWorldHint=true, destructiveHint=false). The description adds value by enumerating the facts returned, helping an agent understand what this read operation produces. It aligns with the annotations and adds coverage context; it doesn't mention network latency or rate limits, but for a simple read tool with annotations present this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence, front-loaded with the core purpose before a colon-delimited fact list. Every item in the enumeration earns its place and there is no filler, though the list runs long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity: a single required parameter, no output schema, and no nested objects. Annotations cover the read-only safety profile, and the fact list gives a strong sense of the return coverage. Given the low complexity, nothing critical is missing for an agent to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single 'domain' parameter is fully documented with an example in the schema. The description adds no format details beyond what the schema already provides, so the baseline of 3 applies. No additional parameter semantics are needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) and resource (DNS and hosting facts) with a detailed enumeration of coverage: nameservers with provider, A/AAAA with ASN owner, CNAME, MX, CAA, SPF/DMARC, DNSSEC, registrar, and RDAP expiry. This differentiates it from siblings like check_certificate and check_dns_propagation. However, it doesn't explicitly separate itself from check_expiry, which also reports expiry, leaving minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus its alternatives. check_dns_propagation (propagation status) and check_expiry (expiry only) overlap meaningfully with this tool's fact set, yet no exclusions or alternative routing is provided. An agent must infer usage from the fact list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare answers for one DNS record across resolvers — the authoritative nameservers, Korean ISPs (KT, SK Broadband, LG U+) and public resolvers (Cloudflare, Google, Quad9, OpenDNS) — measured from a Korean network. Use it to confirm a TXT/CNAME for certificate domain validation (e.g. _acme-challenge) has propagated.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Record name, e.g. _acme-challenge.example.com | |
| type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the description's main value is specifying that measurements are from a Korean network and that it compares across specific resolvers. It does not contradict annotations, and it adds useful context about the network vantage point, but does not detail response format or potential delays.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the tool's purpose, and provides a concrete use case. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers its purpose, use case, and network context. It doesn't have an output schema, but the description mentions comparing answers, which implies a response format. Missing details like timeout behavior or error handling are minor, as annotations cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the 'name' parameter is well-described with an example, but 'type' only has an enum without explicit examples. The description implies the 'name' is a record name and mentions TXT/CNAME for validation, adding some value. However, it doesn't clarify how 'type' interacts with the comparison or whether all types are supported equally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares DNS answers across specific resolver groups and explicitly names the use case (confirming TXT/CNAME for certificate domain validation). It distinguishes itself from sibling tools like check_dns by focusing on propagation across multiple resolvers rather than a single lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use it (confirm propagation for certificate validation) and implicitly distinguishes from check_dns (which likely checks DNS records generally). However, it doesn't explicitly say when not to use it or mention alternatives like check_certificate, leaving some guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verdict for up to 5 domains at once: status OK | WARN | CRITICAL | UNKNOWN per domain combining the served certificate (verification, days left — null when the server cannot be measured) and domain registration expiry (RDAP), plus Korean alert lines. Use this for inventories, CI gates (fail unless status is OK) and periodic checks.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Domain names | |
| critDays | No | Days before expiry that count as CRITICAL "expiring soon" (default 15; must be < warnDays) | |
| warnDays | No | Days before expiry that count as WARN (default 30; the default shrinks for short-lived certificates) |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| checkedAt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower, yet the description still adds useful behavior: it discloses the per-domain status set, the null days-left case when the server cannot be measured, and that Korean alert lines are included. It does not mention rate limits or failure modes when RDAP lookups time out, which would complete the picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: the verdict/status definition leads, then the data sources, then usage cases. It is dense but every clause carries information; no filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value explanation is not required, and the description adequately covers what the tool does, its inputs' meaning, and when to use it. A brief note on partial failures (e.g. some domains UNKNOWN because RDAP is unreachable) would make it fully complete for a multi-domain batch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents domains, critDays, and warnDays. The description reinforces the domain cap ('up to 5 domains at once') and links the WARN/CRITICAL vocabulary back to the warnDays/critDays parameters, adding meaning beyond the raw schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Verdict for up to 5 domains at once') with an explicit output vocabulary (OK | WARN | CRITICAL | UNKNOWN) and names the two data sources it combines (served certificate + RDAP registration). This clearly separates it from siblings like check_certificate (single-cert only) and watch_expiry (ongoing monitoring).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage contexts: inventories, CI gates (fail unless status is OK), and periodic checks. It does not explicitly name an alternative such as watch_expiry for continuous monitoring, so an agent must still infer the boundary between one-shot checks and ongoing watching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Security posture check of a web server (no port scanning): TLS protocol support (legacy 1.0/1.1 detection via a Korean network probe), security headers (HSTS/CSP/X-Content-Type-Options/anti-clickjacking/Referrer-Policy), HTTP→HTTPS redirect, and certificate key/signature strength. Returns per-item pass/warn/fail and an overall grade.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and non-destructive behavior, so the description adds valuable context: the tool uses a 'Korean network probe' for legacy TLS detection, checks specific security headers, and returns 'per-item pass/warn/fail and an overall grade'. This goes beyond the annotation safety profile and clarifies scope and output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with a front-loaded purpose and an early exclusion note ('no port scanning'). It packs a lot of specific detail into a structured list format without redundant wording, though it is slightly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately discloses the return shape ('per-item pass/warn/fail and an overall grade'). It covers the main checks, the network probe behavior, and output format. It does not discuss error cases or timing, but for a single-parameter read-only tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, domain, is fully described in the schema ('Domain name, e.g. example.com'), giving 100% schema coverage. The description does not add parameter-level detail, but none is needed because the schema already covers it; this meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Security posture check of a web server', then enumerates exactly what is covered (TLS, headers, redirect, certificate strength). It also distinguishes itself from siblings by explicitly excluding port scanning and focusing on posture rather than DNS or certificate-only checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: for a security posture assessment of a web server, including an explicit exclusion of port scanning. It does not name sibling alternatives such as check_certificate for deeper cert details, so it stops short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a TLS/SSL certificate error message from a browser, curl/OpenSSL, Java, Python, Node.js, Go or .NET: likely causes, fixes, and links to step-by-step guides (Korean). Works offline from a curated knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| error | Yes | Full error text, e.g. "PKIX path building failed" or "NET::ERR_CERT_DATE_INVALID" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: it works offline from a curated knowledge base, returns likely causes and fixes, and links to Korean step-by-step guides. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence front-loads the action and then efficiently specifies supported sources, output contents, language, and offline behavior. Every part earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only lookup tool, the description fully covers the input format, output contents, language, and operational constraint. The sibling tools are all checkers, so no additional routing guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the single 'error' parameter with examples. The description adds context about supported error sources but no additional parameter-level constraints or format details, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Explain') and a clear resource ('TLS/SSL certificate error message'), and enumerates the supported source ecosystems. This distinguishes it from sibling tools that check certificates, DNS, or expiry rather than explaining an existing error.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the trigger: when an agent has a TLS/SSL error string, this tool returns causes, fixes, and guides. It does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions, but the input type and offline knowledge-base behavior provide strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe an email address to free daily expiry monitoring of up to 5 domains (certificate, domain registration and security grade) with email alerts, plus an optional Slack/Discord/Telegram/webhook channel. Also alerts when Certificate Transparency logs show a new certificate for a domain from a CA not seen before (possible unauthorized issuance). Double opt-in: a confirmation email is sent and monitoring starts only after the recipient clicks the link; one confirmation email per address per 24 hours. Use only an address the user owns and explicitly asked to use.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address that will receive the alerts | ||
| domains | Yes | Domain names to monitor (host or host:port). For paid certificates you may append the contract (subscription) end date and the DCV method, e.g. "shop.example.com 2027-05-01 email" — contract expiry is alerted with the same thresholds and email DCV gets a reminder (email DCV ends 2028-03-15, CA/B Forum SC-090). A trailing "45/20" sets per-domain WARN/CRITICAL days. | |
| webhook | No | Optional alert channel URL — alerts are also posted there after confirmation. Accepts a Slack or Discord incoming-webhook URL, a Telegram URL https://api.telegram.org/bot<TOKEN>/sendMessage?chat_id=<CHAT_ID>, or any public https endpoint (receives JSON POST, version 1). It is a secret; only pass a URL the user gave you. | |
| critDays | No | Days before expiry that count as CRITICAL "expiring soon" (default 15; must be < warnDays) | |
| warnDays | No | Days before expiry that count as WARN (default 30; the default shrinks for short-lived certificates) | |
| slackWebhook | No | Deprecated alias of webhook that accepts only Slack Incoming Webhook URLs (https://hooks.slack.com/services/...). |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
watch_expiry3 fields changedInput schema / properties / domains / descriptionPrevious value: -"Domain names to monitor (host or host:port). For paid certificates you may append the contract (subscription) end date and the DCV method, e.g. \"shop.example.com 2027-05-01 email\" — contract expiry is alerted with the same thresholds and email DCV gets a reminder (email DCV ends 2028-03-15, CA/B Forum SC-090)."New value: +"Domain names to monitor (host or host:port). For paid certificates you may append the contract (subscription) end date and the DCV method, e.g. \"shop.example.com 2027-05-01 email\" — contract expiry is alerted with the same thresholds and email DCV gets a reminder (email DCV ends 2028-03-15, CA/B Forum SC-090). A trailing \"45/20\" sets per-domain WARN/CRITICAL days."Input schema / properties / slackWebhook / descriptionPrevious value: -"Optional Slack Incoming Webhook URL (https://hooks.slack.com/services/...) — alerts are also posted there after confirmation. It is a secret; only pass a URL the user gave you."New value: +"Deprecated alias of webhook that accepts only Slack Incoming Webhook URLs (https://hooks.slack.com/services/...)."Input schema / properties / webhookAdded value: +{
+ "description": "Optional alert channel URL — alerts are also posted there after confirmation. Accepts a Slack or Discord incoming-webhook URL, a Telegram URL https://api.telegram.org/bot<TOKEN>/sendMessage?chat_id=<CHAT_ID>, or any public https endpoint (receives JSON POST, version 1). It is a secret; only pass a URL the user gave you.",
+ "type": "string"
+}watch_expiry1 field changedInput schema / properties / domains / descriptionPrevious value: -"Domain names to monitor (host or host:port)"New value: +"Domain names to monitor (host or host:port). For paid certificates you may append the contract (subscription) end date and the DCV method, e.g. \"shop.example.com 2027-05-01 email\" — contract expiry is alerted with the same thresholds and email DCV gets a reminder (email DCV ends 2028-03-15, CA/B Forum SC-090)."watch_expiry2 fields changedInput schema / properties / domains / descriptionPrevious value: -"Domain names to monitor"New value: +"Domain names to monitor (host or host:port)"Input schema / properties / slackWebhookAdded value: +{
+ "description": "Optional Slack Incoming Webhook URL (https://hooks.slack.com/services/...) — alerts are also posted there after confirmation. It is a secret; only pass a URL the user gave you.",
+ "type": "string"
+}check_certificate1 field changedInput schema / properties / portAdded value: +{
+ "description": "TLS port (default 443). Implicit TLS: 8443 4443 9443 6443 636 465 993 995 853 5061 3269 8883; STARTTLS: 25 587 (SMTP), 143 (IMAP), 110 (POP3), 389 (LDAP). Or pass domain as host:port",
+ "type": "integer"
+}check_certificate2 fields changedInput schema / properties / critDaysAdded value: +{
+ "description": "Days before expiry that count as CRITICAL \"expiring soon\" (default 15; must be < warnDays)",
+ "maximum": 365,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / warnDaysAdded value: +{
+ "description": "Days before expiry that count as WARN (default 30; the default shrinks for short-lived certificates)",
+ "maximum": 365,
+ "minimum": 1,
+ "type": "integer"
+}check_expiry2 fields changedInput schema / properties / critDaysAdded value: +{
+ "description": "Days before expiry that count as CRITICAL \"expiring soon\" (default 15; must be < warnDays)",
+ "maximum": 365,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / warnDaysAdded value: +{
+ "description": "Days before expiry that count as WARN (default 30; the default shrinks for short-lived certificates)",
+ "maximum": 365,
+ "minimum": 1,
+ "type": "integer"
+}watch_expiry2 fields changedInput schema / properties / critDaysAdded value: +{
+ "description": "Days before expiry that count as CRITICAL \"expiring soon\" (default 15; must be < warnDays)",
+ "maximum": 365,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / warnDaysAdded value: +{
+ "description": "Days before expiry that count as WARN (default 30; the default shrinks for short-lived certificates)",
+ "maximum": 365,
+ "minimum": 1,
+ "type": "integer"
+}check_certificate2 fields changedInput schema / properties / detailAdded value: +{
+ "description": "Include the full certificate chain in the text output (default false)",
+ "type": "boolean"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "headline": {
+ "description": "One-line verdict (Korean)",
+ "type": "string"
+ },
+ "reasons": {
+ "items": {
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "messageEn": {
+ "type": "string"
+ },
+ "severity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "severity"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "description": "UNKNOWN = could not be measured (never treat as OK)",
+ "enum": [
+ "OK",
+ "WARN",
+ "CRITICAL",
+ "UNKNOWN"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "domain",
+ "status",
+ "headline",
+ "reasons"
+ ],
+ "type": "object"
+}check_expiry1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "checkedAt": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "headline": {
+ "description": "One-line verdict (Korean)",
+ "type": "string"
+ },
+ "reasons": {
+ "items": {
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "messageEn": {
+ "type": "string"
+ },
+ "severity": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "severity"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "status": {
+ "description": "UNKNOWN = could not be measured (never treat as OK)",
+ "enum": [
+ "OK",
+ "WARN",
+ "CRITICAL",
+ "UNKNOWN"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "domain",
+ "status",
+ "headline",
+ "reasons"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}check_certificatecheck_dnscheck_dns_propagationcheck_expirycheck_securityexplain_tls_errorwatch_expiryInspect one endpoint's served certificate, expiry, hostname coverage, and accepted TLS versions.
Free SSL/TLS certificate checker: expiry, chain trust, hostname match, TLS version, A/B/C/F grade.
Inspects live IPv4/IPv6 DNS resolution, TLS certificate issuer/expiry, and HTTP security grade.
Monitors TLS/SSL certificate expiry, DNS resolution, and TCP port status for AI agents.
Add one secure layer between your agents and this server.