TLS Radar
REMOTE · TLSRADAR.COM · SCANNED SEP 24
SSL/TLS scanning, free Let's Encrypt issuance, and certificate-expiry monitoring.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security66
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (remove_monitor). See how to fix → View diagnostics → Fail
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC is configured correctly; the domain's records validate against the full chain to the root. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability78
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 1746 tokens (~109/item across 16 items; 16 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management93
- Stability check failed: schema churn in the 30 days we've observed: 1 tool removals, 0 breaking changes, 0 auth/transport breaks, 0 additions. See how to fix → Fail
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 16 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities20
- Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28. See how to fix → Fail
How do I install the TLS Radar MCP server?
TLS Radar is a hosted endpoint at https://tlsradar.com/api/v1/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · tlsradar.com
claude mcp add --transport http com-tlsradar-tlsradar 'https://tlsradar.com/api/v1/mcp'
{
"mcpServers": {
"com-tlsradar-tlsradar": {
"url": "https://tlsradar.com/api/v1/mcp"
}
}
} {
"servers": {
"com-tlsradar-tlsradar": {
"type": "http",
"url": "https://tlsradar.com/api/v1/mcp"
}
}
} [mcp_servers.com-tlsradar-tlsradar] url = "https://tlsradar.com/api/v1/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"com-tlsradar-tlsradar": {
"type": "remote",
"url": "https://tlsradar.com/api/v1/mcp",
"enabled": true
}
}
} openclaw mcp add com-tlsradar-tlsradar --url 'https://tlsradar.com/api/v1/mcp' --transport streamable-http
mcp_servers:
com-tlsradar-tlsradar:
url: "https://tlsradar.com/api/v1/mcp" {
"McpServers": {
"com-tlsradar-tlsradar": {
"Transport": "http",
"Url": "https://tlsradar.com/api/v1/mcp"
}
}
} assistant mcp add com-tlsradar-tlsradar -t streamable-http -u 'https://tlsradar.com/api/v1/mcp'
{
"mcpServers": {
"com-tlsradar-tlsradar": {
"type": "http",
"url": "https://tlsradar.com/api/v1/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 14 Sept 26 −1
- Stability: pass → fail ▼ security
- A breaking change shipped without a version bump: still 1.0 ▼ security
- Tool “register_beacon_order” was removed ▼ security
- 26 Aug 26 79
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 25 Aug 26 0
- Stability: 0.97 → pass security
- 11 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 31 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 30 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 0
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 24 Sept 2026 · Probed https://tlsradar.com/api/v1/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=tlsradar.com | CN=WE1,O=Google Trust Services,C=US | 14 Sept 2026 | 13 Dec 2026 | ECDSA 256 | ECDSA-SHA256 | 1f1bbb908810a81913d44d067246e2d5 |
| SANs: tlsradar.com, mta-sts.tlsradar.com, *.mta-sts.tlsradar.com | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC secure
Validation of tlsradar.com. — Secure
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| tlsradar.com. | present | 2371 | 13 | Verified |
| tlsradar.com. | Verified address RRset verified with the apex keys |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000; includeSubDomains |
| content-security-policy | default-src 'self'; script-src 'self' 'strict-dynamic' https://challenges.cloudflare.com 'nonce-8uiuCEIIbOExZ9JvcvH6Mw=='; style-src 'self' 'unsafe-inline'; font-src 'self' data:; img-src 'self' data: https:; connect-src 'self' https://api.stripe.com https://challenges.cloudflare.com https://us.i.posthog.com https://us-assets.i.posthog.com https://*.googletagmanager.com https://*.google-analytics.com https://*.analytics.google.com; frame-src https://js.stripe.com https://hooks.stripe.com https://challenges.cloudflare.com; frame-ancestors 'self'; object-src 'none'; form-action 'self' https://checkout.stripe.com https://accounts.google.com https://github.com https://www.facebook.com https://login.microsoftonline.com; base-uri 'self'; upgrade-insecure-requests |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |
| referrer-policy | strict-origin-when-cross-origin |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://tlsradar.com/api/v1/mcp | Verified | 200 | |
| http (plaintext) | http://tlsradar.com/api/v1/mcp | HTTPS enforced | 301 | https://tlsradar.com/api/v1/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
add_monitor ~135
Add a domain to ongoing certificate monitoring with expiry alerts. Requires authentication (the user runs /mcp once). If the plan's monitor limit is reached, the response's structuredContent carries a limit-reached payload - when relaying it, LEAD with `recommended_upgrade` (typically Starter, $9.99/mo), mention `also_available` tiers in a single closing line, and offer removing an existing monitor as the free alternative. Don't dump a full tier comparison; that's choice paralysis at the moment of action.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Hostname to monitor (e.g. example.com). No scheme, no path. |
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | – | – |
| host_id | string | – | – |
| scan_group_id | string | – | – |
| team_id | string | – | – |
No examples provided.
add_monitors ~55
Add multiple domains to monitoring in one call. Returns a per-domain status so the caller can show partial-success outcomes. Honors the same plan-limit checks as add_monitor.
| Name | Type | Req | Description |
|---|---|---|---|
| domains | array | yes | List of hostnames to monitor |
| Name | Type | Req | Description |
|---|---|---|---|
| added | integer | yes | – |
| requested | integer | yes | – |
| results | array | yes | Per-domain add status. |
| scan_group_id | string | – | – |
| team_id | string | – | – |
No examples provided.
check_certificate_propagation ~70
Check whether the DNS TXT records for a certificate order have propagated (Cloudflare/Google/Quad9). Step 2 of issuance - poll until all_found is true, then call finalize_certificate. Returns per-record resolver results.
| Name | Type | Req | Description |
|---|---|---|---|
| order_id | string | yes | The order_id from create_certificate. |
| Name | Type | Req | Description |
|---|---|---|---|
| all_found | boolean | – | True when every challenge record/file is in place. |
| records | array | – | Per-record propagation status. |
No examples provided.
create_certificate ~322
Start issuing a FREE 90-day Let's Encrypt certificate for a domain (no account required). Step 1 of 3. Pick a validation method with `challenge`: "dns-01" (default; publish a TXT record; covers apex + www) or "http-01" (serve a file over HTTP on port 80; issues the exact domain only). dns-01 with a DNS-provider API token is the most automatable; http-01 suits a server you control on port 80. Returns an order_id plus either dns_records (dns-01) or http_files (http-01) to put in place. Next: poll `check_certificate_propagation` until all_found, then call `finalize_certificate`. Strongly prefer the CSR path at finalize (the private key never leaves the user's machine). Issuing automatically offers the user ongoing monitoring by email once it completes - don't add a monitor manually afterward.
| Name | Type | Req | Description |
|---|---|---|---|
| challenge | string | – | Validation method: dns-01 (default) or http-01. |
| client_id | string | – | Optional anonymous install id from ~/.config/tlsradar/install_id (funnel attribution). If omitted, the response's install_id is a fresh one to save there. |
| domain | string | yes | Apex domain, no scheme/www (e.g. example.com). |
| string | yes | Contact email for Let's Encrypt expiry notices and the monitoring handoff. | |
| marketing_consent | boolean | – | Only true if the user explicitly opts in to a free account + reminder email. Default false. |
| Name | Type | Req | Description |
|---|---|---|---|
| challenge | string | yes | – |
| dns_records | array | – | TXT records to publish for dns-01. |
| domain | string | yes | – |
| http_files | array | – | Files to serve for http-01. |
| install_id | string | – | – |
| next_action | string | – | – |
| order_id | string | yes | – |
| resume_token | string | – | Signed token to finalize past the backend's order TTL. |
No examples provided.
export_monitors ~41
Dump the user's monitors as a JSON structure suitable for backup, migration, or infrastructure-as-code workflows. Tokens and PII are NEVER included - only domain configuration.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| exported_at | string | yes | – |
| teams | array | yes | – |
| version | string | yes | – |
No examples provided.
finalize_certificate ~375
Finalize and issue a certificate order in one call: validates the DNS challenges, waits for Let's Encrypt, and returns the issued cert. Step 3 of issuance - call after check_certificate_propagation reports all_found. STRONGLY PREFER passing csr_pem (generate the key + CSR locally with openssl so the private key never leaves the machine). Returns leaf_pem/chain_pem/fullchain_pem. If you must, pass a passphrase instead to get a PKCS#12 bundle - but a CSR is safer. If it replies "still validating", DNS hasn't fully propagated: re-check check_certificate_propagation and call again. Needs a locally-generated CSR (csr_pem) - requires a local shell with openssl. On a surface without one (e.g. a Claude.ai custom connector) this can't complete; it returns guidance to finish in Claude Code/Cowork or the web form. Scanning and monitoring work everywhere. On success the structuredContent carries a `handoff` object - relay `handoff.message` to the user and do NOT separately call add_monitor; the cert→monitoring handoff is automatic and server-side.
| Name | Type | Req | Description |
|---|---|---|---|
| csr_pem | string | – | PEM CERTIFICATE REQUEST covering exactly {domain, www.domain}. Preferred - key stays local. |
| max_wait_seconds | integer | – | How long to wait for validation server-side. Default 60, capped at 75. |
| order_id | string | yes | The order_id from create_certificate. |
| passphrase | string | – | Fallback only: ≥8 chars, protects a returned PKCS#12 bundle. Omit when using csr_pem. |
| resume_token | string | – | Optional. The resume_token from create_certificate; pass it to finalize an order whose row Beacon already purged (~24h). |
| Name | Type | Req | Description |
|---|---|---|---|
| chain_pem | string | – | – |
| fullchain_pem | string | – | Full certificate chain (PEM), present on success. |
| handoff | object | – | Cert->monitoring handoff; relay handoff.message and do not call add_monitor. |
| leaf_pem | string | – | – |
| mode | string | – | – |
| not_after | string | – | – |
| state | string | – | – |
No examples provided.
get_account ~28
Return the current user's plan, limits, and usage so the client can render upgrade nudges proactively.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| string | yes | – | |
| plan | object | – | Plan tier and limits. |
| usage | object | – | Current usage against the plan limits. |
No examples provided.
get_certificate_status ~59
Return the current state of a certificate order (dns_pending, validating, ready, completed, failed) and per-authorization Let's Encrypt statuses. Use it to resume an interrupted issuance.
| Name | Type | Req | Description |
|---|---|---|---|
| order_id | string | yes | The order_id from create_certificate. |
| Name | Type | Req | Description |
|---|---|---|---|
| challenge | string | – | – |
| fullchain_pem | string | – | Present once the order is completed. |
| state | string | – | – |
No examples provided.
get_scan_history ~62
Return recent scan results for a domain the user monitors. Useful for spotting issuer changes, grade drops, or vulnerability appearances over time.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Domain name as it appears in list_monitors |
| limit | integer | – | Max results to return |
| Name | Type | Req | Description |
|---|---|---|---|
| count | integer | yes | – |
| domain | string | yes | – |
| results | array | yes | – |
No examples provided.
import_monitors ~69
Create monitors from a JSON structure (typically produced by `export`). Skips domains the user is already monitoring; honors the plan's domain limit. Returns a per-domain status.
| Name | Type | Req | Description |
|---|---|---|---|
| payload | object | yes | Export payload, version 1.0. Use the `export` tool to generate one. |
| Name | Type | Req | Description |
|---|---|---|---|
| added | integer | – | – |
| requested | integer | – | – |
| results | array | – | Per-domain import status. |
No examples provided.
invite_team_member ~94
Invite a user to a team by email. Defaults to the user's current team. Honors the plan's seat limit (returns the same upgrade payload as add_monitor when the cap is hit).
| Name | Type | Req | Description |
|---|---|---|---|
| string | yes | Email address of the person to invite | |
| role | string | – | Invitee role: guest or admin. Defaults to guest. |
| team_id | string | – | Team UUID; defaults to the current team |
| Name | Type | Req | Description |
|---|---|---|---|
| invited_email | string | yes | – |
| role | string | yes | – |
| team_id | string | yes | – |
| team_name | string | – | – |
No examples provided.
list_expiring_certificates ~93
Return monitored certificates expiring within N days. Defaults to 30. If the response's structuredContent includes a `nudge` object, the user is watching enough soon-to-expire certs to benefit from a higher tier - mention it casually ONCE (lead with `nudge.recommended_upgrade`); skip it if it doesn't fit.
| Name | Type | Req | Description |
|---|---|---|---|
| within | integer | – | Days from now to look ahead |
| Name | Type | Req | Description |
|---|---|---|---|
| count | integer | yes | – |
| entries | array | yes | – |
| nudge | object | – | Present only when an upgrade nudge is warranted. |
| within_days | integer | yes | – |
No examples provided.
list_monitors ~80
List all certificates currently being monitored across the user's teams. If the response's structuredContent includes a `nudge` object, the user is at their monitor cap - surface it casually ONCE (lead with `nudge.recommended_upgrade`, mention `nudge.also_available` in one closing line); don't force it if it doesn't fit the conversation.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| count | integer | yes | – |
| monitors | array | yes | – |
| nudge | object | – | Present only when an upgrade nudge is warranted. |
No examples provided.
remove_monitor ~55
Stop monitoring a domain. Accepts the domain name or the host_id returned by list_monitors.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | – | Domain to stop monitoring |
| host_id | string | – | UUID of the host (alternative to domain) |
| Name | Type | Req | Description |
|---|---|---|---|
| removed_address | string | yes | – |
No examples provided.
renew_certificate ~111
Renew a certificate by cloning a recent order (requires the original order_id; Beacon purges orders after ~24h). Returns a new order_id and fresh DNS TXT records - then poll check_certificate_propagation and call finalize_certificate. If you don't have an order_id (the usual case at 90-day renewal time), call create_certificate for the domain instead; that IS the renewal.
| Name | Type | Req | Description |
|---|---|---|---|
| order_id | string | yes | The original order_id to clone. If you don't have one, use create_certificate instead. |
| Name | Type | Req | Description |
|---|---|---|---|
| challenge | string | – | – |
| dns_records | array | – | – |
| http_files | array | – | – |
| order_id | string | – | – |
| state | string | – | – |
No examples provided.
scan_domain ~97
Run a free, anonymous SSL/TLS scan against a hostname and return certificate details. No account required.
| Name | Type | Req | Description |
|---|---|---|---|
| client_id | string | – | Optional anonymous install id from ~/.config/tlsradar/install_id. Pass it for funnel attribution. If you omit it, the response's install_id is a fresh one to save there. |
| domain | string | yes | Hostname to scan (e.g. example.com). No scheme, no path. |
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| expiration_date | string|null | – | – |
| install_id | string | – | Anonymous install id to persist locally and reuse. |
| scanned_at | string|null | – | – |
| share_token | string | yes | – |
| share_url | string | yes | – |
| status | string | yes | – |
No examples provided.
What is the TLS Radar MCP server?
TLS Radar is an MCP server listed in the public MCP registry as com.tlsradar/tlsradar. SSL/TLS scanning, free Let's Encrypt issuance, and certificate-expiry monitoring. This page covers its hosted endpoint (https://tlsradar.com/api/v1/mcp).
Is the TLS Radar MCP server safe to use?
TLS Radar scores 78 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the TLS Radar MCP server expose?
TLS Radar exposes 16 tools: scan_domain, create_certificate, check_certificate_propagation, finalize_certificate, get_certificate_status, and 11 more. Their descriptions and schemas cost roughly 1,746 tokens of context every time the server is loaded.
Does the TLS Radar MCP server require authentication?
No. We connected to TLS Radar without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.
Is the TLS Radar MCP server still maintained?
TLS Radar is still listed as active in the MCP registry. We last reached this channel on 24 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.