Elasticsearch MCP: plaintext http on an https channel (ES_URL must use the https scheme)

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.

received plaintext http traffic on an https channel, closing connection

Fix it

1. Check the scheme in your MCP server config:

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

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

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