ranger-rag-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CA_BUNDLE | No | Path to CA certificate bundle | |
| VERIFY_SSL | No | Set 'false' to disable SSL verification | true |
| RANGER_PASS | Yes | Workload password for Ranger API auth | |
| RANGER_USER | Yes | Workload username for Ranger API auth | |
| RAG_STUDIO_URL | Yes | RAG Studio base URL | |
| RAG_STUDIO_API_KEY | Yes | RAG Studio API key | |
| RANGER_GATEWAY_URL | Yes | Ranger Admin REST API URL via Knox | |
| RAG_INFERENCE_MODEL | No | LLM model for response generation | |
| RAG_RESPONSE_CHUNKS | No | Number of chunks to retrieve | 5 |
| RANGER_SERVICE_NAME | No | Ranger service name | rag |
| HTTP_TIMEOUT_SECONDS | No | Request timeout in seconds | 30 |
| RAG_STUDIO_PROJECT_ID | No | Project ID | 1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| query_knowledge_baseA | Query a RAG knowledge base with Ranger authorization check. First checks Apache Ranger to verify the user has 'read' access to the specified knowledge base. If allowed, forwards the query to RAG Studio and returns the answer. If denied, returns an access denied message. Args: user: Username to check permissions for (e.g., 'alice', 'bob'). knowledge_base: Name of the knowledge base to query (e.g., 'Finance KB', 'HR Policies'). query: The question to ask the knowledge base. Returns: If authorized: The RAG response with answer and sources. If denied: An access denied message with the reason. |
| list_knowledge_basesA | List all knowledge bases the user has access to. Checks Ranger authorization for each knowledge base and returns only those the user is permitted to query. Args: user: Username to check permissions for. Returns: List of accessible knowledge bases with their details. |
| check_accessA | Check if a user has access to a specific knowledge base without querying it. Useful for pre-flight permission checks before attempting a query. Args: user: Username to check permissions for. knowledge_base: Name of the knowledge base. access_type: Type of access to check ('read' or 'write'). Default: 'read'. Returns: Access decision with policy details. |
| list_policiesA | List all Ranger policies for the RAG service. Shows which users/groups have access to which knowledge bases. Useful for administrators to understand the current access control setup. Returns: List of policies with their resource definitions and access rules. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: querying a KB, listing accessible KBs, checking access pre-flight, and listing all policies. There is no meaningful overlap that would cause confusion, as even the access check in query is incidental to its primary function.
All tool names follow a consistent verb_noun snake_case pattern (query_knowledge_base, list_knowledge_bases, check_access, list_policies). The two 'list' verbs are used consistently with different objects, and there are no mixed conventions.
Four tools is a well-scoped count for a RAG query service with authorization checks. Each tool covers a necessary function without redundancy, fitting the typical 3-15 range comfortably.
The core workflows of querying, listing accessible bases, pre-flight access checks, and viewing policies are covered. Minor gaps exist such as no policy management or write operations, but these are likely out of scope for a read-oriented query server.