MCP Sampling and Elicitation Testing Interview Questions

MCP sampling and elicitation testing interview questions probe whether an engineer can test a bidirectional protocol, not whether they can memorize two method names. A strong candidate separates wire-level correctness, capability negotiation, user control, security, model quality, and compatibility across protocol revisions.

There is also a current lifecycle nuance. Sampling remains relevant to existing protocol revisions and implementations, while the accepted protocol work marks the core feature as deprecated during a transition window. Interview answers should name the revision under test, preserve backward compatibility, and avoid designing a new dependency as if its status were permanent. Elicitation remains a distinct client capability with form and URL modes in the current draft documentation.

This guide is independent preparation based on public protocol information and common engineering competencies. It does not present leaked, confidential, official, or guaranteed interview questions.

Build the Correct Mental Model First

In sampling, a server asks the connected client to perform a model generation. The client retains control over model access, permissions, and what is returned. The test boundary therefore includes capability advertisement, the create-message request, human approval policy, content validation, model selection policy, result handling, and failure propagation.

In elicitation, a server asks the client to obtain more information or guide the user through an external interaction. Form mode requests structured, reviewable input. URL mode sends the user to an external location for sensitive or out-of-band work. An accept action for URL mode indicates consent to continue, not proof that the external task completed.

Do not collapse either feature into “the server calls AI” or “the server shows a form.” The protocol relationship matters: these are server-to-client requests associated with an originating client request, and each side has duties that should be independently observable.

Map the Protocol Testing Boundary

The field map traces a request from negotiated capability to a decision that can be audited. It deliberately separates transport evidence from semantic quality.

1. 01 / revision contract

   Revision Contract

   Select the protocol version and advertised capability.

   negotiate

2. 02 / associated request

   Associated Request

   Bind the server request to an originating client action.

   authorize

3. 03 / user control

   User Control

   Apply review, consent, decline, and cancellation rules.

   exercise

4. 04 / evidence check

   Evidence Check

   Validate envelopes, schemas, safety, and model quality.

   decide

5. 05 / compat decision

   Compatibility Decision

   Pass, reject, or migrate with explicit revision evidence.

The first test artifact should record client and server versions, negotiated protocol revision, advertised capabilities, request ID, originating request ID or trace relationship, user action, response envelope, and terminal outcome. Without those fields, a failure that looks semantic may actually be a negotiation or correlation defect.

Test Sampling in Deterministic and Statistical Layers

Protocol tests can be exact even when model output is variable. Assert that an unsupported client does not receive a sampling request, required fields use valid shapes, roles and content types are handled, request IDs correlate, cancellation is respected, invalid results fail safely, and server errors reach the original operation without being disguised as a successful generation.

Model-output evaluation belongs in a separate layer. Use versioned inputs, explicit quality criteria, safety slices, and repeated samples when variance affects the decision. Record model and prompt configuration where the client exposes it, but do not assert a provider-specific model choice if the protocol leaves that choice to client policy.

An interviewer may ask, “How would you test temperature?” A weak answer says to set it to zero for deterministic output. A stronger answer asks whether the field is a hard control or a preference, validates bounds and serialization at the protocol layer, and measures the output distribution rather than promising mathematical determinism.

Test Elicitation as a User-Controlled State Machine

Treat elicitation as states and transitions. Start with requested, then cover displayed, accepted, declined, cancelled, timed out, failed validation, and completed where the mode supports a completion signal. Exercise duplicates and late messages. A client should ignore an unknown or already-completed elicitation identifier instead of resuming an unrelated user flow.

For form mode, test supported schema keywords, required and optional fields, boundary lengths, enum values, malformed schemas, client-side review, server-side validation, and the user's ability to modify or decline. Sensitive credentials should not travel through form mode.

For URL mode, verify explicit consent, full target visibility, secure opening behavior, domain emphasis, suspicious internationalized names, no automatic prefetch, no sensitive data in the URL, and correct binding between the external session and authenticated user. Test the case where the completion notification never arrives and make sure manual retry or cancellation remains possible.

Weak Versus Strong Interview Answers

Strong answers quote requirements carefully. “Must” behavior should become a blocking conformance test. “Should” behavior needs a documented policy and exception rationale. Optional behavior needs negotiation tests, not assumptions.

Interview Questions with Model Answers

1. How would you test a client that advertises elicitation but only supports form mode?

Model answer: I would initialize with a form-only capability, confirm a valid form request is presented, and confirm URL mode is never sent or is rejected safely if a faulty server sends it. I would also test an empty legacy capability object according to the target revision. Evidence includes initialization messages, the attempted request, visible user options, and the final protocol error or result.

2. A sampling request returns valid JSON but unsafe content. Is it a protocol pass?

Model answer: It can pass envelope validation and still fail the product's safety gate. I would report two results: protocol conformance and semantic policy outcome. That separation keeps transport regressions diagnosable while preventing a structurally valid but harmful generation from being treated as acceptable.

3. The user clicks accept in URL elicitation, but the external flow fails. What should the client do?

Model answer: Accept means consent to open the flow, not business completion. I would keep the original operation pending or recoverable according to product policy, validate any completion notification by elicitation ID and client connection, ignore duplicates, and expose manual retry or cancel if completion never arrives.

4. How would you test sampling during deprecation?

Model answer: I would inventory supported revisions and existing consumers, keep conformance coverage for negotiated revisions, add telemetry for use, and place the feature behind an interface that can route to the migration approach. New designs should not assume long-term core support. Removal tests begin only when the selected protocol revision and compatibility policy permit it.

5. A server sends elicitation without an originating request. What is your response?

Model answer: I would reject or ignore it according to the implementation contract, record the protocol violation, and verify no UI or external navigation occurs. Then I would add a trace assertion that every server-to-client request is associated with the client operation that caused it.

Scenario Prompt: Diagnose a Cross-Client Failure

One client completes a tool call with form elicitation, another hangs, and a third sends a cancellation after the server has already returned. Explain your investigation.

A strong response freezes versions and capabilities first. Compare traces at initialization, request association, UI action, result serialization, and terminal cleanup. The hanging client may never send decline or cancel, while the late-cancellation client may have a race in its state machine. Build a deterministic transport harness before blaming model behavior, then add interleaving tests for cancellation and response ordering.

Score the Answer

Use a zero-to-four scale for each dimension:

A candidate scoring 17 or more should still receive a concurrency follow-up. Bidirectional requests create ordering failures that a happy-path explanation can hide.

For practical repetition, take these protocol states into a gamified QA practice arena and rehearse explaining both the failed invariant and the evidence that localizes it.

Official Sources and Further Reading

Use the current official pages for sampling and elicitation, then review the accepted sampling deprecation proposal. Always align test expectations with the exact protocol revision implemented by the client and server.

Conclusion: Test the Relationship, Not Just the Message

MCP sampling and elicitation testing interview questions reward engineers who can reason across negotiation, correlation, user control, schema validation, nondeterminism, and lifecycle change. The key move is to keep each evidence layer separate while tracing one user operation end to end.

Practice with rejected capabilities, cancelled requests, unsafe data paths, late notifications, and revision mismatches. If your answer can identify the responsible boundary and the next falsifiable test, it demonstrates the protocol judgment expected from an agentic QA or SDET role.