Interview: Model Context Protocol (MCP)

What you will be able to do

• ✓Explain the problem MCP solves
• ✓Describe hosts, clients, servers and transports
• ✓Compare tools, resources and prompts
• ✓Compare MCP with direct function calling
• ✓Discuss MCP security risks and defences

The idea, in plain English

MCP is newer than the other topics, so interviewers use it to see whether you keep up - and whether you understand why a standard protocol matters.

Expect architecture questions (host, client, server), primitive questions (tools vs resources vs prompts), and security questions about connecting to servers you did not write.

Module 4 built a server, connected an agent to it, and used community servers - use those as examples.

Worked example: Fourteen MCP questions answered with the server and multi-server agent built in Module 4.

Basic: What is the Model Context Protocol?

An open standard for connecting AI applications to tools and data sources. A tool provider writes one MCP server, and any MCP-capable app can use it - instead of every app writing its own integration for every tool.

• •Often compared to USB-C for AI tools.
• •Lesson 4.1.

Basic: What problem does MCP solve?

Without a standard, M apps and N tools need M x N custom integrations. With MCP, each app implements the client side once and each tool implements a server once: M + N.

• •Reuse: one server works with many agents and apps.
• •Tools can be added without changing the agent's code.

Basic: What are the host, client and server in MCP?

The host is the AI application the user works with. Inside it, an MCP client keeps a connection to one MCP server. The server exposes tools, resources and prompts.

• •One client per server connection.
• •A host can connect to many servers at once. Lesson 4.2.

Intermediate: What are tools, resources and prompts in MCP?

Tools are actions the model can call (model-controlled). Resources are data the application can read and add to context, identified by URIs (application-controlled). Prompts are reusable templates a user can pick (user-controlled).

• •Not everything should be a tool - read-only data fits resources.
• •Lesson 4.5.

Intermediate: What transports does MCP use?

stdio, where the host starts the server as a local process and talks over standard input and output, and streamable HTTP for remote servers. Messages are JSON-RPC 2.0.

• •stdio: simple and local, no network.
• •HTTP: shared, remote servers - needs authentication.

Intermediate: What happens when an MCP client connects to a server?

They initialise: exchange protocol versions and capabilities, then the client can list the server's tools, resources and prompts and call them. At the end the connection is closed.

• •Capability negotiation lets both sides support different features.

Intermediate: MCP or direct function calling - when do you use which?

Function calling is how the model asks for a tool. MCP is how tools are packaged and connected. Use plain functions for a few tools inside one app; use MCP to share tools across apps, use community servers, or keep tools in a separate process.

• •They work together: MCP tools are turned into function-calling tools for the model.

Intermediate: How do you build an MCP server in Python?

With the official SDK's FastMCP: create a server, decorate Python functions as tools or resources - their type hints and docstrings become the schemas - and run it over stdio or HTTP.

• •Lesson 4.3 builds one; Lesson 4.4 connects an agent to it.

Advanced: What are the security risks of MCP servers?

A server is code and text you did not write. Tool descriptions can hide instructions to the model (tool poisoning), tool outputs can carry prompt injections, servers can be over-privileged or replaced by a malicious update, and remote servers need proper authentication.

• •Install only trusted servers and pin versions.
• •Give each server the least access it needs.
• •Show and approve tool calls that change things.

Advanced: How do you use several MCP servers in one agent safely?

Connect each through its own client, prefix or namespace tool names to avoid clashes, give the agent only the tools the task needs, and keep risky servers behind approval.

• •Too many tools from many servers confuse the model.
• •Lesson 4.7 combines servers into one agent.

Advanced: How would you handle authentication for a remote MCP server?

Use the transport's authorisation (MCP specifies OAuth-based flows for HTTP servers), issue tokens per user with limited scopes, and never put secrets in tool descriptions or prompts.

• •The server must check permissions for every call, not trust the client.

Advanced: What would you check before using a community MCP server?

Who maintains it, what access it needs (files, network, credentials), what its tools really do, how it handles errors and secrets, and whether you can pin a version and run it isolated.

• •Read the code or run it in a sandbox first.
• •Lesson 4.6 uses community servers.

Advanced: How do you debug an MCP integration?

Test the server on its own with an inspector tool, check the initialisation and the listed tools, log JSON-RPC messages, and trace the agent run to see which tool calls were made and what came back.

• •Most problems: wrong command or path for stdio, schema mismatches, or errors swallowed by the server.

Advanced: Where does MCP fit in a production agent architecture?

As the integration layer between the agent and internal systems: each system (tickets, CRM, docs) gets an MCP server owned by its team, with its own auth and limits, and agents connect to the servers they need.

• •Teams can change a server without changing every agent.
• •Central policies: logging, rate limits, approvals.

Interview questions