Milvus MCP: permission denied on Zilliz Cloud (set MILVUS_TOKEN)

TL;DR: Zilliz Cloud and secured Milvus need a token on every request. Set MILVUS_TOKEN in the MCP server's environment (alongside MILVUS_URI). Local dev Milvus without auth is the only setup that works without it.

Permission denied / authentication failed (Milvus)

Fix it

1. Get the token - Zilliz Cloud dashboard for cloud clusters (root:password style or a revocable API key), or your Milvus auth config for self-hosted.

1. Set it in the MCP client config env block:

{
  "env": {
    "MILVUS_URI": "https://your-cluster.zillizcloud.com:19540",
    "MILVUS_TOKEN": "your-token",
    "MILVUS_DB": "default"
  }
}

1. Validate with the list-collections tool. Any non-error response (even an empty list) proves the connection is live.

1. Restart the MCP client if you changed the config.

Expected: permission errors gone, tools work.

When to use this

• Permission denied or auth failures against Zilliz Cloud or auth-enabled self-hosted Milvus.
• The same URI works from a client where you did pass the token.

When NOT to use this

• Connection refused or timeout. The server is unreachable; auth is not the issue yet.
• Plain local Milvus without auth enabled. No token is needed there.

Compatibility

• zilliztech/mcp-server-milvus (MILVUSURI / MILVUSTOKEN / MILVUS_DB env config).
• Zilliz Cloud, self-hosted Milvus with authentication.

Why it happens

Milvus auth is all-or-nothing per deployment: either the instance accepts anonymous clients (local dev) or every request needs credentials. MCP configs copied from local dev carry the URI but no token, and the first secured deployment fails on every tool.

Edge cases

• Token format matters: root:Milvus style vs API key depends on how auth was configured. Match the format your deployment expects.
• Rotated tokens need a client restart. The server reads env once at startup.
• For Zilliz Cloud, the URI is https:// on port 19540 (or the endpoint shown in the dashboard). The token alone does not fix a wrong URI.