MCP Protocol Upgrade and OAuth Failure Interview Scenarios

MCP upgrades fail at boundaries: a client and server negotiate different assumptions, a capability appears without working behavior, an HTTP request omits protocol context, or an OAuth token crosses the wrong resource boundary. Senior AI QA candidates should turn those failures into deterministic transcripts and compatibility evidence.

These twenty-four scenarios cover lifecycle, transport, schemas, discovery, consent, scopes, audience, and rollout. Answer with exact request order, status classes, cached state, negative cases, and artifacts. "Test old and new versions" is only the title of a plan.

Start with the Handshake

The official MCP lifecycle specification defines initialization as version agreement, capability negotiation, and implementation exchange, followed by the client's initialized notification. That state machine is the first upgrade contract to test.

Persist raw JSON-RPC messages with secrets redacted, transport metadata, client and server implementation identifiers, negotiated protocol, advertised capabilities, and connection termination reason.

Initialization and Version Negotiation

1. Why must initialize be tested as a state transition rather than a normal method?

It establishes the rules for every later message. Test initialize as the first interaction, duplicate initialize, normal requests before the response, and server requests before initialized. The expected behavior follows the negotiated lifecycle rather than application tool logic. Preserve a timestamped transcript so an apparent tool timeout can be traced back to a client that never reached ready state.

2. How would you test a client upgrading before its server fleet?

Build a compatibility matrix of client-supported and server-supported protocol revisions, including overlap and no-overlap cases. For each pair, assert the returned protocol, client acceptance, capability set, and disconnect behavior. Canary against representative servers, not only one fixture. A client must not silently serialize new fields under an older negotiated contract simply because the connection stayed open.

3. Why should an unsupported server-selected version cause a clean disconnect?

Continuing would make message and capability semantics ambiguous. The client should record requested and returned versions, avoid normal requests, close the transport, and present an actionable compatibility error without tokens or payloads. Test that no automatic reconnect loop floods the server. Fallback is valid only when both sides explicitly support the chosen revision, not when a parser happens to accept it.

4. How would you verify the initialized notification boundary?

Delay, omit, duplicate, and reorder the notification while observing whether the server begins normal server-initiated behavior. After successful initialize, send it once and exercise an advertised feature. The trace should distinguish response receipt from readiness notification. A server that emits operational requests too early can race a client still configuring handlers, producing intermittent upgrade failures.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {"roots": {"listChanged": true}},
    "clientInfo": {"name": "qa-compat-client", "version": "test-build"}
  }
}

Capability and Schema Contracts

5. Why should capability claims be tested behaviorally?

An advertised flag is only a promise. For every negotiated capability, invoke its happy path, malformed input, unsupported subfeature, notification behavior, and shutdown. Conversely, request a feature that was not advertised and verify predictable rejection or absence. Build the matrix from negotiated capabilities at runtime so tests do not assume that all server builds expose the same optional functions.

6. How would you test a tool schema change during an upgrade?

Snapshot discovered schemas and classify additions, removals, type changes, required-field changes, defaults, and semantic changes. Generate valid old and new calls plus boundary-invalid inputs. Verify that clients refresh discovery when notified or reconnected, validate before invocation, and display migration errors. A compatible-looking optional field can still be breaking if the server changes its default side effect.

7. Why test error envelopes independently from tool errors?

Protocol or JSON-RPC failures and a tool's domain failure have different ownership and recovery. Inject malformed JSON, wrong identifiers, unknown methods, invalid parameters, and a valid tool call returning a domain error. Confirm correlation, structure, and retry policy for each. A client that treats every error as retryable can duplicate side effects or hide a protocol incompatibility behind repeated calls.

8. How would you verify list-changed behavior across mixed versions?

Start with a known tool or resource list, mutate server inventory, and observe behavior with the capability advertised and absent. Ensure the client refreshes once, validates the new schema, removes unavailable entries, and does not execute a stale cached definition. Inject duplicate and burst notifications. If a negotiated revision lacks the behavior, reconnect or explicit refresh policy must be tested instead of assumed.

Transport and Session Failures

9. How would you test the protocol version header on HTTP requests?

After negotiation, capture every subsequent HTTP request and assert the negotiated value is present where required. Test missing, malformed, stale, and unsupported values, including reconnect after a server upgrade. The server should reject incompatible context without processing a tool side effect. Logs must record the rejected version and request correlation while redacting authorization headers.

10. Why should stdio logging be tested separately from protocol output?

If diagnostic text enters the protocol stream, clients may parse it as malformed messages. Run startup warnings, verbose logs, stack traces, and non-ASCII application data while asserting that framed protocol output remains clean and diagnostics use the intended error channel. Also test buffering and abrupt child exit. The artifact should include byte-level boundaries when line-oriented logs obscure corruption.

11. How would you test disconnect during a long-running tool call?

Inject a break before server acceptance, after acceptance, during progress, and after completion before response delivery. Record whether the operation is cancellable, continues, or has unknown status. On reconnect, the client must not blindly repeat a side effect. Use operation identifiers and authoritative state checks. The test outcome includes resource state, not merely whether a new session connected.

12. Why test duplicate and out-of-order messages?

Reconnect logic, intermediaries, or application defects can surface repeated responses and notifications. Verify request identifiers correlate exactly once, stale responses do not satisfy new calls, and duplicate notifications are idempotent. For state-changing tools, duplicate client submission requires an application-level idempotency strategy. Protocol correlation prevents confusion but does not by itself guarantee exactly-once external state.

OAuth Discovery and Client Identity

13. How would you test protected resource metadata discovery?

Begin without authorization, inspect the server challenge, fetch only permitted metadata locations, and validate issuer and authorization-server relationships before following them. Test missing metadata, malformed JSON, cross-origin redirects, unreachable endpoints, and inconsistent cache updates. Prevent arbitrary metadata URLs from becoming server-side request forgery paths. Preserve challenge and discovery transcripts without bearer tokens.

14. Why must issuer paths be covered in authorization discovery tests?

Tenant-specific issuers can include path components, and discovery endpoint construction differs from a root issuer. Build fixtures for root and nested issuers, supported endpoint forms, redirects, and ambiguous metadata. Verify deterministic priority and issuer equality checks. A client that simply appends one well-known suffix may work in development but fail or contact the wrong tenant in production.

15. How would you test client metadata and redirect URI validation?

Serve valid metadata, mismatched client identifiers, invalid JSON, changed cache content, and redirect URI variants involving case, path, port, fragment, and wildcard attempts. Authorization must accept only registered values under the applicable mechanism. Test metadata fetch failures without falling open. The evidence should connect the requesting client identity, approved redirect, and callback that receives the code.

16. Why is per-client consent important for an MCP proxy?

A user's existing downstream session must not imply consent for every MCP client. Test two clients under one user, approve one, then attempt authorization from the other using altered redirects and existing cookies. Consent records must bind user, client, scopes, and redirect context. The MCP security best practices describe per-client consent and exact redirect validation as protections against confused-deputy flows.

Tokens, Audience, and Scopes

17. How would you test access-token audience binding?

Issue tokens intended for the MCP resource, another MCP server, and a downstream API. Only the correctly intended token should be accepted. Test multiple audiences according to server policy, malformed claims, expired tokens, and changed resource identifiers. The server must not forward an unrelated token downstream. Record validation result and resource identity, never the raw token in test reports.

18. Why distinguish 401 recovery from 403 scope escalation?

A missing, invalid, or expired token requires authentication recovery; an authenticated token lacking permission requires a scope decision. Test status, challenge fields, cache invalidation, and user interaction separately. Retrying a 403 with the same token creates a loop, while treating every 401 as a broad re-consent request may request excess permission and degrade security.

19. How would you test incremental scope challenges?

Start with the minimum scope for a read operation, then invoke a write requiring additional permission. Verify the 403 challenge identifies the operation's required scope, the client presents a clear step-up decision, and a denied escalation leaves the original token usable for reads. After approval, confirm the new token's resource and scope. Test malformed and unexpectedly broad challenges rather than accepting them automatically.

20. Why key token caches by more than user identity?

The same user may connect to several resources, authorization servers, clients, tenants, and scope sets. Cache entries should bind those dimensions plus expiry and token type. Test that a token for one MCP server is never reused for another and that step-up does not overwrite a narrower token incorrectly. Logout, revocation, and account switching must invalidate the correct entries without leaking across sessions.

The official MCP authorization specification requires authorization on each HTTP request and resource-specific token validation. Those rules should appear as assertions in the transport harness, not remain documentation-only assumptions.

Upgrade Rollout and Diagnosis

21. How would you build an MCP compatibility test matrix?

Cross supported client revisions, server revisions, transport modes, authorization mechanisms, and optional capability profiles. Use pairwise reduction for low-risk combinations but retain every critical boundary and no-overlap case. Each cell records handshake outcome, discovered contract, representative calls, errors, shutdown, and auth result. Publish unsupported combinations explicitly so absence of testing is not mistaken for compatibility.

22. Why run dual-stack canaries before broad migration?

Canaries expose real discovery metadata, proxies, network behavior, token issuers, and server inventories that fixtures may miss. Route isolated test identities through old and new paths, compare transcripts and authoritative side effects, and define rollback triggers before traffic. Do not share mutable token caches between variants during diagnosis. A canary must be observable enough to explain divergence, not only report availability.

23. How would you use MCP Inspector without making it the release test?

Use the official MCP Inspector to examine connection settings, negotiated capabilities, tools, resources, prompts, notifications, custom inputs, and error responses during exploration. Convert every discovered regression into an automated transcript or contract test. Manual inspection is excellent for understanding a failure, but it is not repeatable coverage for the full version, transport, and OAuth matrix.

24. Why must rollback include authorization state?

Returning binaries to an older build may leave new client registrations, redirect metadata, scopes, cached tokens, consent records, or discovery caches active. Define which state is backward compatible, which must be invalidated, and how users recover. Rehearse rollback with in-flight sessions and revoked credentials. The release is not reversible until both protocol behavior and authorization state return to a known secure condition.

Make a Protocol-Level Hiring Decision

Strong candidates model lifecycle and authorization as explicit state machines. They capture negotiation before testing features, distinguish protocol failures from domain failures, bind tokens to resources, and investigate transport ambiguity through authoritative state.

The decisive recommendation is to block an upgrade whenever unsupported negotiation continues, capability claims lack behavior, or OAuth recovery widens trust silently. Ship only the compatibility cells and authorization paths supported by reproducible transcripts, then expand through measured canaries.