Open the drawer where old cables live. Micro-USB, mini-USB, three different laptop chargers, that one proprietary connector for a device you no longer own. Every manufacturer solved the same problem separately, and everyone paid for it. AI tooling was in exactly that state — every AI application writing its own connector for every system — until a protocol showed up to do what USB-C did for cables. That protocol is MCP, and this lesson is why it exists.
The N×M problem
Your company has four AI applications — a support bot, a coding assistant, an analytics helper, an internal search tool. They need six systems: Jira, Confluence, GitHub, Postgres, Salesforce, S3.
Without a standard, that's up to 24 integrations. Each one is separately built, tested, secured and maintained. Each reinvents authentication handling and error semantics. And when Jira's API changes, four different teams patch four different connectors — usually at different times, usually after something breaks.
It isn't the building that hurts; it's the maintaining. That's the argument that actually wins adoption debates inside companies.
The USB-C idea
USB-C didn't make laptops faster. It made connection universal: one connector, any device, any host. MCP does the same for AI capabilities. The owner of each system publishes one server; any MCP-capable client connects to it. Six servers instead of 24 connectors — and a fifth AI application costs zero integration work.
Keep the analogy's nuance too, because interviewers probe it: a universal connector standardizes connection, not quality. Plugging in a bad device doesn't become good because the cable fits.
What MCP actually is
An open protocol with three participants — host (the AI application the person uses), client (one per server connection, created by the host), and server (published by whoever owns the system) — exchanging JSON-RPC-style messages over a transport. Lesson 2 covers that architecture properly.
A server can offer three kinds of capability, and the distinction between them is the most-asked MCP interview question:
| Primitive | Controlled by | Example |
|---|---|---|
| Tools | the model | create a ticket, search orders, run a query |
| Resources | the application | the text of a document, a list of projects |
| Prompts | the user | "write a release note" template |
Plus a client-side capability worth knowing early: sampling, where a server asks the client to run a model completion on its behalf — so servers can use model intelligence without holding their own API keys (lesson 3).
Wait — does MCP make my AI better?
No, and being clear about this separates a real answer from marketing. MCP does not improve the model's reasoning. It does not guarantee the model uses tools correctly — descriptions still have to be well written, prompts still matter, and wrong tool choices are still your problem. It does not replace function calling; an MCP server's tools still reach the model as ordinary tool calls (lesson 6). And it does not make third-party servers trustworthy — connecting one is like installing a plugin with access to your data (lesson 7).
MCP removes integration work. Everything else is still engineering.
When it's worth it — and when it isn't
Worth it when there's reuse: several AI clients need the same systems, a platform team wants to expose a capability once for the whole company, a SaaS vendor wants customers' assistants to plug in, or you want to consume servers other people already maintain.
Not worth it for one application with three private tools. There's no duplication to remove, so the protocol layer is pure overhead — plain function calling is simpler and easier to debug. The test in one sentence: will more than one client need this?
Selection-round radar: "What is MCP?" is the opener. Four beats: the N×M integration problem → one server per system, any client → the three primitives (tools/resources/prompts by who controls them) → what it doesn't do. The fourth beat is what makes you sound like an engineer rather than a newsletter reader.
Common mistakes
- Describing MCP as a replacement for function calling — different layers.
- Claiming it improves model accuracy; it standardizes connection, not judgment.
- Adopting it for a single app with a couple of private tools.
- Assuming a connected server is trustworthy because the protocol is open.
- Confusing the host (the application) with the server (the system being exposed).
Quick recap
| Concept | One-liner |
|---|---|
| The problem | N apps × M systems = N×M custom integrations to build and maintain |
| MCP | one server per system, usable by any MCP-capable client |
| Analogy | USB-C — universal connection, not better devices |
| Primitives | tools (model) · resources (app) · prompts (user) |
| Doesn't do | improve reasoning, guarantee correct tool use, or vouch for servers |
| Worth it when | more than one client needs the same systems |
Practice Zone — PYQs from real selection rounds
Six MCQs and two tasks — count the integrations for a real company, then draft your 40-second "what is MCP?" answer.
What problem does MCP primarily solve?
Asked in
How does MCP relate to function/tool calling?
Asked in
Who publishes an MCP server, typically?
Asked in
Which statement about MCP is FALSE?
Asked in
An analogy interviewers like for MCP is:
Asked in
When is MCP NOT worth adopting?
Asked in
Hands-on tasks:
A company has 4 AI applications (support bot, coding assistant, analytics helper, internal search) and 6 systems (Jira, Confluence, GitHub, Postgres, Salesforce, S3). Compare integration effort with and without MCP, and say what else changes besides the count.
Asked in
"What is MCP?" is now a standard question. Write your 40-second answer — problem, solution, and one sentence on what it doesn't do.
Asked in
FAQ
Who created MCP and who can use it?
It was introduced by Anthropic as an open protocol, with SDKs across several languages and adoption by a growing set of AI applications and tool vendors. Vendor-neutrality is the point — a connector standard only one client speaks wouldn't solve the N×M problem at all.
Do I need to build servers to benefit?
No — many teams start purely as consumers, connecting existing servers (filesystem, git, databases) to their assistant. You build a server when you own a system that AI clients should reach.
How is this different from a plain REST API?
An MCP server usually sits in front of your APIs. The differences that matter: capabilities are described for a model (natural-language descriptions plus schemas), they're discoverable at runtime, and they're curated into task-shaped tools rather than mirroring every endpoint (lesson 5).
Next lesson: the three participants and how they talk — Lesson 2: MCP Architecture →