PDF-Based RAG & MCP Document Assistant

Overview

The assistant turns PDFs into searchable knowledge sources. Local all-MiniLM-L6-v2 embeddings, ChromaDB retrieval, and DeepSeek answers over retrieved context run through FastAPI; MCP provides tool access to those capabilities. Status and latest-log endpoints support observability.

Problem and goal

Finding the right passage in long documents and tracing an answer back to a page is difficult. A general-purpose LLM can produce details not grounded in the document without source context.

My role

• Developed PDF extraction, chunking, embedding, and ChromaDB indexing.
• Connected retrieval results to answer generation with source and page information.
• Exposed search and question-answering through FastAPI and MCP tools.

Solution

• Document text was chunked while retaining page context and indexed with embeddings.
• Questions were converted into vector searches for the most relevant passages.
• Retrieved context was passed to the LLM to produce an answer and source markers; MCP remained the tool-access layer.

Architecture

The system’s main components and data/decision flow are separated as follows.

Tech stack

Implementation decisions

• Treat source updates as a re-indexing problem rather than model training.
• Keep heavy retrieval and generation work in the backend and the MCP layer thin.
• Keep document and page information visible beside the answer.

Results and evaluation

• Built an end-to-end flow for PDF ingestion, indexing, search, and sourced question-answering.
• Made the same capabilities available to web/API and MCP clients.

Challenges and solutions

• Context-preserving chunking → carry page metadata with every passage.
• Layer responsibilities → keep retrieval/LLM work in the backend and tool contracts in MCP.

What I learned

The project reinforced that RAG quality depends heavily on extraction, chunk boundaries, metadata, and source presentation—not just model choice.