Chapter 7 — MCP & RAG

Retrieval & Benefits

Retrieval parameters, the architectural benefits of the RAG layer, its security and persistence model, and the end-to-end flow from document upload to Agent response.

Retrieval configuration

Several parameters control how LightRAG searches the indexed knowledge and how much information is returned.

• Mode — the retrieval strategy. Supported modes are naive, local, global, hybrid and mix; the default is mix. Each strategy is described under KnowledgeBase retrieval.
• topK — the number of top relevant results considered during retrieval.
• onlyNeedContext — returns the retrieved context without requiring a generated RAG answer. Particularly useful for Agent integration, where the Agent itself is responsible for reasoning and generating the final response.

{
"query": "...",
"mode": "mix",
"topK": 10,
"onlyNeedContext": true
}

The backend forwards the retrieval request to the LightRAG server configured for the selected topic. For Agent-based retrieval, returning only the relevant context keeps response generation inside the Agent — the retrieved information becomes additional context, combinable with conversation state and other tool results.

Figure 7 — RAG architecture, components and retrieval configuration.

Architectural benefits

Access to organisation-specific knowledge	The Agent retrieves information from documents maintained by the organisation instead of relying only on the model's general knowledge.
Independent knowledge updates	Documents can be added, updated or removed without changing Agent logic or retraining the underlying model.
Runtime retrieval	The Agent decides when additional knowledge is required and invokes RAG only when necessary, complementing its other tools.
Separation of retrieval and reasoning	LightRAG retrieves relevant information; the Agent remains responsible for reasoning, conversation handling and response generation.
Configurable retrieval behaviour	Parameters such as mode, topK and onlyNeedContext adapt retrieval to different use cases.
Knowledge isolation by topic	Topics provide separate knowledge scopes and LightRAG configurations for different projects or use cases.
Reusable Agent architecture	The same Agent logic works with different knowledge bases by changing the configured topic and documents rather than implementing new retrieval logic.

The knowledge layer can therefore evolve independently while Agent behaviour stays flexible, reusable and focused on the current conversation.

Security and persistence

• The Knowledge Base Backend supports Bearer JWT authentication for protecting access to its API when authentication is enabled.
• Communication between the backend and LightRAG uses the API credentials configured for the corresponding topic. LightRAG API keys are stored encrypted and added by the backend, never exposed directly to the Agent.
• PostgreSQL persists knowledge-base topics, LightRAG configuration, document metadata and status, RAG configuration and query history.

End-to-end RAG flow

The integration has two stages. During knowledge preparation , documents are added to a topic and processed by LightRAG until they are indexed and available for retrieval. At runtime , the Agent determines whether additional knowledge is required; if so it invokes the RAG tool, which retrieves relevant document context through the backend and LightRAG. The returned context is then used by the Agent when determining its response.

Figure 8 — End-to-end RAG flow.