RAGLight: A Provider-Agnostic RAG Framework With Optional Extras and an MCP Hook

The Gap RAGLight Fills: One Retrieval Layer, Many Providers

Most RAG code starts as a script tied to one vendor. You embed with one model, store vectors in one database, and call one chat endpoint. Swapping any of those means editing the pipeline, not just a config value. RAGLight's stated goal is to make each of those three pieces a plug: the README lists LLM support for Ollama, Google Gemini, LMStudio, vLLM, OpenAI API, Mistral API and AWS Bedrock, embeddings that can come from HuggingFace models such as all-MiniLM-L6-v2 or from Bedrock, and vector stores chosen at install time. The audience is a Python developer who already knows they want retrieval-augmented generation and does not want to write the glue for a fourth time. The repository topics include agentic-ai, agentic-rag and mcp-tools, which signals the project is aimed at people building tool-using assistants rather than plain question-answering over a PDF folder. That is a narrower and more opinionated target than a generic RAG library, and it explains why MCP integration sits in the feature list next to embeddings.

How the Pieces Fit: Ingestion, Vector Store, Retrieval, Generation

The README describes a pipeline rather than a service. Documents are ingested from a folder, chunked and embedded, then written to a vector store. At query time the retriever pulls candidates and the LLM generates an answer. Two features change that shape. Hybrid search combines BM25 keyword retrieval with dense vector search and merges the two ranked lists using Reciprocal Rank Fusion, which the README presents as a way to get both exact-term matching and semantic matching in one result set. Query reformulation rewrites a follow-up question into a standalone query using conversation history, which matters in multi-turn chat where a question like "and what about the second one" has no retrievable terms on its own. Conversation history is supported across all listed providers with an optional max_history cap. Streaming is exposed as generate_streaming() alongside generate(), described as a drop-in with no extra configuration. Observability is optional: installing the langfuse extra traces the retrieve, rerank and generate stages. The architecture is therefore a set of swappable components with a default wiring, plus hooks (custom pipeline, processor overrides) for replacing stages you disagree with.

Getting It Running: pip Extras, the CLI Wizard, and raglight serve

Installation is a base package plus extras. The base command is pip install raglight. Vector store backends are separate: pip install "raglight[qdrant]" for Qdrant, pip install "raglight[chroma]" for ChromaDB, and they can be combined as pip install "raglight[chroma,qdrant]" or paired with observability as pip install "raglight[qdrant,langfuse]". The README notes a real platform difference here: the chroma extra requires a C++ compiler on Windows, while qdrant-client is pure Python and works without one. That single line is probably the most practically useful sentence in the document. For a no-code path, raglight chat launches an interactive wizard that asks for a data folder, folders to ignore during indexing (the README gives .venv, node_modules and __pycache__ as examples), where to store the vector database and under what name, which embeddings model to use, and which LLM to use. The README states the wizard then indexes the documents and starts a chat session. A second wizard, raglight agentic-chat, does the same for the agentic pipeline. For service deployment there is raglight serve, which exposes a REST API with a chat UI, endpoints, environment-variable configuration and a Docker Compose path; the same configuration can also be supplied through the configuration classes, including ignore-folder settings. If you use LMStudio, the README is explicit that the model must already be loaded there. If you use AWS Bedrock, credentials come from environment variables, ~/.aws/credentials or an IAM role, with no extra install.

Where RAGLight Will Frustrate You

The project ships releases quickly: 3.1.1 in early March 2026, 3.2.0 a week later, 3.4.7 by late March, and a push to main in September 2026. That cadence is a signal about API stability, and it is the first thing to weigh. The README is also the primary specification; the supplied material does not include a changelog, a migration guide or a deprecation policy, so an upgrade from 3.1.x to 3.4.x has no documented path in what is available here. The extras design is a second friction point. Because vector store clients are optional, a missing extra surfaces as an import error at runtime rather than at install time, and the Windows C++ compiler requirement for ChromaDB will stop an install cold on a machine without a toolchain. The provider list is broad, but breadth is not the same as parity: the README asserts conversation history and streaming across all providers, yet the supplied material does not document per-provider behaviour differences, so a feature that works against Ollama may behave differently against Bedrock. Finally, MCP integration means the agent can call external tools such as code execution or database access. That is a security boundary, not a feature bullet, and the README does not describe a permission model. If your use case is a single provider and a single vector store that will never change, RAGLight's abstraction is overhead you will pay for and never use.

What It Is Not: RAGLight Against a Hosted RAG Service

The obvious alternative is a hosted retrieval service, where you upload documents through an API and the vendor owns chunking, embedding, indexing and the generation call. The difference in approach is total. A hosted service collapses the three swap points into one vendor decision and removes the vector store from your infrastructure entirely. RAGLight does the opposite: it keeps the vector store on your side, whether that is Qdrant or ChromaDB, and keeps the model call configurable per environment. That matters when the constraint is data residency, when you already run Ollama locally, or when you want to test the same pipeline against a local model and a hosted one without changing retrieval code. It also means you own the operational surface: the vector database process, the credentials for whichever provider you select, and the Docker Compose stack if you deploy the REST API. The trade is control for maintenance. A hosted service will not ask you to install a C++ compiler.

Maintenance Cost, Licence and the MCP Question

RAGLight is MIT licensed, which permits commercial use and modification; the licence text itself is the authority and this is not legal advice. The practical maintenance cost sits in three places. First, the optional extras: each vector store backend is a dependency you upgrade separately, and ChromaDB in particular carries a native build requirement on Windows that Qdrant does not. Second, provider SDKs: seven LLM providers means seven sets of credentials, rate limits and model-name changes to track, and the README's provider list is the contract you are relying on. Third, MCP. Connecting external tools through MCP servers expands what the agent can do, and the supplied material does not describe any allowlist, sandbox or audit mechanism around those calls, so the trust boundary is whatever the MCP servers themselves enforce. Langfuse tracing, if you install the langfuse extra, is the one observability path the README names, and it covers retrieve, rerank and generate rather than tool invocation.

Who Should Adopt It, and What to Check First

RAGLight fits a Python team that wants a single retrieval and generation layer covering local and hosted models, is comfortable installing backends as extras, and treats the CLI wizard as the fastest route to a working prototype before writing custom pipeline code. It does not fit a team that needs a frozen API, a documented upgrade path between minor versions, or a managed service with an SLA. Three checks before you commit. Install the backend you actually intend to use and confirm it resolves on your platform: pip install "raglight[qdrant]" sidesteps the C++ compiler requirement that pip install "raglight[chroma]" imposes on Windows. Run raglight chat against a small folder with your ignore list set (.venv, node_modules, __pycache__) and confirm the wizard reaches a chat session against your provider, remembering that LMStudio requires the model to be loaded first. Then decide whether the MCP path is in scope, because that is the feature that changes the risk profile from a retrieval library to an agent with tool access, and the README does not tell you how to bound it.

Editorial conclusion

Adopt RAGLight if you want one Python codebase that can point at Ollama today and OpenAI, Mistral, Gemini, vLLM or AWS Bedrock tomorrow without rewriting the retrieval layer, and if you are willing to install vector store backends as extras. Do not adopt it if you need a managed service, a stable API guarantee, or a project with a long release history; the version numbers here move fast and the README is the main specification. Before committing, verify three things on your own machine: that the vector store extra you pick installs cleanly (raglight[qdrant] avoids the C++ compiler requirement that raglight[chroma] carries on Windows), that your chosen provider is reachable from the process that runs raglight serve, and that the MCP servers you intend to expose are ones you are willing to let an agent call.

Official sources

1. Bessouat40/RAGLight on GitHub
2. License: MIT
3. Project website
4. README
5. Releases