List every case and drill category available, with counts.

Safe to show the candidate — it contains titles and counts, never content. Use it to offer choices ("I have a profitability case in airlines and a market-entry case in consumer health — which would you like?").

The candidate's history: weakest areas, repeated mistakes, recent attempts.

Use it to recommend what to practise, and to open a session with something specific ("last time you dropped the load factor twice — let's do capacity math"). detail includes per-attempt rows.

Begin a full case interview. Opens the interview room in the browser.

Returns a briefing: format, industry, difficulty, how many questions, and the topics of clarifying information available — never the facts themselves. Tell the candidate the room is open and confirm they can hear you before starting.

Begin a drill: loose questions pulled across cases, no full-case context.

This is the "only hard math" mode. Each question carries its own standalone framing so it makes sense out of case order. With target_weaknesses, the sampler leans toward what they keep getting wrong without excluding the rest.

Speak in your own voice — greetings, probes, transitions, feedback.

Keep it conversational and brief — in voice mode it is read aloud, and in text mode it appears as a chat line. Either way: no lists, no markdown, no long sentences.

With expect_reply (the default) the microphone opens as soon as you stop talking, so the candidate can just answer. Follow with listen.

Hear whatever the candidate says next — not tied to any question.

This is the conversational channel: clarifying questions, "can you repeat that", "I'm ready", thinking out loud. If it returns heard: false they're still talking or thinking — just call it again. Never fill the silence.

Read the case prompt aloud to open the interview.

Returns no content — the prompt reaches the candidate inside the room only, never through this tool result (which would land in the chat transcript). After this, expect clarifying questions before they start structuring.

Advance to the next question and read it aloud.

Returns metadata only — type, difficulty, time target — never the text. Use the type to calibrate: a structure question deserves "take a minute if you'd like"; a math question deserves silence while they work.

Deliver the current question again. Candidates are allowed to ask.

Release one withheld fact, if the candidate asked for it.

This is the only way case data reaches them, and it's deliberate: good candidates ask, weak ones assume. If nothing matches, you get matched: false — say you don't have that information and let them proceed. Don't invent facts; you genuinely don't have the case.

Release a specific withheld fact by id, when keyword matching missed it.

Use only when the candidate's question clearly maps to that topic. You are matching intent, not deciding generosity — if they didn't ask for it, don't release it.

Listen for the candidate's spoken answer, then grade what can be graded.

Call it right after asking a question. If it returns ready: false, they're still thinking — call it again. Don't fill the silence; interviewers let candidates work.

Math answers come back fully graded (deterministic, instant). Framework and synthesis answers come back with the rubric's component labels and the committed transcript — read them, decide which components the candidate actually covered, and pass those ids to score.

Record which rubric components the answer covered, and get the verdict.

You supply the semantic matching; the pass/probe policy lives server-side so it's identical for everyone. A PARTIAL verdict with a named gap is your cue to probe rather than move on.

Get the next hint for the current question, escalating weakest-first.

Real interviewers nudge before they explain. Speak the probe with say, then collect_answer again. When probes run out, you've done what an interviewer would — give the answer and move on.

The casebook's own answer for the current question.

Only after grading. Use it to explain what a strong answer sounds like — paraphrase it conversationally rather than reading it out verbatim.

Display a chart or table in the room.

Exhibits are the one thing the candidate is meant to see — a real interviewer slides paper across the table. Speak the intro line, then give them a moment before asking what they make of it.

Inspect the interview room: state, page health, and a timestamped log.

Use this the moment anything looks wrong — silence, a stall, an answer that never arrived. It reports what was spoken, whether the page acknowledged it, whether the mic is open and whether a tab is even connected, so you can diagnose without asking the candidate what they see on screen.

page_problem is the single most useful field: it names the reason the room won't work (no tab, stale build, audio still locked) or is null when healthy.

Drive the room as if you were the candidate. For testing, not for cheating.

This lets you rehearse or diagnose the whole flow with nobody at the keyboard — press Start, submit an answer, confirm the loop advances. During a real interview, don't answer on the candidate's behalf.

End the session and return the scorecard.

Four dimensions, rated 1–5, where 3 is the bar. Note limiting_factor — real interviewers decide on the weakest box, not the average, so that's what the candidate should work on. recurring_habits are patterns seen more than once; those matter more than any single answer.