CertGuard
Server Details
Free SSL/TLS certificate checker: expiry, chain trust, hostname match, TLS version, A/B/C/F grade.
- Status
- Healthy
- Uptime
- 100.0% over 23 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 1 tool
With only one tool in the set, there is no possibility of misselection or overlap. The description clearly bounds what it does (live TLS handshake + cert audit) and explicitly notes what it does not do (revocation, Cloudflare-fronted hosts).
The single name check_certificate follows a clean verb_noun snake_case convention. There is no competing convention to clash with, so consistency is trivially perfect.
The server's scope is narrow (auditing one host's certificate), so one tool is defensible, but the surface is thin: no batch/multi-host check, no stored result retrieval, and everything is bundled into one opaque call. It sits right at the borderline of 'feels thin' for the domain.
The single tool is internally rich (grade, expiry, chain, TLS version, cipher, key info, findings), but the domain has notable holes: no revocation checking (explicitly stated as missing), no batch/scheduled re-checks, and no way to retrieve or compare prior reports. Agents can work around these by repeating calls, but the surface is not complete.
Available Tools
1 toolcheck_certificateCheck a server's SSL/TLS certificate (expiry, chain, hostname, TLS version)ARead-onlyIdempotentInspect
Run a live TLS handshake against host:port and audit the certificate the server presents. Returns an A/B/C/F grade and summary, expiry (days remaining), hostname match, chain completeness and trust against Mozilla's root store, negotiated TLS version and cipher suite, key type/size, findings, and a link to the full report. Revocation (OCSP/CRL) is NOT checked. Hosts on Cloudflare's own network cannot be checked live (result: isError with code live_check_unavailable, no grade); a failed handshake returns check_failed with no grade. Read-only: it only opens a TLS connection to the public host. Same engine, cache and limits as the CertGuard JSON API (GET /api/v1/check).
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname or public IP to check, e.g. example.com. An https:// URL is accepted and reduced to its host (and port). Private, internal and reserved addresses are rejected. | |
| port | No | TCP port (default 443). Allowed: 443, 8443, 465, 993, 995. | |
| include_raw | No | Also return the full /api/v1/check JSON (all chain certificates, SANs, handshake attempts) in structuredContent.raw. Larger output. |
Output Schema
| Name | Required | Description |
|---|---|---|
| raw | No | Full /api/v1/check response (only when include_raw is true) |
| tls | No | |
| host | Yes | |
| plan | No | |
| port | Yes | |
| chain | No | |
| grade | Yes | |
| apiUrl | No | |
| cached | No | |
| expiry | No | |
| issues | No | |
| source | No | |
| status | Yes | |
| summary | Yes | |
| version | No | |
| hostname | No | |
| checkedAt | No | |
| reportUrl | Yes | |
| notChecked | No | |
| certificate | No | |
| gradeEstimated | No | true when the result was inferred from Certificate Transparency logs instead of a live handshake |
| revocation_checked | Yes | Always false: OCSP/CRL status is not queried |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent, but the description adds substantial context they cannot: the revocation blind spot, the Cloudflare network limitation with its error code, the failure mode and error semantics, and shared cache/limits with the underlying API. This is exactly the behavioral detail an agent needs before invoking.
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?
Dense but front-loaded: what it does, what it returns, then the exceptions and error behavior. Every sentence carries information (exclusions, error codes, shared engine) and none are filler despite the length.
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?
An output schema exists so return values need not be explained, yet the description still gives the error-path contract and the eligibility limits that an agent cannot infer from schema or annotations. Nothing needed to call it correctly is missing.
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 all three parameters carry their own descriptions (host normalization/rejection of private IPs, port enum, include_raw flag), so the schema does the heavy lifting. The description only gestures at 'host:port' without adding format or default detail beyond it.
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?
Opens with a specific verb+resource ('Run a live TLS handshake against host:port and audit the certificate') and enumerates exactly what is audited: grade, expiry, hostname match, chain, TLS version, key type. There is no sibling to confuse it with.
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?
States clear boundaries: revocation is NOT checked, Cloudflare-hosted hosts cannot be checked live, and failures surface as check_failed/live_check_unavailable. No alternatives exist (no siblings), so the remaining gap is only the absence of an explicit when-to-prefer framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
check_certificate
Related MCP Connectors
SSL/TLS scanning, free Let's Encrypt issuance, and certificate-expiry monitoring.
Free SSL/PKI tools: HTTPS audit incl. GM SM2/TLCP, DCV pre-check, CSR, cert decode, P12/JKS.
Free anonymous website, DNS, email and TLS checks, plus monitor read and opt-in write access.
Inspects live IPv4/IPv6 DNS resolution, TLS certificate issuer/expiry, and HTTP security grade.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables live TLS/SSL certificate health checks for any hostname, providing expiry, hostname match, trust verdict, and a health score. Supports both free and paid deep tiers with protocol/cipher analysis.MIT
- AlicenseNot gradedqualityBmaintenanceFree SSL/TLS scanning and Let's Encrypt certificate issuance (private key stays local), plus certificate-expiry monitoring via one MCP server. Public scan and cert tools need no account.3MIT
- AlicenseNot gradedqualityBmaintenanceLets AI assistants check any host's SSL/TLS certificate, reporting expiry, chain trust, hostname match, TLS version, and an A/B/C/F grade. It runs as a remote Streamable HTTP server exposing a single check_certificate tool.MIT
- AlicenseAqualityDmaintenanceEnables checking SSL certificate expiry for any domain, with status indicators for validity and remaining days.1MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.