Model Context Protocol (MCP)

The plain-language idea

Say you're building several AI applications, and each one needs to reach a handful of external tools and data sources: a filesystem, a database, a search API, an internal wiki. Without any shared standard, every application ends up writing its own custom, one-off integration code for every tool it wants to use. Connect N applications to M tools that way, and you've written roughly N × M separate integrations — and every new tool or every new application multiplies that further.

MCP (Model Context Protocol) is an open, standardized protocol that solves this the way most integration problems get solved: with a shared interface both sides can agree on. An MCP server exposes a tool, data source, or context provider (a filesystem, a database, a documentation index, whatever) using the protocol's standard shape. Any MCP client — any AI application built to speak MCP — can then consume that server without needing custom, tool-specific integration code. Build one MCP server for a tool, and every MCP-compatible application can use it. Build one MCP-compatible client, and it can reach every existing MCP server. N × M custom integrations becomes N clients + M servers, each side only needing to implement the protocol once.

This is deliberately a protocol-level concept, not an implementation detail: the value is in the shared contract itself — what a client can ask a server for, and what shape the server's answer comes back in — not in the specifics of any one server's code.

See it in a real thing: why an app would reach for MCP instead of a custom integration

// Without a shared protocol: one bespoke integration per tool, per application
async function getFileList() {
  /* app-specific code to talk to this one filesystem tool, its own way */
}
async function queryDatabase(sql: string) {
  /* a completely different app-specific integration for this one database */
}

// With MCP: any MCP client can call any MCP server the same standardized way,
// without writing a bespoke integration for each one
// const result = await mcpClient.callTool("filesystem-server", "list_files", { path: "/docs" });
// const rows   = await mcpClient.callTool("database-server", "query", { sql: "SELECT ..." });

The client-side code doesn't need to know how the filesystem server or the database server are implemented internally — it only needs to speak the protocol. That's the same shape as, say, HTTP standardizing how a browser talks to any web server regardless of what's running behind it: the standard is what makes "any client, any server" possible without custom glue code for every pair.

What people usually miss

Watch out

• MCP is a protocol, not a specific tool or product. The value is the shared contract between clients and servers, not any one implementation of either side — this is a "what problem does the standard solve" concept, not a specific SDK to memorize.
• The N × M to N + M framing is the core justification. Without it, "why not just write custom integration code for the two or three tools I need right now" sounds reasonable — the payoff shows up as the number of applications and tools both grow, not on day one with a single integration.
• A server doesn't need to know which client is calling it, and vice versa. That decoupling is what lets one MCP server be reused by many unrelated applications without either side writing code aware of the other's internals.
• This is about connecting a model-powered application to the outside world, not about training or fine-tuning a model. It sits at the same layer as function calling and agent tool use — it's a standard way to describe and expose the tools those patterns already rely on.

Why this matters in interviews

"Why would you use a standard protocol like MCP instead of writing a custom integration for each tool?" tests whether a candidate can articulate the actual integration-scaling problem (N × M becoming N + M) rather than just recognizing MCP as a buzzword — the reasoning is the same one that justifies any shared protocol, and being able to generalize it is the real signal.