What Is MCP (Model Context Protocol)?

Short answer: MCP, the Model Context Protocol, is an open standard for connecting an AI application to outside systems. Through one JSON-RPC message format, the application can discover and call external tools, read external data, and load reusable prompts from independent servers. It replaces a separate custom integration per tool with one protocol any compliant application can speak.

The problem it solves is combinatorial. Without a standard, connecting five AI applications to twenty tools means a hundred integrations. With one, it means twenty servers that every application can use.

Quick Overview

The split matters. A server is written once by whoever owns the system being exposed, and it does not need to know which application will call it.

How a call actually flows

The host starts a client for each server it wants to use. The client asks the server what it offers, and the server returns its list of tools with names, descriptions, and parameter schemas.

Those descriptions are then given to the model. When the model decides to act, it names a tool and supplies arguments. The client sends that as a JSON-RPC request, the server runs it, and the result comes back into the model's context for the next step.

This is the same loop described in what is agentic system design. MCP standardizes the tool half of it.

Transports, and where each one fits

Local servers run over standard input and output, as a child process on the same machine. That suits developer tools and anything touching local files.

Remote servers run over streamable HTTP, with OAuth as the recommended way to obtain tokens. An older HTTP transport built on server-sent events has been deprecated.

The design decision worth knowing

The protocol is stateless at its core. There is no session handshake and no session identifier to track. Any request can be served by any server instance behind a plain round-robin load balancer.

That is a genuine system design consequence, and it is why this is worth discussing in an interview. A stateful protocol would force sticky sessions, a shared session store, and a gateway that inspects traffic to route it. A stateless one turns an MCP server into an ordinary horizontally scaled HTTP service. Clients can also cache the tool list for a period the server specifies, which removes a round trip from every conversation.

This is the familiar stateful versus stateless architecture trade-off applied to a new protocol, not a new idea.

What to be careful about

Tool descriptions are an attack surface. The model reads them and acts on them, so text that arrives from a server can influence behavior. Treat a third-party server with the caution you would apply to any untrusted input.

Permissions need a real boundary. A server that exposes a database and a server that exposes a calendar should not carry the same authority. Scope each connection, and require approval for actions that move money or delete data.

A protocol does not fix tool design. Badly named tools with vague descriptions make the model guess, whether or not they are served over MCP. The naming and granularity work still belongs to you.

How to Prepare

• Learn the agent loop first. MCP only makes sense once the loop does. Start with what is agentic system design.
• Do not add agents to solve a tool problem. How do you design a multi-agent system explains why that is usually the wrong fix.
• Be able to compare it to plain function calling. Function calling is the model asking to act. MCP is how that request reaches a system somebody else owns. Interviewers like candidates who keep the two separate.
• Connect it to retrieval. Servers expose data as well as actions, so the retrieval answers apply: retrieval-augmented generation and vector databases.
• Study the tool chapter. Grokking the AI System Design Interview covers tool design in depth, including naming, granularity, and failure handling. The lesson on tool use and function calling is the place to start.