What is the Model Context Protocol (MCP) and what problem does it solve?
MCP is an open protocol originally introduced by Anthropic that standardizes how an AI host discovers and uses tools, resources, and prompt templates exposed by separate servers. It solves bespoke integration sprawl by giving each server one common interface, while leaving model orchestration, permissions, and user approval to the host.
How to think about it
MCP is an open protocol, originally introduced by Anthropic, that gives an AI application a standard way to discover and use tools, data, and prompt templates exposed by other programs. It solves bespoke integration sprawl: each server implements the interface once, and compatible AI hosts can reuse it instead of writing a separate connector for every backend.
Why MCP exists
Picture an internal support copilot and an IDE assistant. Both need access to Jira issues, GitHub commits, PostgreSQL metrics, and company documents in Google Drive.
Without a common protocol, each application needs a separate integration for each backend. That is two hosts multiplied by four backends: eight integration paths. Each path has to deal with authentication, argument formats, errors, retries, permissions, and changes to the underlying API. The code is rarely difficult. Keeping eight slightly different versions of “search tickets” working at 3 a.m. is the difficult part.
MCP changes the boundary. Each backend can be wrapped by an MCP server, and each AI application can implement one MCP client. The hosts and servers then speak the same protocol. This does not make the integrations free, but it prevents the same integration logic from being rebuilt for every host.
The value grows as the ecosystem grows. A new host can connect to existing servers. A new server can be used by existing hosts. That is the interoperability problem MCP is designed to solve.
How the protocol works
An MCP host is the AI application the user interacts with. It owns the conversation, connects the model, displays approval requests, and decides which external systems the model is allowed to use.
An MCP client is the host-side component that maintains a protocol connection to one server. A host commonly creates one client connection per MCP server.
An MCP server is a program that exposes capabilities through MCP. It may be a local process launched on the user’s computer, or a remote service. It is usually an adapter around an existing API, database, filesystem, or business system. It is not itself the language model.
When a connection starts, the client and server initialize and negotiate capabilities. In plain English, they announce which protocol behavior and features they support. The client can then discover the server’s available primitives:
| Primitive | What it represents | Example |
|---|---|---|
| Tool | An action the model may request | Search tickets |
| Resource | Addressable context the host can read | A document or schema |
| Prompt | A reusable prompt template | Incident investigation |
MCP messages use JSON-RPC 2.0, a standard format for request and response messages. The message format is separate from the transport, meaning the way messages travel. Local connections commonly use standard input and output, called stdio; remote connections can use Streamable HTTP.
The usual tool flow is:
- The server advertises a tool name, description, and input schema. An input schema is a machine-readable description of the arguments the tool accepts.
- The host makes that information available to the model through the model provider’s normal tool-calling interface.
- The model chooses a tool and supplies arguments.
- The host, not the model, sends the MCP request to the server.
- The server performs the action and returns a structured result.
- The host gives that result back to the model so it can continue the conversation.
That distinction matters. The model usually does not open a socket and speak MCP directly. The host translates between the model’s tool-call format and MCP.
A concrete example
Suppose an engineer asks:
Which checkout incidents increased after release 2026.08.27?
An incident-management MCP server advertises a tool called search_tickets. Its description says that query is a string and limit is an integer from 1 through 5. After the model chooses the tool, the host might send this MCP request:
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "search_tickets",
"arguments": {
"query": "checkout timeout after 2026.08.27",
"limit": 5
}
}
}The server could return:
{
"jsonrpc": "2.0",
"id": 7,
"result": {
"content": [
{
"type": "text",
"text": "INC-1842: checkout timeout after release 2026.08.27; 37 reports"
}
],
"isError": false
}
}The id lets the host match the response to the request. The server did not need to know whether the request came from an IDE, a web application, or a desktop assistant. It only needed to understand the MCP request and its own ticket-system logic.
The host can now pass the result to the model, which might search a second deployment server for changes made in that release. The model coordinates the investigation, but the host controls the connections and the servers perform the actual system operations.
The senior-level nuance
MCP standardizes the connection. It does not guarantee that the connection is useful.
| MCP standardizes | MCP does not guarantee |
|---|---|
| Message format and lifecycle | Correct business meaning |
| Capability discovery | Good tool descriptions |
| Machine-readable arguments | Safe authorization policy |
| Common tools, resources, and prompts | Low latency or reliable backends |
A server can be perfectly valid MCP and still expose a terrible tool. A tool named run_query with a vague description and an unrestricted database connection is technically interoperable, but operationally reckless. A schema can say that an argument is a string; it cannot tell the model that “date” means UTC release date rather than the customer’s local date.
MCP also does not replace the underlying API. The server still needs authentication, input validation, pagination, rate limiting, retries, and sensible error handling. For a write operation such as creating a ticket or deleting a file, the host should usually require explicit user approval. Credentials should be scoped to the smallest useful permission set.
Security is not automatic. Tool descriptions and returned resources can contain prompt injection, meaning hidden or malicious instructions in data that try to steer the model. A read-only tool can still expose confidential information. A write tool can still cause damage. A production host should use allowlists, isolated credentials, user confirmation for risky actions, audit logs, timeouts, and least privilege, meaning each tool receives only the access it actually needs.
There is also a cost. MCP adds a process or network boundary and another place for failures to occur. For one deterministic service with one fixed database query, calling a typed SDK directly is often simpler and faster. Routing that query through a model and a protocol adds unnecessary discovery, permission handling, and model uncertainty.
MCP is most valuable when capabilities must be reused across multiple hosts, models, teams, or vendors. It is less valuable when there is only one caller and the workflow is already known in code.
A failure mode you should know
A common first symptom is that the tool appears in the host, but the model repeatedly calls it with the wrong arguments or says it cannot access the data.
The usual cause is not the wire protocol. It is a poor tool contract: an ambiguous description, a required argument missing from the schema, inconsistent units, or backend errors that are swallowed and returned as empty results. The model sees a tool that technically exists but cannot infer how to use it reliably.
The fix is to make names and descriptions concrete, mark required arguments, validate every argument on the server, and return actionable errors. Log initialization, discovery, request IDs, redacted arguments, status, and duration. If a request times out, you want to know whether the host failed to connect, the server failed to authenticate, or the database spent 40 seconds scanning an unindexed column.
What they’ll ask next
Is MCP the same as function calling?
No. Function calling is the model-facing mechanism by which a model emits a structured request such as a tool name and arguments. MCP is the host-to-server integration protocol. A host can convert MCP tool definitions into the model provider’s function schema, then convert the model’s chosen function call into an MCP tools/call request. They complement each other.
Why not just use REST?
REST is a general web API style for accessing resources over HTTP. MCP is designed specifically for AI applications and adds standardized capability discovery, lifecycle messages, tools, resources, and prompts. An MCP server may wrap a REST API, but MCP is not simply another REST endpoint.
Does MCP make tool use secure?
No. It provides protocol rules, and some deployments provide authentication mechanisms, but it does not decide which user may invoke a tool, whether a tool is safe, or whether returned text contains malicious instructions. The host and server still need authorization, scoped credentials, validation, approval policies, and monitoring.
Say this in the interview: MCP is a JSON-RPC-based client-server contract that lets an AI host discover and use tools, resources, and prompts from many servers, replacing one-off integrations while leaving permissions and correctness to the surrounding system.