AI Engineering Interview Questions: Agents & MCP

In MCP, tools are executable functions exposed by an MCP server that allow the AI model to perform actions and interact with external systems (e.g., calling an API, running a query, writing a file). This is distinct from resources (read-only data like files or DB records) and prompts (reusable prompt templates). Tools follow a request/response pattern and are the primary mechanism for giving agents 'agency' to affect the world.

This statement has the roles reversed. In MCP, the server is the component that hosts and exposes tools, resources, and prompts. The client (typically embedded in the AI application or agent framework) connects to one or more MCP servers and relays their capabilities to the AI model. Think of servers as 'capability providers' and clients as 'capability consumers'.

MCP defines a structured JSON-RPC lifecycle for tool usage. An agent first calls tools/list to enumerate all tools exposed by the server (receiving their names, descriptions, and input schemas). Once the model decides which tool to invoke, it sends a tools/call request with the chosen tool name and the required arguments. This two-step pattern — discover then invoke — is fundamental to how MCP agents operate.

This statement is false. While the request/response pattern is the most common interaction, MCP supports server-to-client notifications. For example, an MCP server can send progress notifications for long-running tool calls and emit log messages proactively. The protocol defines server-initiated messages alongside the client-request/server-response model, so it is not strictly one-directional.

The Model Context Protocol defines exactly three server-side primitives: Tools (callable functions that may produce side-effects, like writing to a database), Resources (read-only data exposed via URIs, like files or API responses), and Prompts (parameterized templates the client can retrieve and insert into a conversation). Knowing all three and their distinctions is foundational for MCP-based AI agent development.

This is exactly why MCP scales the way it does in practice — a host like an IDE or a coding assistant typically maintains connections to several servers simultaneously (a filesystem server, a Git server, a ticketing-system server, and so on), each represented by its own client under the hood, and merges everything they expose into one combined registry the model sees as a single flat set of available tools. The model itself doesn't need to know or care which underlying server a given tool came from.

Separating the message format (JSON-RPC 2.0) from the transport (stdio or Streamable HTTP) is what makes MCP's two transports genuinely interchangeable from the protocol's point of view — a server author writes one set of request/response handlers and the transport is a deployment choice, not a rewrite.

All three statements accurately reflect the MCP specification. Statement 1 is correct: the Host is the user-facing application (e.g., Claude Desktop, an IDE extension) that owns and manages multiple MCP Client instances. Statement 2 is correct: each individual MCP Client instance maintains a 1:1 connection with exactly one MCP Server — a Host achieves multi-server connectivity by spawning multiple Clients, not by multiplexing within one Client. Statement 3 is correct: MCP Servers are not purely passive — the spec explicitly defines server-initiated notifications such as notifications/progress (progress updates), notifications/resources/updated (resource change events), and notifications/resources/list_changed (capability list changes). These allow a Server to push information to a Client without waiting for a per-message request. Option (b) is therefore wrong because it mischaracterizes servers as purely request-driven. Option (c) is wrong because a single Client instance maps to one Server. Option (d) is wrong because the Host and Client are distinct architectural roles.

The correct lifecycle order for an MCP agent turn is: (1) The host forwards the user message to the LLM. (2) The LLM decides to call a Tool and returns a structured tool-call request. (3) The MCP Client sends a tools/call request to the appropriate MCP Server. (4) The Server executes the tool and returns a result to the Client. (5) The Client delivers the result back to the Host, which appends it to the conversation context. (6) The Host sends the updated context (including tool result) back to the LLM for the final response. This ordering reflects the request-response, client-driven nature of MCP and the role of the host in managing LLM interactions.

MCP is essentially "USB-C for tools": a common wire format so the M×N problem of wiring M apps to N tools collapses to M+N. It standardizes capability discovery and invocation (tools/resources/prompts), keeping integrations portable across model hosts.

The choice tracks directly to deployment shape: stdio is for a server that lives and dies with its one local host process, trading reachability for zero network overhead and no auth machinery; Streamable HTTP is for a server that exists independently of any one client, trading the simplicity of a local process for the ability to serve multiple remote clients at the cost of a real network and authentication story. Picking the wrong one either forces unnecessary auth/network complexity onto a purely local integration, or makes a genuinely shared service impossible to reach from more than one place.

Discovery is deliberately dynamic rather than a one-time handshake: capability negotiation establishes what kinds of things are worth listing, the list methods enumerate the current specifics, and change notifications keep a long-lived session from silently drifting out of sync with what the server actually offers.

The lifecycle moves from transport, to capability negotiation, to enumerating the specifics, to actual use, and finally to staying current: you can't negotiate capabilities before the connection exists (a before b), you can't usefully call tools/list before you know the server even supports the tools primitive (b before c), you can't invoke a tool by name before you've discovered what it's called and how to call it (c before d), and change notifications are by definition something that happens after the initial discovery-and-use cycle is already underway (e last).

The Model Context Protocol (MCP) defines a strict client-server architecture where the host application (e.g., an IDE or chat client) spawns or connects to MCP servers. The LLM itself never directly calls MCP servers; instead, the MCP client (embedded in the host) mediates all communication. Tool results flow back to the host, which appends them to the context before re-querying the model. Option C is incorrect because MCP servers expose capabilities via JSON-RPC 2.0, not REST. Option D is incorrect because MCP servers are stateful — they maintain a session with the client. Option A is the only accurate statement.

In MCP, a server advertises three distinct capability primitives: Tools (callable functions/actions the model can invoke with side effects), Resources (read-only contextual data the host can attach to the context, URI-addressed), and Prompts (reusable prompt templates or workflows the server exposes). 'Samplers' is not an MCP server primitive — sampling refers to the client-side capability that allows a server to request the host to perform an LLM completion on its behalf (a server-initiated inference request). Knowing all three correct primitives and distinguishing them from sampling is essential for MCP architecture design.

The bug is on line 6, where "method": "notifications/initialized" is assigned inside init_notification. This entire block (lines 5–9) constructs and sends the notifications/initialized notification before the initialize request is ever sent (lines 13–23). According to the MCP protocol, the correct handshake order is: (1) client sends initialize, (2) server replies with its capabilities, (3) client sends notifications/initialized to confirm it has processed the response. Sending notifications/initialized first violates the protocol handshake sequence — the server has not yet established a session and will reject or ignore the premature notification, causing the subsequent initialize request to fail. The fix is to move the initialize request block before the notifications/initialized notification block and wait for the server's response in between.

Stdio (a) and Streamable HTTP (b) are MCP's two transports, matching the local-single-client and remote-multi-client use cases respectively, with Streamable HTTP adding real network auth since it can be reached over the internet. Underneath either one, MCP messages are JSON-RPC 2.0 (c) — the transport is purely how the bytes move, not what they say. Streamable HTTP is explicitly the successor to the older combination of separate HTTP POST and SSE streams for remote connections (d). MCP never requires gRPC (e) — its two defined transports are stdio and Streamable HTTP, full stop.

Rooting the filesystem server at / means every tool call it exposes — read_file, write_file, list_directory, whatever the server provides — can reach anywhere on disk the host OS user can, far beyond the one project directory the assistant actually needs. Least privilege means scoping --root to the specific project path, so even if a call is manipulated by injected content or a bug in the assistant, the blast radius is bounded to that one directory instead of the whole machine.

MCP standardizes the wire protocol for connecting a server, not the trust or safety of what's on the other end of it — those are still the integrator's job. The consequence is that connecting a server is a genuine security decision, not a config toggle: it grants that server whatever access it's configured with, and its output flows straight into the model's context as untrusted data. Least privilege, provenance/trust review, and treating server output like any other untrusted input are the concrete checks that follow from that.

The Model Context Protocol (MCP) defines a strict lifecycle for server-to-client sampling requests. The correct order is: (1) The MCP server calls sampling/createMessage on the client, (2) The client applies its own system prompt injection and model preferences, (3) The client selects a model and issues the actual LLM call, (4) The LLM response is returned to the client, and (5) The client forwards the completion result back to the server as the sampling/createMessage response. This design is intentional — the client retains control over model selection and prompt augmentation, preventing servers from directly driving arbitrary LLM calls without user-side oversight.

This code has a critical bug on line 9. The tool result is being sent back using notifications/message (a one-way notification) instead of a proper JSON-RPC response. In MCP, tool call results MUST be returned as a JSON-RPC response object with the same id as the original request (i.e., via a tools/call response), not as a notification. Notifications have no id field and are fire-and-forget; using one here means the client can never correlate the result with its pending request, causing the agent to hang indefinitely waiting for a response that will never arrive. Line 9 should construct a proper JSON-RPC result response using the original request's id.

MCP's roots capability allows clients to expose filesystem or URI namespaces to servers, and the protocol mandates that when the set of roots changes (e.g., the user adds or removes a workspace folder), the client MUST send a notifications/roots/list_changed notification to each connected server. Servers that declared roots support in their capabilities can then call roots/list to re-fetch the updated list. Option A is wrong because servers cannot push root changes — roots are owned by the client. Option C is wrong because there is no roots/sync method in the spec. Option D is wrong because re-initializing the entire session is not required or correct — a lightweight notification suffices.

MCP is an open, client-server protocol that gives a uniform way to expose tools, resources, and prompts to LLM hosts (a), and its central payoff is write-once/reuse-everywhere interoperability across compatible clients (b). It does not remove the security burden: a server runs with whatever access you give it and the data it returns enters the model's context, so an untrusted or compromised server is a genuine injection/exfiltration risk (c) — least privilege and review still apply. MCP does not replace function calling (d); it is the transport/standard through which tool definitions and calls flow — the model still decides which tool to invoke. And it offers no guarantee against malicious server output misleading the model (e); content returned over MCP is untrusted data like any other.

Writing plain logs to stdout on a stdio server (a) is a very real, easy-to-hit bug, because that channel is reserved for the protocol's own JSON-RPC messages — any stray print statement can corrupt the stream. Over-broad scope grants (b) are a classic least-privilege failure that magnifies the impact of any single compromised server. Skipping the re-list after a change notification (c) leaves a client silently out of sync with what the server actually offers. Capability mismatches are meant to be negotiated explicitly at connection time (e), not discovered as confusing runtime failures. The protocol explicitly does not promise guaranteed notification delivery (d) — that's a documented best-effort limitation, and code that assumes otherwise will eventually miss an update.

On the stdio transport, stdout is the wire — every line written there is expected to be a well-formed JSON-RPC message the client will try to parse. The console.log debug line on line 2 also writes to stdout, so it gets interleaved with the real protocol output on line 4, breaking message framing: the client either fails to parse the log line as JSON-RPC or gets confused about where one message ends and the next begins. The fix is to send anything that isn't a protocol message to stderr (console.error) instead, which stdio-transport clients don't treat as protocol data.