Qdrant MCP: 401 Unauthorized (set QDRANT_API_KEY for key-protected Qdrant)

Not specified by the original author.

TL;DR: HTTP 401 from Qdrant means the instance requires an API key and the MCP server is not sending one. Set QDRANT_API_KEY in the client config env block next to QDRANT_URL. Qdrant Cloud always needs this.

HTTP 401 Unauthorized

(From the Qdrant instance, surfaced through the MCP server's tools.)

Fix it

1. Confirm the key requirement. Test with curl:

curl -H "api-key value YOUR_KEY" https://your-cluster.qdrant.io:6333/collections

Expected: JSON. Without the header you get 401, proving the key is required.

2. Get the API key: Qdrant Cloud dashboard for cloud clusters, or the value of QDRANT__SERVICE__API_KEY for self-hosted.
3. Set it in the client config:

{
  "mcpServers": {
    "qdrant": {
      "env": {
        "QDRANT_URL": "https://your-cluster.qdrant.io:6333",
        "QDRANT_API_KEY": "your-api-key-here"
      }
    }
  }
}

4. Restart the MCP client.

   Expected: 401 is gone, tools work.

When to use this

• Tools fail with 401 or Unauthorized against Qdrant Cloud or a key-protected self-hosted instance.
• The curl test without the key also 401s.

When NOT to use this

• The error is connection refused. Qdrant is not reachable at all.
• Local Qdrant without a key set. Then no key is needed; check the URL.

Compatibility

• qdrant/mcp-server-qdrant and Qdrant-backed MCP servers that honor QDRANTAPIKEY.
• Qdrant Cloud, self-hosted Qdrant with QDRANTSERVICEAPI_KEY.

Why it happens

Qdrant's API key gate rejects every keyless request with 401. MCP servers that predate key support (or configs copied from keyless local setups) send nothing, so everything 401s. Qdrant Cloud always requires a key, which surprises people moving from local Docker.

Edge cases

• The key travels as the api-key header. It is never logged by well-behaved servers, but do not paste it into chats anyway.
• Sending a key over plain http:// triggers a client warning. Use https:// for key-protected instances.
• If you set the key server-side, the /collections healthcheck also needs it. Use /readyz for unauthenticated health checks.

The code-index-mcp commit feat(qdrant): send QDRANTAPIKEY to server-mode Qdrant (consiliency/code-index-mcp) documents this exact failure: a Qdrant server started with QDRANTSERVICEAPIKEY rejects every request without the key, and the MCP server had no way to send one, so server mode got HTTP 401. The fix was reading QDRANTAPIKEY and passing it to every URL-mode QdrantClient, with a 401/403 suggesting the user set QDRANTAPIKEY. The workspace-qdrant-mcp troubleshooting guide documents the same: Unauthorized or 403 Forbidden with Qdrant Cloud, fixed by setting QDRANTAPI_KEY. Sources: https://github.com/consiliency/code-index-mcp/commit/bf7782377596002ba7f342b8f0c39e10bd0e0de0 and https://github.com/chrisgve/workspace-qdrant-mcp/blob/HEAD/docs/TROUBLESHOOTING.md

Not specified by the original author.

TL;DR: Weaviate Cloud requires an API key and your MCP server is not sending one. Set WEAVIATE_API_KEY in the server's environment alongside WEAVIATE_URL. Local Docker Weaviate does not need this, which is why the same config breaks when you move to Cloud.

401 Unauthorized

(From Weaviate Cloud, surfaced through the MCP server's tools.)

Fix it

1. In the Weaviate Cloud dashboard, create an API key for your cluster. Copy it.
2. Set both variables in the MCP client config env block:

{
  "env": {
    "WEAVIATE_URL": "https://your-cluster.weaviate.cloud",
    "WEAVIATE_API_KEY": "your-weaviate-api-key"
  }
}

3. Restart the MCP client.

   Expected: 401 is gone, collection tools work.

When to use this

• Tools fail with 401 against a *.weaviate.cloud URL.
• The same config works against local Docker Weaviate.

When NOT to use this

• Local Docker Weaviate with auth disabled. No key is needed; check the URL.
• Connection refused or timeout. The instance is unreachable.

Compatibility

• weaviate/mcp-server-weaviate and Weaviate-backed MCP servers.
• Weaviate Cloud.

Why it happens

Weaviate Cloud mandates API key auth on every request. Local Docker images ship with auth off for convenience. Configs migrate from local to Cloud carrying only the URL, and the missing key produces a bare 401 with no hint about what to set.

Edge cases

• The Cloud URL is https://. Plain http:// fails differently.
• API keys are per-cluster. A key for cluster A does not work on cluster B.
• If you enabled auth on self-hosted Weaviate (APIKEY auth), the same variable applies. Check how your server maps it.

The weaviate-cloud secure coding rules (tikitribe/claude-secure-coding-rules rules/rag/vector-managed/weaviate-cloud/CLAUDE.md) show the correct Weaviate Cloud connection pattern: weaviate.connecttoweaviatecloud with clusterurl from WEAVIATEURL and authcredentials=AuthApiKey from WEAVIATEAPIKEY. Weaviate Cloud requires API key authentication; without the key the server gets 401 Unauthorized. Local Docker Weaviate typically runs without auth, which is why configs copied from local setups break against Cloud. Source: https://github.com/tikitribe/claude-secure-coding-rules/blob/HEAD/rules/rag/vector-managed/weaviate-cloud/CLAUDE.md

Not specified by the original author.

TL;DR

Implemented and closed as completed via bounty PR #2979. Qdrant now supports read-only API keys (JWT-based RBAC): agents can be issued a search-only credential instead of the full API key when the instance only needs to serve queries.

The error

Feature request: an API key that only allows read operations (search, scroll, get-point, recommend, list collections) so a Qdrant instance can be safely exposed for search-only workloads without reverse-proxy hacks.

Fix

1. Implemented and closed as completed via bounty PR #2979.
2. Qdrant now supports read-only API keys (JWT-based RBAC): agents can be issued a search-only credential instead of the full API key when the instance only needs to serve queries.

Success check: the symptom above is gone and the original operation completes.

When to use

• You hit this exact symptom in qdrant.
• You want the verified fix without digging through the thread.

When not to use

• A different error in qdrant, even a similar-looking one.
• General qdrant setup or credential questions.

Compatibility

• Qdrant (qdrant/qdrant)

Variant phrasings

• How to fix "read-only API key" in qdrant
• qdrant: read-only API key

Source

• https://github.com/qdrant/qdrant/issues/1959

In gh:qdrant/qdrant#1959 (https://github.com/qdrant/qdrant/issues/1959), the question was: Feature request: an API key that only allows read operations (search, scroll, get-point, recommend, list collections) so a Qdrant instance can be safely exposed for search-only workloads without reverse-proxy hacks. The verified resolution: Implemented and closed as completed via bounty PR #2979. Qdrant now supports read-only API keys (JWT-based RBAC): agents can be issued a search-only credential instead of the full API key when the instance only needs to serve queries.