TL;DR: Your cluster speaks HTTPS but the MCP server is talking plain HTTP. Change `ES_URL` from `http://` to `https://`. One character class of fix.

```text
received plaintext http traffic on an https channel, closing connection
```

## Fix it

1. Check the scheme in your MCP server config:

```json
{
  "env": {
    "ES_URL": "your-cluster"
  }
}
```

2. Change it to the service URL for that host and port. Keep the port (9200 is the HTTPS port for Elasticsearch).

3. Restart the MCP client.

   Expected: the plaintext error is gone. Next you will likely hit cert verification or 401, which are separate, fixable steps.

## When to use this

- The error is exactly `received plaintext http traffic on an https channel`.
- The cluster was set up with security/TLS enabled (Elasticsearch 8 default, Elastic Cloud, docker with certs).

## When NOT to use this

- The cluster is plain HTTP (older setups, `xpack.security.enabled=false`). Then `http://` is correct and something else is wrong.
- The error is a certificate verification failure. The scheme is already right; trust the CA.

## Compatibility

- elastic/mcp-server-elasticsearch.
- Elasticsearch 8.x, Elastic Cloud, any TLS-enabled cluster.

## Why it happens

Elasticsearch 8 enables TLS by default. Configs written for older plain-HTTP clusters get copied forward, and the `http://` URL survives the upgrade. The server opens a plaintext connection, Elasticsearch sees non-TLS bytes on a TLS port and drops it with this distinctive message.

## Edge cases

- Some proxies terminate TLS and forward HTTP internally. Then the MCP server's URL should match what the proxy expects, not the cluster.
- Port 9200 is HTTPS when security is on. If your setup uses a different port for TLS, use that.
- After fixing the scheme, expect the self-signed cert error next on self-hosted clusters. That is the normal sequence: scheme, then trust, then auth.