TL;DR: `Connection refused` with Milvus is usually the wrong scheme or port in `MILVUS_URI`. Local Docker Milvus is the service URL for that host and port. Zilliz Cloud is `https://`. Match the URI to the deployment.

```text
Connection refused (Milvus)
```

(With `MILVUS_URI` set to a mismatched scheme or port.)

## Fix it

1. Identify your deployment:
   - Local Docker: the service URL for that host and port (plaintext, port 19530).
   - Zilliz Cloud: the service URL for that host and port or the exact endpoint from the dashboard.

2. Set it correctly:

```json
{
  "env": {
    "MILVUS_URI": "http://YOUR_MILVUS_HOST:19530"
  }
}
```

3. Restart the MCP client and validate with the list-collections tool.

   Expected: connection succeeds.

## When to use this

- Connection refused and the URI mixes `https://` with port 19530, or `http://` with a cloud endpoint.
- It worked locally and broke when pointed at Cloud (or vice versa).

## When NOT to use this

- Permission denied with a good connection. That is the token, not the URI.
- Timeout with the right URI. Firewall or routing.

## Compatibility

- zilliztech/mcp-server-milvus.
- Self-hosted Milvus, Zilliz Cloud.

## Why it happens

Milvus serves plaintext gRPC on 19530 and TLS on the cloud endpoints. The scheme and port are a pair; mixing them points the client at a listener that speaks the other protocol, and the handshake dies as connection refused rather than a helpful message.

## Edge cases

- Some self-hosted setups enable TLS on 19530. Then use `https://` with that port and the right CA.
- Copy the cloud endpoint verbatim from the dashboard. Guessing the hostname pattern fails when regions differ.
- Docker: from inside a container, `YOUR_HOST` is the container. Use `host.YOUR_HOST` or the service name.