Skip to main content
Glama
Jambozx

OnlineCyberTools MCP (280+ filterable tools)

network_ssl_certificate

Fetch and parse the live TLS certificate chain from a host:port to inspect subject, issuer, validity, expiry, SANs, fingerprints, and security analysis.

Instructions

SSL/TLS Certificate Checker. Fetches and parses the live TLS certificate chain from a host:port by opening an outbound SSL socket to it, then reports the leaf certificate's subject, issuer, validity window, expiry countdown, SANs, fingerprints, signature algorithm, public key, the presented chain, and a security analysis. Use this to inspect a server's actual served certificate (including self-signed or expired ones — peer verification is intentionally disabled, so tls_verified is always false and this is not a trust decision); use network_website_status_checker for HTTP status and response time, network_dns_lookup for DNS records, and network_whois for domain registration. Makes a real network connection to the target (hostname is pinned to a resolved public IP for SSRF safety; private, loopback, and reserved addresses are rejected), so results reflect the host's current certificate. CAPTCHA-gated and rate-limited (anonymous 5/min, 30/hour, 100/day). Key output includes days_until_expiry and expiry_status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostnameYesHostname to fetch the certificate from, no scheme or path, e.g. example.com. Must resolve to a public IP.
portNoTLS port to connect to. Defaults to 443.
worker_idNoOptional registered healthy worker peer ID. Omit to use the default master-server behavior.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
successNoTrue when the certificate was fetched and parsed.
hostnameNoThe hostname that was queried, echoed back.
resolved_ipNoThe public IP the TLS socket was pinned to.
portNoThe TLS port that was connected to.
tls_verifiedNoAlways false — peer verification is intentionally disabled so invalid certs can still be inspected. Not a trust decision.
timestampNoServer-side inspection time, Y-m-d H:i:s.
certificateNoParsed leaf certificate fields.
validationNoExpiry and weakness checks on the leaf certificate.
security_analysisNoHeuristic grading of key exchange, cipher strength, protocol support, and certificate transparency.
errorNoPresent when success is false — the validation or connection failure reason.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond annotations by detailing that it makes a real network connection, is CAPTCHA-gated and rate-limited, pins hostnames to public IPs for SSRF safety, rejects private addresses, and always sets tls_verified to false. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: starts with the main action, then caveats, usage guidance, and security/rate-limit info. Every sentence is valuable, though slightly verbose in listing all output fields. Still, it remains readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (3 params, full schema, output schema present), the description is very complete: explains behavior, security, rate limits, sibling differentiation, and key output fields like days_until_expiry and expiry_status. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3. The description adds meaning by explaining that hostname must resolve to a public IP, port defaults to 443, and worker_id is optional for custom behavior. It also ties parameter use to the tool's security model.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly names the tool as an SSL/TLS Certificate Checker, specifies the action (fetches and parses live TLS certificate chain), and distinguishes it from siblings like network_website_status_checker, network_dns_lookup, and network_whois.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use (inspect a server's actual served certificate) and when-not-to-use (not for HTTP status, DNS, or whois) with specific sibling names. Also warns that peer verification is disabled, so it's not for trust decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jambozx/onlinecybertools-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server