# Qdrant RBAC [Health: Active]

**Category:** 🧠 Knowledge & Memory  
**Repository:** https://github.com/Fidonis/qdrant-mcp-rbac  
**GitHub Stars:** 0  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/qdrant-rbac

## Description
Role-based access to your Qdrant vector store, via MCP. OIDC in, scoped JWTs out.

## Tools
Capabilities this server exposes over MCP:

- **list_collections** — (any) — returns only collections the caller can read
- **get_collection_info** — r` on the target collection
- **search_collection** — r` on the target collection
- **search_collection_by_text** — r` on the target collection
- **scroll_collection** — r` on the target collection
- **list_documents** — r` on the target collection
- **upsert_points** — rw` on the target collection
- **delete_points** — rw` on the target collection

## Claude Desktop Quick Installation
Remote MCP endpoint (confidence: high). Install path detected from listing signals. Add as a URL/SSE server in your client:

```json
"mcpServers": {
  "qdrant-rbac": {
    "url": "http://localhost:8000/mcp"
  }
}
```

## Documentation

## What Qdrant RBAC does

The Qdrant RBAC MCP server exposes Qdrant vector-store operations through a streamable HTTP MCP endpoint. It authenticates callers with OIDC access tokens, maps their roles to grants, and forwards permitted requests to Qdrant with a derived JWT. Keycloak-compatible OIDC providers are supported through discovery and JWKS endpoints.

Access can be assigned at the collection level as read-only, read/write, or manage. Grants are stored as points in a dedicated ACL collection rather than in static configuration. The server can create that collection on its first read. Administrators can manage grants at runtime through MCP tools, including `grant_access`.

Optional document policies narrow access within a collection. Policies can allow or deny documents according to payload fields such as `acl_tags` or `source`. This makes the Qdrant RBAC MCP server suitable for separating collections and individual records by role.

## How it works

An MCP client sends an `Authorization: Bearer` token to the `/mcp` endpoint. The authentication middleware checks the token signature, expiry, issuer, audience, required subject, and optional not-before claim against the OIDC provider's published keys. Supported signing algorithms are RSA and elliptic-curve variants: RS256, RS384, RS512, ES256, ES384, and ES512. Symmetric and unsigned tokens are rejected.

Roles are read from `realm_access.roles` and from client roles under `resource_access`. Users in the configured break-glass administrator role receive a global-manage Qdrant token. Other users are evaluated against the cached role-to-grant mapping from the ACL collection. Each tool checks access for its target collection before making a Qdrant request.

For reads, a document policy becomes a Qdrant payload filter added as a required condition. Caller-provided filters remain active, so both restrictions apply. Multiple grants are merged using the most-permissive applicable policy; an unrestricted grant removes document-level restrictions for that collection.

## Setup and configuration

The server runs as a container or as its own Python project. A typical container exposes port 8000 and uses `/mcp` for streamable HTTP. `/health` is unauthenticated. Required configuration includes the OIDC issuer URL, OIDC audience, Qdrant URL, and the same JWT secret configured as Qdrant's API key.

Useful settings also include the administrator role, ACL collection name, and JWKS cache lifetime. The ACL collection defaults to `_rbac_acl`. The repository provides a Docker environment template with the complete variable set.

## Tools and capabilities

Available MCP operations include:

- `list_collections` to return collections readable by the caller.
- `get_collection_info` to inspect an accessible collection.
- `search_collection` and `search_collection_by_text` for vector and text-based retrieval.
- `scroll_collection` and `list_documents` for reading points and document facets.
- `upsert_points` and `delete_points` for collections where the caller has write access.
- `grant_access` for runtime administration of role grants, including document policies.

## Limitations and notes

The server depends on an OIDC provider, reachable JWKS discovery, Qdrant, and a shared JWT secret. Role changes are read through a TTL-cached ACL resolver, so updates may not take effect until the relevant cache expires. The `iat` claim is not checked, although expiry, issuer, audience, signature, subject, and `nbf` are enforced.

Document policies operate on Qdrant payload fields. Documents without `acl_tags` remain visible under matching default-allow rules but do not satisfy allow conditions under default-deny rules. The service does not require `acl_tags`; other payload fields can be used instead.

_Full upstream README: https://allmcps.com/mcp/qdrant-rbac/readme_