MCP Interview Questions (2026)
Covers the Model Context Protocol and MCP servers. See also all interview topics. These assume you already know the concept — if a section here is unfamiliar, read its linked concept page first; the questions test judgment on top of the concept, not the concept itself.
MCP
Your app connects to a GitHub MCP server and a filesystem MCP server. How many clients is it running?
Two. A client is a connection to one specific server, so a host talking to two servers keeps two separate clients running, each only ever talking to the server it was created for. Adding a third server means a third client, not a shared one handling all three.
Does adopting MCP change how tool calling itself works?
No. The model still decides to call a tool and returns an ordinary tool call the same way it always has; MCP is what makes the connection and the tool list available in the first place, without custom code written for that specific pairing. Take away the protocol and the tool-calling step looks identical — what disappears is the one-off integration code that got the two sides talking.
A team wants to add MCP in front of a single internal tool that only their own app will ever call. Worth it?
Probably not. MCP earns its cost when a tool needs to work across more than one application, or when the integration layer needs to change without a rewrite each time. A single app calling its own single tool has no second consumer to standardize for, so plain tool calling with no protocol layer in between is simpler and MCP adds nothing.
An MCP server exposes a file's contents as a resource rather than as a tool the model calls. Why design it that way?
Because reading the file doesn't need a decision — it's data the model can use for context, not an action with side effects or a result to reason about invoking. Tools are for things the model chooses to trigger; resources are for handing over data without needing the model to decide anything first. Modeling plain data as a tool the model has to call adds a decision point that wasn't actually needed.
You're about to connect your AI app to an MCP server you found online, run by someone you don't know. What's the actual risk?
The server can execute code and return data your application will trust by default — connecting to one is closer to installing a third-party package than clicking a link. A malicious or compromised server could return crafted data designed to manipulate the model, or simply misuse whatever access you've granted it. The caution is to only connect to servers you actually trust, not to assume the protocol itself vets who's on the other end.
MCP Server
Is GitHub's MCP server local or remote, and why does that distinction matter?
Remote — it runs on GitHub's own infrastructure and is reached over the network, acting on your GitHub account rather than anything on your machine. The distinction matters for trust and scope: a local server the host launches as a subprocess never sends anything off your computer, while a remote server means your data and requests travel to infrastructure you don't control.
You need search over an internal wiki with no existing MCP server for it. Build one, or look harder for an existing option?
Build one — an internal wiki is exactly the case nobody else could plausibly have published a server for. Building isn't free, since it becomes code you own, host, and have to keep secure, but there's no existing-server option here to reach for first. The "use an existing one" advice only applies when a system is common enough that someone already built and published a server for it.
A server adds a new tool while a client is already connected. Does the client automatically see it?
Only if that client was built to listen for change notifications — a server can announce when its tools change, but not every client listens for that signal. The reliable fallback, regardless of client, is a plain reconnect, which always picks up the current tool list.
Should an official, well-known MCP server be trusted more by default than a random one you found?
Being official narrows who's accountable if something goes wrong, but it doesn't remove the underlying exposure: any server you didn't write is still code you're choosing to run and data you're choosing to trust. The caution about connecting to servers applies to well-known ones too, just with more reputation backing them if something does go wrong.