TLS Configuration Grounding Data

Overview

A TLS checker API for testing a server's TLS version support from code, a cron job or a CI pipeline, with the answer in seconds. TLS Checker connects to the domain and port you give it and runs a separate handshake at each protocol version, so it reports exactly which of TLS 1.0, 1.1, 1.2 and 1.3 are accepted. From the handshake at the highest version it returns the negotiated cipher, whether that cipher has forward secrecy, and whether the certificate validates for the host. It flags deprecated TLS 1.0/1.1, returns a composite risk score, and assigns an A+ to F grade using APIVerve's own documented rubric: TLS 1.2 or newer and a valid certificate are required; TLS 1.0/1.1, or a chosen cipher without forward secrecy or AEAD, caps the grade at B; A+ needs TLS 1.3. It does not enumerate every cipher suite or test for named vulnerabilities, so the grade is not an SSL Labs grade.

Live Test TLS Configuration Grounding Data Source →

The tool

Once your client is connected to the VerveContext server, this appears in its tool list as TLSConfigurationGroundingData. It is read-only and open-world — it fetches and never mutates anything on your side — so most clients call it without asking you to confirm.

{
  "name": "TLSConfigurationGroundingData",
  "arguments": {
    "domain": "amazon.com"
  }
}

You do not name the tool yourself; the model picks it. Asking about amazon.com in the terms this source covers is enough for it to reach for TLSConfigurationGroundingData on its own — naming it explicitly also works, and is the way to force the call.

Connecting

One server URL covers every source in the catalog, including this one. Authorization is OAuth: the client opens a browser once, and there is no key to paste into a config file.

{
  "mcpServers": {
    "vervecontext": {
      "url": "https://api.vervecontext.com/v1/mcp"
    }
  }
}

https://api.vervecontext.com/v1/mcp

Per-client setup — Claude, Cursor, VS Code, ChatGPT — is on the MCP setup page.

Arguments

These are the properties on the tool's inputSchema, so a well-behaved client validates them before the call is made. Premium arguments are accepted on every plan but only take effect on plans that include them.

What the model gets back

The result carries a structuredContent object matching the tool's declared outputSchema, so a client reads fields without parsing prose. status is "ok" and error is null on success; a null field means the value was not available for that input, not that the call failed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "status": "ok",
  "error": null,
  "data": {
    "domain": "amazon.com",
    "tlsVersions": {
      "TLSv1": false,
      "TLSv1.1": false,
      "TLSv1.2": true,
      "TLSv1.3": true
    },
    "highestVersion": "TLSv1.3",
    "negotiatedCipher": "TLS_AES_256_GCM_SHA384",
    "forwardSecrecy": true,
    "certificateTrusted": true,
    "certificateError": null,
    "hasDeprecatedTLS": false,
    "isSecure": true,
    "riskScore": 0,
    "riskLevel": "low",
    "grade": "A+",
    "gradeReasons": []
  }
}

Response fields

Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.

Why ground on it

A model can produce something that looks like this answer from its training data, and be confidently out of date or simply wrong. This source returns the current value in a shape you can check, which is the difference between an answer you can cite and one you have to hedge.

Point an evaluation at highestVersion: it is the field most worth pinning a claim to, and it is either present and current or absent — never plausibly invented.

Failure modes

Errors come back as tool errors carrying a sentence the model can act on, not a bare status code. Error handling covers the full list.

A call costs 2 credits each time the tool actually runs; a model that reasons about the tool without calling it costs nothing.

Use cases

Payment Gateway Auditing

Before onboarding merchant checkout domains, fintech compliance auditors check whether incoming endpoints accept legacy protocols like TLS 1.0 or 1.1.

Deployment Pipeline Verification

Flag outdated web server configurations during production releases by testing handshake support across all modern protocol versions before traffic switches over.

Attack Surface Scanning

Security analysts query customer-facing domains periodically to find legacy protocol support and review the highest negotiable version across exposed web ports.

Vendor Security Assessments

When evaluating SaaS suppliers, procurement teams inspect external hostnames to confirm that partner servers negotiate TLS 1.2 or 1.3.

Other ways to use TLS Configuration Grounding Data

Set up TLS Configuration Grounding Data on VerveContext, or reach the same source a different way. Your VerveContext account and credits work on all of them — one key, one balance.

Related

More in Networking: