Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Interviewer MCP Test me on my weak spots from last session"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A technical interviewer that has actually read your repos — teaches you your own code, drills you on it, and remembers every answer you flubbed.
Install · Demo · Tools · Architecture · llms.txt
AI agents / LLMs: read /llms.txt for a machine-readable index of this project.
Interviewers ask about your projects: why this library, what happens when this request fails, walk me through the auth flow. LeetCode can't prep you for that, and a plain chat session forgets everything between sessions. Interviewer MCP indexes your GitHub repo into a teachable code map, walks you through it Socratically, mock-interviews you in character — and keeps a persistent, per-section record of what you couldn't explain, so the next session re-attacks exactly those spots. It teaches and tests, and the test gets smarter every time. Not a stateless quiz.
"Walk me through this function." Every candidate has frozen on that question about code they wrote months ago — or that AI wrote for them. This makes sure it never happens in the real interview.
You Test me again on soundofspace — last week went badly.
Claude [get_progress] Welcome back. Coverage: 9/14 sections. Three questions
logged weak, the worst: "why is the JWT verified server-side?"
Let's start exactly there. [get_code_section auth.ts:verifyToken]
Here's your own code. Line 12 verifies the signature before touching
the payload. Why can't the client just send the decoded claims?
You Because... the client could edit them?
Claude Right instinct — be precise. What stops an attacker who edits the
payload AND re-signs it? Where does the signing secret live?
[log_interview_result: okay — "knows tampering risk, fuzzy on
why the secret never leaves the server"]Related MCP server: MCP Creator Growth
Two ways to run it — pick per surface:
claude mcp add interviewer -- npx -y interviewer-mcp
# optional: private repos + 5,000 req/hr instead of 60
claude mcp add interviewer --env GITHUB_TOKEN=github_pat_... -- npx -y interviewer-mcpClaude Desktop — add to the config file instead:
{
"mcpServers": {
"interviewer": {
"command": "npx",
"args": ["-y", "interviewer-mcp"],
"env": { "GITHUB_TOKEN": "github_pat_optional_but_recommended" }
}
}
}Both classic and fine-grained tokens work (read-only Contents permission is enough). Then:
Prep me for my interview — my repo is github.com/you/your-project
Agent-driven install: point Claude at SETUP_GUIDE.md and it configures everything itself.
Grab SKILL.md, put it in a folder named interview-prepper/, zip the folder
claude.ai → Settings → Capabilities → Skills → Upload skill
Say: "prep me for my interview on github.com/you/your-project"
The honest difference: the MCP server keeps a durable local database of your coverage and weak spots — return in three weeks and it remembers. The Skill runs entirely inside claude.ai: it clones your repo per session and recalls prior sessions via conversation search, which is best-effort, not guaranteed. Same curriculum and teaching format either way; the MCP path is the one that makes "it remembered" a hard promise.
Per-repo ingestion — fetches any GitHub repo via the REST API (no clone needed), filters to real source files, splits them into teachable sections, and orders them: entry points → most-imported core logic → utilities. Warns instead of silently truncating on huge repos.
Teaching mode — one section per exchange, code always shown first, block-by-block what and why, ending with "an interviewer would ask…" — and a section only counts as covered after you explain it back.
Mock interview mode — Claude stays in character, grounding every question in your actual lines: "Why Supabase over Firebase?" "This fetch has no timeout — what happens at 2am?" Probe targets are auto-detected: external API calls, auth/secrets handling, raw SQL, concurrency, leftover TODOs, long uncommented functions.
Job-description targeting — store the JD, company, and your CV once; teaching then flags "this section is your evidence for the REST-APIs requirement," and interviews probe the JD skills your repo doesn't demonstrate.
Mastery tracking — every answer is scored strong/okay/weak with a concrete note. Scores raise per-section weakness; strong answers decay it. All of it persists in ~/.interviewer-mcp/ and every returning session opens from your weakest point.
Five phases, picked in your order from a menu: ① company briefing → ② concept bootcamp (JD ∪ CV ∪ repo stack) → ③ code deep-dive → ④ mock interview → ⑤ debrief.
ingest_repo ──▶ briefing ──▶ bootcamp ──▶ code deep-dive ──▶ mock interview ──▶ debrief
▲ │
└──── "test me again" (days later)
the interviewer REMEMBERS ◀┘Tool | What it does |
| Fetch + index a GitHub repo into a teachable code map |
| Sections in teaching order, with covered status + weakness scores |
| One section's code with file context |
| Mark a section learned (only after you explain it back) |
| Probe-worthy code, weakest spots first |
| Score an answer; powers cross-session memory |
| Store JD + company + CV; powers briefing, bootcamp, and gap questions |
| Coverage, history, top weaknesses — the "welcome back" tool |
Great fit if you…
have an interview where your projects/portfolio will come up
shipped fast (hackathons, AI-assisted) and need to own every line
want targeted revision of your weak spots instead of re-reading the whole repo
Skip it if you…
need algorithm/DSA drilling — that's LeetCode's muscle, not this
want generic behavioral prep with no codebase involved
Local-first and dependency-light by design: plain TypeScript, native fetch, and a JSON store — no native modules, so npx interviewer-mcp boots on every OS with zero build tooling. Your code cache and interview history live in ~/.interviewer-mcp/ (override with INTERVIEWER_DATA_DIR) and never leave your machine; the only network calls are to GitHub. Sectioning is regex-based per language family (JS/TS, Python, Go, Java/C#/Kotlin) with chunking fallback — tree-sitter AST parsing is on the roadmap.
Full pipeline, store layout, and design-decision rationale: ARCHITECTURE.md.
tree-sitter AST parsing for exact section boundaries
multi-repo interviews ("you use pgvector in two projects — compare the schemas")
spaced-repetition scheduling of weak sections
PRs welcome — the core is small, pure, and tested (npm install && npm test). See CONTRIBUTING.md. Vulnerabilities: SECURITY.md.
MIT © Girik Chadha
Get the user's full learning state for a repo: coverage %, session history, top weaknesses with notes, and recent interview performance. Call this FIRST at the start of any returning session ('let's continue', 'test me again', 'where were we') so you can resume from weak spots instead of starting over. Also call it to generate the strengths/weaknesses summary after an interview.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repo id in owner/repo form |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so no safety concerns. Description adds value by detailing the returned data components (coverage %, session history, weaknesses). No contradictions, but could mention any additional behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then usage cases. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with one parameter and no output schema, the description adequately covers the returned data and usage contexts. Slightly more detail on return format would be beneficial but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for 'repo' as 'Repo id in owner/repo form'. The tool description does not add further parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the user's full learning state for a repo, listing specific elements (coverage %, session history, top weaknesses, notes, performance). This is a specific verb+resource combination and distinguishes from sibling set_job_description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to call it first (at start of returning sessions with trigger phrases) and for generating summaries after interviews. Provides clear context for usage and emphasizes resuming from weak spots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store the prep context: job description, and optionally company name and CV text, tied to a repo. Call this when the user pastes or describes any of them. Once set, use it throughout: in teach mode, point out where the code demonstrates JD-required skills; in interview mode, probe JD-required concepts the repo does NOT demonstrate (e.g. 'the JD requires Docker and your repo has no containerization — how would you containerize this app?'). The JD is returned by get_progress so returning sessions stay JD-aware.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repo id in owner/repo form this JD applies to | |
| company | No | Company name, for company-specific briefing and question style | |
| cv_text | No | The candidate's CV/resume text — every claimed skill becomes bootcamp + interview material | |
| job_description | Yes | The full job description text, or the user's summary of the role |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent, non-destructive writes. Description adds that data is tied to a repo and persists across modes. Could mention overwrite behavior but idempotent hint covers it. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: core purpose, when to call, and usage in modes. Front-loaded with key action. Every sentence adds unique value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema descriptions, annotations, and no output schema needed, the description covers storage, usage, and retrieval via get_progress. Adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions. The tool description adds meaningful context about how each parameter is used (e.g., cv_text becomes bootcamp + interview material), going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stores job description, company, and CV text tied to a repo. It uses specific verbs and distinguishes from sibling get_progress, which retrieves this data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call when the user pastes or describes any of these items. Provides detailed guidance on how the stored data is used in teach and interview modes, and notes that get_progress returns the JD for session awareness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.0get_progressset_job_descriptionThe two tools have completely distinct purposes: one for storing job description context, the other for retrieving user progress. No overlap or ambiguity.
Both tools follow a consistent verb_noun snake_case pattern (set_job_description, get_progress), making them predictable and easy to understand.
With only 2 tools, the server feels under-scoped for its advertised 'interview' and 'teach' modes. Many expected operations (e.g., conducting an interview, scoring answers) are missing.
The tool surface lacks any tools for actual interview or teaching interactions. The descriptions refer to modes that would require additional tools not present, leaving critical gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ask any GitHub repository a question. Get source-backed answers.
AI colleagues that keep your standards, your project and their reasoning between sessions
Shared memory for coding agents. Stop re-explaining your codebase every session.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/girik-chadha/interviewer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
