Check SSL/TLS certificate expiry for one or more domains and warn when certificates expire soon to prevent service outages.
Check certificate expiry for one or more domains and highlight certificates expiring soon
| Name | Required | Description | Default |
|---|---|---|---|
| hosts | Yes | Domain names to check | |
| warnDays | No | Warn if expiring within this many days (default: 30) |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that certificates expiring soon are 'highlighted' but says nothing about the network operations implied (live TLS handshakes/connections), timeouts, rate limits, failure handling for unreachable hosts, or whether any state is persisted. For an external-network probe tool this is a meaningful gap.
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?
A single efficient sentence with the primary action front-loaded and no filler. It is not bloated, but the brevity comes at the cost of the missing behavioral and routing detail noted elsewhere.
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 simple (2 params, no nesting, no output schema, no annotations), and the description covers the core purpose, but it omits expected output shape (e.g., per-host expiry dates/statuses) and any failure-mode context. Adequate minimum viability, not complete.
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% (hosts: 'Domain names to check'; warnDays: 'Warn if expiring within this many days (default: 30)'), so the baseline is 3. The description adds only mild confirmation via 'one or more domains' and 'expiring soon', which loosely map to hosts and warnDays but add no format or unit detail.
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 (certificate expiry) plus a secondary behavior (highlight certificates expiring soon), so an agent can tell what it returns. However, it does nothing to distinguish itself from the sibling ssl_inspector tools inspect_ssl, inspect_ssl_bulk, and get_cert_info, which likely overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no mention of when not to use it, and no reference to the sibling tools that also inspect SSL/certificates. The agent must infer from the name alone whether to call this versus inspect_ssl or get_cert_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.