Interview Coach MCP

An MCP-enabled AI Interview Coach that combines structured interview history, semantic memory, and Retrieval-Augmented Generation (RAG) to help analyze a user's LeetCode preparation, identify recurring weaknesses, and provide personalized insights.

The project demonstrates how Model Context Protocol (MCP) can connect an LLM such as Claude to application-owned tools, databases, and semantic memory.

Overview

While solving LeetCode problems, the final answer is only part of the learning process.

Important information is often hidden in the experience of solving the problem:

• What approach did I initially take?

• What mistake did I make?

• What concept did I fail to recognize?

• What insight did I gain?

• How confident was I?

• Have I made a similar mistake before?

• Is the same weakness appearing across multiple problems?

This project stores those experiences and gives an LLM access to them through MCP.

The system combines:

MCP + SQL Database + Semantic Memory + RAG + LLM Agent

to create a personalized interview-preparation assistant.

Related MCP server: myBrAIn

Problem Being Solved

Suppose a user has the following experiences:

Problem A: "I couldn't recognize Binary Search on the Answer."

Problem B: "I recognized binary search but couldn't formulate the feasibility check."

Problem C: "I needed a hint to identify the monotonic relationship."

These are different problems and different descriptions, but they may indicate the same underlying weakness.

A traditional database can answer:

"What problems did I solve?"

But semantic retrieval can answer:

"Have I previously struggled with recognizing monotonic relationships?"

This distinction is the motivation behind the semantic-memory component of the project.

Architecture

                     USER
                       │
                       ▼
                CLAUDE / LLM
                       │
                       │ MCP
                       ▼
          ┌─────────────────────────┐
          │   Interview Coach MCP   │
          │         Server          │
          └────────────┬────────────┘
                       │
          ┌────────────┴────────────┐
          │                         │
          ▼                         ▼
  Structured Memory          Semantic Memory
          │                         │
          ▼                         ▼
       SQLite              Qwen Embeddings
          │                         │
          │                         ▼
          │                      ChromaDB
          │                         │
          └────────────┬────────────┘
                       ▼
                Retrieved Context
                       │
                       ▼
                Claude Reasoning
                       │
                       ▼
             Personalized Analysis

The architecture deliberately separates structured memory from semantic memory.

Technology Stack

MCP Tools

The MCP server exposes the following capabilities to the LLM.

add_problem()

Adds a new LeetCode problem to the relational database.

It also prevents duplicate problem records.

log_attempt()

Logs an interview attempt containing:

• solved status

• time taken

• confidence

• initial approach

• mistake

• insight

• final notes

New attempts are automatically indexed into semantic memory.

get_recent_attempts()

Retrieves the user's recent interview attempts.

get_attempt_history()

Retrieves the historical attempts associated with a problem.

get_topic_history()

Retrieves attempts associated with a particular topic.

get_weak_areas()

Analyzes structured attempt data to identify areas where the user is struggling.

search_interview_memory()

Performs semantic retrieval over previous interview experiences using vector similarity.

Structured Memory

The relational database is built using SQLite and SQLAlchemy.

The core data model is:

Problem │ │ 1:N ▼ Attempt │ │ 1:N ▼ Note

Problem

Stores information about a LeetCode problem:

id leetcode_id title difficulty topic

Attempt

Stores information about an attempt:

id problem_id solved time_taken confidence attempted_at

Note

Stores the qualitative experience:

id attempt_id initial_approach mistake insight final_notes

SQLite is responsible for questions requiring structured and deterministic querying.

For example:

"Show my last 10 attempts."

"What was my confidence on this problem?"

"Show my history with Dynamic Programming."

Semantic Memory & RAG

Structured queries alone cannot capture semantic relationships between different experiences.

Therefore, each attempt is transformed into a memory document.

For example:

Problem: Smallest Sufficient Team Leetcode ID: 1125 Difficulty: Hard

Solved: True Confidence: 6/10

Initial Approach: Recognized the bitmask pattern quickly but initially framed the problem as BFS instead of bitmask DP.

Mistake: Struggled to reframe the problem from BFS/search into DP.

Insight: Need more practice converting bitmask states into DP transitions and reconstructing the solution.

This document is embedded using:

Qwen/Qwen3-Embedding-0.6B

and stored in ChromaDB.

Semantic Retrieval Flow

When the user asks a semantic question:

User Query │ ▼ Qwen Embedding Model │ ▼ Query Vector │ ▼ ChromaDB │ ▼ Top-k Similar Memories │ ▼ MCP Tool Result │ ▼ Claude │ ▼ Reasoning + Synthesis │ ▼ Personalized Response

For example, instead of asking:

"What were my weaknesses in Smallest Sufficient Team?"

the user can ask:

"Have I previously struggled with reconstructing the actual solution after finding the optimal value?"

The system can retrieve the relevant experience even though the problem name was never mentioned.

This is the key semantic-retrieval capability of the project.

Automatic Memory Indexing

New attempts are automatically added to semantic memory.

The flow is:

log_attempt() │ ▼ Create Attempt │ ▼ Create Note │ ▼ Commit to SQLite │ ▼ index_attempt() │ ▼ build_memory_document() │ ▼ Qwen Embedding │ ▼ ChromaDB

This means the user does not need to manually synchronize the relational database and vector database.

Existing records can also be indexed using the indexing utility created during development.

Agentic Tool Orchestration

One of the main demonstrations of MCP is that Claude can combine multiple tools to answer a higher-level question.

For example:

"Analyze my recent interview performance."

Claude can determine that it needs multiple sources of information:

get_recent_attempts() ↓ get_weak_areas() ↓ search_interview_memory() ↓ get_attempt_history() ↓ Claude synthesizes the results

The important point is that the MCP server does not manually implement one giant function such as:

analyze_everything()

Instead, it exposes smaller capabilities and allows the LLM agent to decide which capabilities are required.

Why MCP?

Without MCP, the application could simply be implemented as a Python program directly connected to SQLite, ChromaDB, and an LLM API.

The purpose of MCP is to create a standardized interface between the LLM and application capabilities.

The LLM does not need to know:

• how SQLAlchemy works,

• where the database is located,

• how ChromaDB performs similarity search,

• how embeddings are generated.

It only interacts with capabilities such as:

get_recent_attempts() get_weak_areas() search_interview_memory() log_attempt()

Conceptually:

LLM │ │ MCP ▼ Tools / Capabilities │ ▼ Application Logic │ ├── SQLite └── ChromaDB

This separation makes the application capabilities accessible to an MCP-compatible client without coupling the client to the internal implementation.

Why Not Just Use Claude/ChatGPT Memory?

A natural question is:

"Claude and ChatGPT already have memory. Why build another memory system?"

The key distinction is application-owned, domain-specific memory vs. conversational memory.

This project explicitly owns and controls the memory layer.

1. Structured application data

The system stores interview-specific fields such as:

Problem Attempt Confidence Time Taken Mistake Insight Topic Difficulty

This allows deterministic database queries and analysis.

2. Semantic retrieval

The project explicitly embeds interview experiences and stores them in ChromaDB.

This allows queries based on meaning rather than exact wording.

3. Retrieval control

The application controls:

• what gets stored,

• how memories are constructed,

• which embedding model is used,

• how many results are retrieved,

• how similarity search is performed,

• what context is returned to the LLM.

4. Application ownership

The memory belongs to the application rather than being an implicit feature of a particular chat interface.

The underlying memory system can therefore evolve independently of the LLM client.

5. Domain-specific design

The memory schema is specifically designed around interview preparation.

The system is not simply remembering that a conversation happened; it is explicitly modeling:

problem → attempt → mistake → insight → confidence

Interview Summary

If asked:

"Why not just use Claude's memory?"

A concise answer is:

"Claude's conversational memory and my application's semantic memory solve different problems. I wanted application-owned, domain-specific memory where I control the schema, persistence, embedding model and retrieval strategy. SQLite handles structured interview history, while ChromaDB provides semantic retrieval over qualitative experiences. MCP then exposes these capabilities to the LLM in a standardized way."

Why SQLite + ChromaDB?

The two databases serve different purposes.

SQLite

Best for:

• structured records

• relationships

• filtering

• aggregation

• deterministic queries

ChromaDB

Best for:

• embeddings

• semantic similarity

• natural-language retrieval

• conceptually related experiences

Therefore:

SQLite "What happened?"

ChromaDB "What is semantically similar?"

Using both provides a hybrid memory architecture.

Why Qwen Embeddings?

The project uses:

Qwen/Qwen3-Embedding-0.6B

because the primary retrieval task is semantic matching between natural-language descriptions of interview experiences.

The embedding model converts both memories and user queries into vector representations so that semantically related experiences can be retrieved even when they use different wording.

The model can also be run locally, which fits the current local-first architecture.

Example

Suppose the user logs:

I solved Smallest Sufficient Team. I recognized the bitmask pattern quickly but struggled to formulate it as DP. I also figured out the minimum team size but couldn't reconstruct the actual selected people. Confidence 6/10.

The system performs:

` log_attempt() ↓ SQLite ↓ index_attempt() ↓ Qwen Embedding ↓ ChromaDB

Later, the user asks:

"Have I previously struggled with reconstructing an actual solution after determining the optimal value?"

Claude calls:

search_interview_memory()

ChromaDB retrieves the semantically related memory.

Claude then uses that retrieved context to produce a personalized response.

Project Structure

interview_coach_mcp/
│
├── src/
│   ├── server.py
│   ├── database.py
│   ├── models.py
│   ├── memory.py
│   └── ...
│
├── prompts/
│   └── instructions_to_mcp.py
│
├── tests/
│   └── ...
│
├── chroma_data/
│
├── .env
├── pyproject.toml
├── uv.lock
└── README.md

chroma_data/, .env, virtual environments, caches and other generated/local files should not be committed to GitHub.

Running the Project

Install dependencies using uv and activate the project environment.

Run the MCP server using:

uv run python src/server.py

The MCP server can then be connected to an MCP-compatible client such as Claude.

Production Considerations

The current implementation is designed primarily as a local learning project.

A production deployment could evolve toward:

                Cloud Deployment
                       │
             ┌─────────┴─────────┐
             │                   │
         PostgreSQL            Qdrant
             │                   │
             └─────────┬─────────┘
                       │
                   MCP Server
                       │
                Authentication
                       │
                     LLM

Potential improvements include:

• PostgreSQL instead of SQLite

• Qdrant or another production vector database

• Docker containerization

• AWS deployment

• authentication and authorization

• asynchronous embedding/indexing

• background workers

• retrieval filtering

• reranking

• RAG evaluation

• observability

• automated testing

Future Improvements

Potential future extensions include:

Hybrid Retrieval

Combine structured filtering with semantic retrieval.

For example:

"Find semantically similar Dynamic Programming experiences from the last three months."

Reranking

Retrieve a larger candidate set and rerank the results before sending them to the LLM.

RAG Evaluation

Measure:

• retrieval relevance

• retrieval recall

• answer relevance

• answer faithfulness

Learning Progress Tracking

Track whether identified weaknesses improve over time.

For example:

Binary Search on Answer

August     → Confidence: 3/10
September  → Confidence: 6/10
October    → Confidence: 8/10

This could eventually turn the system from an interview-memory assistant into a longer-term learning analytics system.

Key Concepts Demonstrated

This project provides hands-on experience with:

Model Context Protocol

• MCP server development

• FastMCP

• MCP tools

• tool discovery

• multi-tool orchestration

• LLM-driven tool selection

RAG

• document construction

• embeddings

• vector databases

• semantic search

• top-k retrieval

• retrieved context

• LLM synthesis

Databases

• SQLite

• SQLAlchemy

• relational modeling

• one-to-many relationships

• persistent application state

AI Engineering

• LLM tool use

• agentic workflows

• structured memory

• semantic memory

• application-owned memory

• semantic retrieval

• RAG pipelines

Project Status

Completed

• MCP server

• FastMCP tools

• SQLAlchemy data model

• SQLite persistence

• Problem management

• Attempt logging

• Attempt history

• Recent attempts

• Topic history

• Weak-area analysis

• Agentic multi-tool orchestration

• MCP instructions

• Semantic memory

• Qwen embeddings

• ChromaDB

• Semantic retrieval

• RAG integration

• Automatic memory indexing

• Claude integration

Future

• Dockerization

• AWS deployment

• PostgreSQL

• Production vector database

• Async indexing

• Reranking

• RAG evaluation

• Observability

Core Idea

The project can ultimately be summarized as:

MCP
  +
Structured Memory
  +
Semantic Memory
  +
RAG
  +
LLM Agent
  =
Personalized Interview Coach

MCP provides the interface to the application's capabilities.

SQLite stores structured interview history.

Qwen embeddings + ChromaDB provide semantic memory.

RAG retrieves relevant past experiences.

Claude reasons over the retrieved context and produces personalized interview insights.