TLS certificate diagnostics: served-cert expiry, chain, security grade, error explainer, alerts
Scored across 7 tools
Most tools are clearly distinct: check_dns vs check_dns_propagation have different purposes (facts vs propagation), and explain_tls_error/watch_expiry are unique. However, check_certificate, check_expiry, and check_security all touch certificate expiry/key strength, so an agent could conflate their scopes without careful reading.
Five tools follow the clear check_* pattern (check_certificate, check_dns, check_dns_propagation, check_expiry, check_security), while explain_tls_error and watch_expiry break the pattern with different verbs. The deviation is minor and semantically reasonable, but the mix prevents a perfect score.
Seven tools is well-scoped for a certificate/domain health server. Each tool fills a distinct diagnostic or monitoring role without redundancy, and the count is within the ideal 3-15 range.
The surface covers the core workflow well: deep single-domain checks, bulk expiry summaries, DNS propagation verification, security posture, error explanation, and proactive monitoring. Minor gaps exist (e.g., no bulk security check or historical certificate timeline), but they are not likely to cause agent failures for typical certificate management tasks.
Check one domain's TLS certificate in depth: expiry and days left for the certificate the server actually serves (measured from a Korean network, CT logs as fallback), whether a newer certificate exists in CT logs but is not deployed, live TLS verification from a global PoP and from Korea, certificate chain (leaf → intermediates → root), revocation, SAN list, and recent incident history of the issuing CA.
| 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 mark the operation as read-only and non-destructive, so the description earns credit for adding measurement-source context: Korean network, CT-log fallback, global PoP vs. Korea verification, and chain ordering. It does not cover rate limits or failure behavior, but it discloses far more than the annotations alone.
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 main action is front-loaded and the colon-separated list packs many distinct checks into one sentence without filler. It is dense and slightly run-on, but every clause contributes information, so it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter diagnostic tool with no output schema, the enumerated checks effectively tell the agent what results to expect. It does not describe result formatting, ordering, or edge cases like invalid domains, but the annotation set and simple schema keep the remaining gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the only parameter, domain, with an example, and the description adds no syntax, formatting, or validation details beyond that. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Check one domain's TLS certificate in depth') and then enumerates distinct checks such as expiry, CT deployment gaps, live verification, chain, revocation, SAN, and CA incidents. This makes the tool easy to distinguish from siblings like check_expiry or check_dns even without explicit comparisons.
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 detailed scope implies the tool is for deep certificate diagnostics rather than simple expiry checks, but the description never states when to prefer it over siblings such as check_expiry or check_security. There is no explicit when-to-use/when-not-to-use guidance, leaving the agent to infer usage from the feature list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Expiry summary for up to 5 domains at once: served certificate expiry and issuer, undeployed newer certificate in CT logs, domain registration expiry (RDAP), and alert lines (Korean). Use this for inventories and periodic checks.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Domain names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses concrete behaviors: batch size limit, multiple data sources (served certificate, CT logs, RDAP), and the fact that alert lines are Korean. This provides a realistic picture of what the tool returns without contradicting the annotations.
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?
Two sentences with no filler. The first sentence front-loads the core behavior and output scope, and the second provides a practical usage hint. Every part earns its place.
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 one required parameter, safety annotations, and no output schema, the description covers the key details needed to invoke correctly: input limit, output categories, and recommended use case. It leaves little ambiguity for the tool's complexity.
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 schema already fully documents the one parameter, 'domains', including min/max items and a description reading 'Domain names,' so schema coverage is 100%. The description mostly restates the up-to-five limit and adds no new semantic detail beyond the schema's existing coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an expiry summary for up to five domains and enumerates the specific checks performed: served certificate expiry/issuer, CT log certificates, RDAP registration expiry, and Korean alert lines. It is distinct in scope from siblings like check_certificate, though it does not explicitly name alternative tools.
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 explicit usage context: 'Use this for inventories and periodic checks.' This provides clear context, but it does not state when not to use the tool or name alternatives such as watch_expiry for ongoing monitoring.
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. Double opt-in: a confirmation email is sent and monitoring starts only after the recipient clicks the link. 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it discloses the double opt-in flow, that monitoring starts only after the confirmation link is clicked, and the types of monitoring performed. This is valuable since readOnlyHint=false already indicates a side-effecting operation but not its specific 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?
Three sentences with no fluff: the first front-loads the core action and scope, the second explains the opt-in flow, and the third gives the critical usage restriction. Every sentence earns its place and the most decision-relevant information appears early.
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 two-parameter subscription tool with no output schema, the description covers the purpose, the input semantics, the opt-in behavior, and the consent requirement. It does not describe the immediate return value or what happens on duplicate subscription, but these are secondary given the clear description of the side-effecting flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful meaning by explaining what happens to the domains (certificate, registration, and security grade monitoring), the 'up to 5' constraint, and the consent requirement for the email parameter. This goes beyond the schema's simple field 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?
The description states a specific verb ('subscribe') and resource ('an email address ... to free daily expiry monitoring'), and clearly distinguishes this from the check_* siblings by emphasizing ongoing monitoring and email alerts. The parenthetical listing what is monitored further clarifies the tool's scope.
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 when to use this tool: when the user wants ongoing daily monitoring with alerts, as opposed to a one-time check. It includes a strong consent guideline ('Use only an address the user owns and explicitly asked to use'), though it does not explicitly name check_expiry or other alternatives as the contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_certificatecheck_dnscheck_dns_propagationcheck_expirycheck_securityexplain_tls_errorwatch_expirySSL/TLS scanning, free Let's Encrypt issuance, and certificate-expiry monitoring.
Inspect one endpoint's served certificate, expiry, hostname coverage, and accepted TLS versions.
Free anonymous website, DNS, email and TLS checks, plus monitor read and opt-in write access.
Monitors TLS/SSL certificate expiry, DNS resolution, and TCP port status for AI agents.
Add one secure layer between your agents and this server.
