MCP — Model Context Protocol interview questions
MCP — Model Context Protocol questions a AI engineer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What is the Model Context Protocol, and what problem does it solve?
The strongest answer: An open protocol that standardises how AI applications connect to tools and data: a server exposes its capabilities once and any compatible application can use them, instead of a custom integration for every app-and-tool pair
Why it works: Exactly — every application times every tool becomes one integration per side. The application discovers what each server offers when it connects.
- One protocol between apps and tools.
- Build the integration once, as a server.
- Any compatible application can connect.
- A standard is not a safety check.
In MCP, what are the host, the client and the server?
The strongest answer: The host is the AI application the user works in; inside it, each client keeps a connection to one server; a server is a separate program or service offering tools, resources and prompts
Why it works: Exactly — and the host is where policy lives: it decides which servers to connect, what the model sees and which calls need the user’s consent. The model never contacts a server itself.
- Host contains clients; clients reach servers.
- Host: the AI application.
- One client per server connection.
- The host decides what the model sees.
An MCP server can offer tools, resources and prompts. What is each one, and who decides when it is used?
The strongest answer: Tools are actions the model chooses to invoke; resources are data the application decides to read into context; prompts are templates the user picks. Model-controlled, application-controlled and user-controlled, in that order
Why it works: Exactly — the split is about control. Knowing who triggers each one tells you where consent and review belong.
- Three primitives, three controllers.
- Tools: the model invokes them.
- Resources: the application attaches them.
- Prompts: the user selects them.
An MCP server can run locally over standard input and output, or remotely over HTTP. How do you choose?
The strongest answer: Local when it needs the user’s machine — files, local apps — and runs as a child process with that user’s rights; remote when it is a shared service for many users, which then needs real authentication
Why it works: Exactly — the transport follows where the data lives and who shares the server, and it changes the security model: process rights locally, authentication remotely.
- Transport follows data and sharing.
- Local: the user’s machine and rights.
- Remote: shared, so authenticated.
- Same messages, different trust model.
You connect your agent to an MCP server. How do that server’s tools actually end up being used by the model?
The strongest answer: The client asks the server which tools it offers; my application adds those definitions to the model’s tool list; when the model calls one, the application routes it to that server and returns the result
Why it works: Exactly — discovery at connection time, then ordinary tool calling with the application in the middle. That middle is where you filter, confirm and log.
- Discover, present, route, return.
- The client lists the server’s tools.
- They join the model’s tool list.
- Your application brokers every call.
You are asked to put your company’s internal REST API, more than a hundred endpoints, behind an MCP server for agents to use.
How do you decide what the server exposes?
The strongest answer: Design for the agent’s tasks, not one tool per endpoint: a few well-described task-level tools with tight schemas, results trimmed to what the model needs, actionable errors, and write actions separate and scoped
Why it works: Exactly — an API built for programmers is not an interface built for a model. Fewer, higher-level tools with lean results are easier to select and cheaper to run.
- Design tools for tasks, not endpoints.
- Few, well-described, tightly typed.
- Trim results to what is needed.
- Separate and scope the writes.
You are putting an MCP server on the internet for your customers’ AI applications. How do you handle who is calling and what they may do?
The strongest answer: OAuth-style delegated authorisation: the user consents, the client gets a token issued for this server, I validate it on every request, map it to that user’s scopes and act downstream with their rights
Why it works: Exactly — authentication says who, scopes say what, and a token meant for your server is the only kind you accept. The rest is ordinary API security, which is the point.
- A remote MCP server is an API.
- Authenticate every request.
- Accept only tokens issued for you.
- Act with the user’s scopes.
A team wants to connect the company’s coding assistant to a community MCP server they found online. You own the decision.
What is your review before you say yes?
The strongest answer: Treat it as third-party code with the assistant’s reach: who publishes it, a pinned and reviewed version, what it can access and which credentials it sees, and its tool descriptions read as untrusted text
Why it works: Exactly — it is a supply-chain decision plus a prompt-surface decision: the server’s descriptions and results reach the model, so they are input from a stranger.
- An MCP server is third-party code.
- Vet the publisher; pin the version.
- Map what it can reach.
- Treat its text as untrusted input.
You own the MCP rollout for a company with dozens of servers and several AI applications. What does the permission model look like?
The strongest answer: An allow-list of vetted servers; tools enabled per role and per task, reads separate from writes; sensitive actions confirmed by the user with the real arguments shown; credentials scoped per user; every call logged
Why it works: Exactly — control at three levels: which servers, which tools for whom, and which calls need a person. Logging is what lets you loosen it later on evidence.
- Control servers, tools and calls.
- Allow-list vetted servers.
- Enable tools per role; split writes.
- Confirm sensitive calls; log everything.