MCP & tool interfaces interview questions
7 questions across 2 sections, in the order you would learn them. Every answer here is one that works — but an answer you have read is not an answer you can give, so use Test yourself and say it out loud first.
What MCP is for
Read the section that teaches thisIf this comes up in an interview
What is MCP and what problem does it solve?
A standard protocol for exposing tools, resources and prompt templates to model clients. It removes the repetition of rewriting the same integration per application and per provider format, so a capability written once works with any client that speaks it.
Then they push further
How is that different from defining tools in your API call?
Tools in an API call are defined by your application for that request. MCP puts them behind a server speaking a standard protocol, so one integration can be used by many clients and agents without each rewriting it.
What are the security concerns with MCP servers?
A server's tool descriptions and results go straight into the model's context, so a malicious or compromised server can inject instructions. Servers often hold credentials too. Install only servers you trust, scope their credentials, and review what they expose.
What gets marked up. Marked up for describing it as a standard interface between agents and tools, and for raising the trust questions unprompted.
What is the difference between a tool and a resource in MCP?
A tool is an action the model can invoke and which usually changes something. A resource is read-only data the client can fetch, addressed by URI. Most servers implement only tools.
When would you not use MCP?
A single application with a few tools that nobody else needs. Plain function calling is simpler and has fewer moving parts. The protocol pays off with multiple clients or when you want to consume servers written by others.
Building and shipping a server
Read the section that teaches thisIf this comes up in an interview
Have you built an MCP server?
Answer with the specific thing you built, what it wrapped, and one design decision you had to make, such as how you capped result size or handled auth. This is asked to find out whether you have shipped one, so a concrete link beats a description of the protocol.
What makes a good tool definition?
One clear job, a description that says when to use it rather than only what it does, bounded results, readable errors, and argument names a person would use. The description is what the model reads to choose between tools, so vague ones cause wrong selection.
How do you handle credentials in an MCP server?
The server reads them from the environment and the model never sees them. Never accept a key as a tool argument, because arguments are generated by the model and end up in conversation history.
What happens if a server exposes fifty tools?
Selection accuracy degrades, because the model is choosing between too many similar descriptions. Group related operations behind fewer tools with a mode argument, or split by domain into several servers.
These are the questions for one topic. The whole question bank covers every topic on the site.