# TLS Radar (remote · tlsradar.com)

SSL/TLS scanning, free Let's Encrypt issuance, and certificate-expiry monitoring.

- Trust score: 67/100 (medium)
- Change this week: +5
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `tlsradar.com`: 67/100 (this document), [markdown](https://verifymcp.io/servers/com-tlsradar-tlsradar/api-v1-mcp.md), [page](https://verifymcp.io/servers/com-tlsradar-tlsradar/api-v1-mcp)

## Channel facts

- Endpoint: `https://tlsradar.com/api/v1/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.5.1`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 66/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (remove_monitor).
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 76/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1893 tokens (~111/item across 17 items; 17 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 20/100
  - Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http com-tlsradar-tlsradar https://tlsradar.com/api/v1/mcp
```

### Codex

```toml
[mcp_servers.com-tlsradar-tlsradar]
url = "https://tlsradar.com/api/v1/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-tlsradar-tlsradar": {
      "type": "remote",
      "url": "https://tlsradar.com/api/v1/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-tlsradar-tlsradar --url https://tlsradar.com/api/v1/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-tlsradar-tlsradar:
    url: "https://tlsradar.com/api/v1/mcp"
```

### Other

```json
{
  "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.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 67, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 66, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 65, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 64, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 63, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 62, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 62)

First indexed and scored.

## MCP tools (17)

### `scan_domain` (~97 tokens)

Run a free, anonymous SSL/TLS scan against a hostname and return certificate details. No account required.

Input parameters:

- `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, required): Hostname to scan (e.g. example.com). No scheme, no path.

Output parameters:

- `domain` (string)
- `expiration_date` (string|null)
- `install_id` (string): Anonymous install id to persist locally and reuse.
- `scanned_at` (string|null)
- `share_token` (string)
- `share_url` (string)
- `status` (string)

### `create_certificate` (~322 tokens)

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.

Input parameters:

- `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, required): Apex domain, no scheme/www (e.g. example.com).
- `email` (string, required): 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.

Output parameters:

- `challenge` (string)
- `dns_records` (array): TXT records to publish for dns-01.
- `domain` (string)
- `http_files` (array): Files to serve for http-01.
- `install_id` (string)
- `next_action` (string)
- `order_id` (string)
- `resume_token` (string): Signed token to finalize past the backend's order TTL.

### `check_certificate_propagation` (~70 tokens)

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.

Input parameters:

- `order_id` (string, required): The order_id from create_certificate.

Output parameters:

- `all_found` (boolean): True when every challenge record/file is in place.
- `records` (array): Per-record propagation status.

### `finalize_certificate` (~375 tokens)

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.

Input parameters:

- `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, required): 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).

Output parameters:

- `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)

### `get_certificate_status` (~59 tokens)

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.

Input parameters:

- `order_id` (string, required): The order_id from create_certificate.

Output parameters:

- `challenge` (string)
- `fullchain_pem` (string): Present once the order is completed.
- `state` (string)

### `renew_certificate` (~111 tokens)

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.

Input parameters:

- `order_id` (string, required): The original order_id to clone. If you don't have one, use create_certificate instead.

Output parameters:

- `challenge` (string)
- `dns_records` (array)
- `http_files` (array)
- `order_id` (string)
- `state` (string)

### `register_beacon_order` (~147 tokens)

OBSOLETE - do not call. The cert→monitoring handoff is server-side now (issue via create_certificate, which records the order itself). This tool is kept only so old plugin versions that still call it don't error; it remains idempotent and harmless.

Input parameters:

- `domain` (string, required): Domain the cert was requested for
- `email` (string, required): Contact email the user gave Beacon
- `order_id` (string, required): The order_id from beacon.create_order
- `webhook_secret` (string): Per-order HMAC secret Beacon returned (used to verify the subsequent webhook). Optional - without it, this server can't verify webhooks for the order and will drop them.

Output parameters:

- `domain` (string)
- `has_webhook_secret` (boolean)
- `order_id` (string)
- `registered` (boolean)

### `get_account` (~28 tokens)

Return the current user's plan, limits, and usage so the client can render upgrade nudges proactively.

Output parameters:

- `email` (string)
- `plan` (object): Plan tier and limits.
- `usage` (object): Current usage against the plan limits.

### `list_monitors` (~80 tokens)

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.

Output parameters:

- `count` (integer)
- `monitors` (array)
- `nudge` (object): Present only when an upgrade nudge is warranted.

### `add_monitor` (~135 tokens)

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.

Input parameters:

- `domain` (string, required): Hostname to monitor (e.g. example.com). No scheme, no path.

Output parameters:

- `address` (string)
- `host_id` (string)
- `scan_group_id` (string)
- `team_id` (string)

### `add_monitors` (~55 tokens)

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.

Input parameters:

- `domains` (array, required): List of hostnames to monitor

Output parameters:

- `added` (integer)
- `requested` (integer)
- `results` (array): Per-domain add status.
- `scan_group_id` (string)
- `team_id` (string)

### `remove_monitor` (~55 tokens)

Stop monitoring a domain. Accepts the domain name or the host_id returned by list_monitors.

Input parameters:

- `domain` (string): Domain to stop monitoring
- `host_id` (string): UUID of the host (alternative to domain)

Output parameters:

- `removed_address` (string)

### `list_expiring_certificates` (~93 tokens)

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.

Input parameters:

- `within` (integer): Days from now to look ahead

Output parameters:

- `count` (integer)
- `entries` (array)
- `nudge` (object): Present only when an upgrade nudge is warranted.
- `within_days` (integer)

### `get_scan_history` (~62 tokens)

Return recent scan results for a domain the user monitors. Useful for spotting issuer changes, grade drops, or vulnerability appearances over time.

Input parameters:

- `domain` (string, required): Domain name as it appears in list_monitors
- `limit` (integer): Max results to return

Output parameters:

- `count` (integer)
- `domain` (string)
- `results` (array)

### `export_monitors` (~41 tokens)

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.

Output parameters:

- `exported_at` (string)
- `teams` (array)
- `version` (string)

### `import_monitors` (~69 tokens)

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.

Input parameters:

- `payload` (object, required): Export payload, version 1.0. Use the `export` tool to generate one.

Output parameters:

- `added` (integer)
- `requested` (integer)
- `results` (array): Per-domain import status.

### `invite_team_member` (~94 tokens)

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).

Input parameters:

- `email` (string, required): 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

Output parameters:

- `invited_email` (string)
- `role` (string)
- `team_id` (string)
- `team_name` (string)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-tlsradar-tlsradar/api-v1-mcp#diagnostics

## Score history

- 2026-08-03: 67
- 2026-08-02: 66
- 2026-08-01: 66
- 2026-07-31: 65
- 2026-07-30: 64
- 2026-07-29: 64
- 2026-07-28: 63
- 2026-07-27: 62
- 2026-07-26: 62

## Links

- Remote endpoint: https://tlsradar.com/api/v1/mcp
- Repository: https://github.com/TLS-Radar/tlsradar-claude-plugin
- Website: https://tlsradar.com/cli
- Changelog RSS feed: https://verifymcp.io/servers/com-tlsradar-tlsradar/api-v1-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-tlsradar-tlsradar/api-v1-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/com-tlsradar-tlsradar/api-v1-mcp