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., "@claude-interview-mode Let's do an interview about my SaaS pricing strategy"
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.
An MCP server that turns Claude into a structured interviewer — and gets smarter with every conversation. Each interview feeds a shared evolution system where checkpoints are scored, ranked, and recommended based on real usage patterns across all users.
This isn't just an interview tool. It's a collectively evolving knowledge system.
Every time anyone runs an interview in a category (e.g., "saas-pricing"), the system learns:
Session 1: You explore freely → decisions become new checkpoints
Session 2: Checkpoints load → Claude prioritizes what matters
Session 5: Bayesian scores stabilize → the interview path optimizes itself
Session 20: Community patterns emerge → everyone benefits from collective experience1. Checkpoint Discovery — When a decision is made during an interview, its topic is automatically registered as a new checkpoint. After just a few sessions, the system knows what topics matter for each category.
2. Bayesian Scoring — Each checkpoint tracks how often it's covered and how often it leads to a decision. The score uses Bayesian smoothing to handle sparse data:
decision_rate = (decisions + 0.6) / (times_covered + 2)The prior (0.6/2 = 30% base rate) ensures new checkpoints start with a reasonable score. After ~5 sessions, real data dominates.
3. Composite Ranking — Checkpoints are ranked by a composite score combining decision-leading effectiveness (70%) and usage frequency (30%):
composite = decision_rate × 0.7 + normalized_usage × 0.3High-scoring checkpoints are the ones that consistently lead to concrete decisions — not just topics that get discussed.
4. Recommended Path — The system computes an optimal interview path: checkpoints with decision_rate > 0.2, sorted by their average position in past sessions. This tells Claude not just what to ask, but when to ask it.
5. Community Evolution — All metadata flows to a shared database. When you interview about "api-design", you benefit from every other user who interviewed about "api-design" before you. The checkpoints, scores, and paths evolve collectively.
Shared (metadata only) | Never shared |
Category names (e.g., "saas-pricing") | Your actual questions and answers |
Checkpoint names (e.g., "pricing-model") | Decision details and reasoning |
Usage counts, scores, positions | Any personal or project-specific content |
Related MCP server: ATLAS MCP Server
Claude drives the interview — asks questions, proposes options with reasoning, challenges assumptions
Tracks Q&As and decisions — structured records with timestamps
Evolving checkpoints — learns what topics matter per category, ranked by Bayesian effectiveness scores
Recommended paths — suggests the optimal order to explore topics based on past interview patterns
Concurrent sessions — supports multiple interviews running in parallel
Privacy-first — only anonymous metadata (categories, checkpoint names, counts) goes to the shared database
npx claude-interview-modeOr install globally:
npm install -g claude-interview-modeAdd to your project's .mcp.json:
{
"mcpServers": {
"interview-mode": {
"type": "stdio",
"command": "npx",
"args": ["-y", "claude-interview-mode"]
}
}
}Restart your Claude Code session to load the MCP server. That's it — the evolution system starts working immediately via a shared community database.
By default, checkpoint data is stored in a shared community Supabase instance. If you want your own private database:
{
"mcpServers": {
"interview-mode": {
"type": "stdio",
"command": "npx",
"args": ["-y", "claude-interview-mode"],
"env": {
"SUPABASE_URL": "https://your-project.supabase.co",
"SUPABASE_ANON_KEY": "your-anon-key"
}
}
}
}Then run supabase/schema.sql in your Supabase SQL Editor to create the tables.
Start an interview with Claude Code:
> Let's do an interview about my SaaS pricing strategyClaude will lead the conversation. As the interview progresses:
Each Q&A and decision is recorded with checkpoint coverage
At the end, metadata is uploaded to evolve the system
Next time anyone interviews in the same category, the improved checkpoints are loaded
Tool | Description |
| Begin a session — loads scored checkpoints and recommended path |
| Record a Q&A or decision, with checkpoint coverage tracking |
| Review progress, see uncovered checkpoints ranked by score |
| End session, upload metadata, evolve the checkpoint system |
You ←→ Claude ←→ MCP Server (interview-mode)
│
├─ read (anon key, read-only)
│ └→ checkpoints, scores, patterns
│
└─ write (Edge Function, validated)
└→ metadata, checkpoint updates, score recalculation
│
Supabase (shared community DB)4 database tables power the evolution:
Table | Purpose |
| Checkpoint dictionary per category (name, usage count, decision count) |
| Bayesian scores per checkpoint (decision rate, avg position, samples) |
| Coverage sequences per session (which checkpoints, in what order) |
| Session summaries (category, counts, duration) |
Security:
Anon key is read-only (SELECT only via RLS)
All writes go through an Edge Function with input validation and spam defense
Empty interviews, implausible rates, and oversized payloads are rejected
git clone https://github.com/teabagkim/claude-interview-mode.git
cd claude-interview-mode
npm install
npm run build # TypeScript → dist/index.js
npm run dev # Watch modeMIT
End the current interview session and get a structured summary of all Q&As and decisions. Use this when enough information has been gathered.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Session ID to end. If omitted, uses the most recent active session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool ends the session and returns a summary, but does not disclose whether it is destructive or any side effects. Adequate but lacks depth.
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?
Two sentences, front-loaded with the action, no wasted words. Every sentence adds value and is immediately actionable.
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 the simplicity of the tool (one optional parameter, no output schema), the description is nearly complete. It explains when to use and what happens, but could mention if the action is reversible or if it saves data.
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% (the single parameter session_id is fully described in the schema). The description adds no additional meaning beyond what the schema already provides, so baseline of 3 is appropriate.
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 verb 'End' and the specific resource 'current interview session', and also notes the output 'structured summary of all Q&As and decisions'. This distinguishes it from sibling tools like start_interview and get_context.
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?
The description explicitly advises 'Use this when enough information has been gathered', providing clear context for appropriate use. It does not explicitly list when not to use, but the guidance is straightforward enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full context of the current interview session. Use this to review what has been discussed so far before asking the next question.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Session ID. If omitted, uses the most recent active session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-like operation (get context) but does not detail what 'full context' includes or any side effects. The description is adequate but not highly informative.
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?
The description is two sentences, front-loaded with the action, and contains no unnecessary information. Every sentence earns its place.
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?
The description is complete enough for a simple retrieval tool: it states what it does and when to use it. However, without an output schema, it could briefly hint at the return format. Overall, it is satisfactory.
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 one optional parameter. The description does not add any information about the parameter beyond what the schema provides, so the baseline score of 3 applies.
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 uses a specific verb 'Get' and resource 'full context of the current interview session', clearly distinguishing it from sibling tools like end_interview, record, and start_interview.
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?
The description explicitly states to use it for reviewing what has been discussed before asking the next question, providing clear context. However, it does not mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a Q&A exchange or a decision made during the interview. Call this after each meaningful exchange to maintain context.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of record: 'qa' for question-answer, 'decision' for a decision made | |
| topic | No | The topic of the decision (for decision type) | |
| answer | No | The answer received (for qa type) | |
| decision | No | The decision made (for decision type) | |
| question | No | The question asked (for qa type) | |
| reasoning | No | Why this decision was made (for decision type) | |
| session_id | No | Session ID to record into. If omitted, uses the most recent active session. | |
| covered_checkpoints | No | Checkpoint names that this Q&A or decision covers. Match against the checkpoints loaded at session start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It mentions recording for context but does not disclose side effects, idempotency, permissions, or how records are stored and used afterward (e.g., by get_context).
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?
Two sentences: first defining the action, second specifying usage. No extraneous information, efficient and clear.
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?
With 8 parameters and no output schema, the description is too brief. It omits post-recording behavior, return values, and how records affect context (crucial given get_context sibling). The tool's role in maintaining context is vague.
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 descriptions for all parameters. The description does not add meaning beyond the schema, so baseline 3 applies; no extra parameter guidance is provided.
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 records Q&A exchanges or decisions during an interview, with a specific verb ('Record') and resource. It distinguishes from siblings like end_interview or get_context by focusing on recording events.
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?
The description explicitly advises calling after each meaningful exchange to maintain context, providing clear usage timing. It does not specify when not to use or alternatives, but the context with sibling tools makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new interview session. Use this when beginning a conversational exploration of a topic, project, or decision.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The topic or purpose of this interview | |
| category | No | Category for checkpoint matching (e.g. 'service-planning', 'api-design'). Defaults to topic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states 'start a new interview session' without disclosing side effects, state changes, or whether previous sessions are affected. For a mutation tool, this is insufficient.
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?
Two sentences, direct and efficient. The first sentence states the action, the second provides usage guidance. No wasted words.
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 simple tool with 2 parameters and no output schema, the description covers purpose and usage. It lacks details about session management (e.g., session ID), but given siblings and context, it is minimally adequate.
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 both parameters described. The description adds no further meaning beyond the schema, meeting the baseline. No additional param context is needed.
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 starts a new interview session, using the specific verb 'start' and resource 'interview session'. It distinguishes from siblings like end_interview by context.
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?
The description explicitly says 'Use this when beginning a conversational exploration', providing clear context for when to use. However, it does not mention when not to use or name alternatives, though siblings are apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: start_interview initiates, record logs exchanges, get_context retrieves current state, end_interview concludes. No overlap or ambiguity.
All tools use imperative verbs, mostly in verb_noun form (start_interview, end_interview, get_context). 'record' is a single verb but fits the pattern; minor inconsistency but still predictable.
Four tools is ideal for an interview mode server. Each tool serves a fundamental operation (start, record, read context, end) without being overly minimal or excessive.
The tool set covers the full interview lifecycle (start, record, review context, end). A potential gap might be editing or removing a record, but the core workflow is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Chat forgets your training. AIm doesn't — an AI coach for Claude with persistent memory.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Persistent, governed institutional memory for Claude Code — specs, decisions, learnings.
Give Claude an honest self-model — behavioral tendencies built from evidence, not session memory. Mi
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/teabagkim/claude-interview-mode'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
