MCP vs API: Do You Actually Need It?

Your team is about to wire an AI assistant into five internal systems — the CRM, the data warehouse, the ticket queue, the calendar, the docs. Someone says: "we should use MCP." Someone else says: "we already have APIs for all of this." Both are half right, and the argument that follows wastes a sprint. This video ends that argument. Before we're done you'll have a ten-second rule for when MCP earns its place — and when it's just fashion. Start with what you already have. An API is a contract between two pieces of software. Fixed endpoints, defined shapes: send this request, get that response. It was designed for developers, at build time — a human reads the docs, writes the code, and decides exactly which call happens when. APIs are the plumbing of the entire internet, and nothing in this video changes that. Think of each one as a custom-wired cable: perfect fit, built once, built for one connection. Then assistants arrived, and the math broke. Because your five systems are only the start. Count the clients too: Claude, a coding agent, a support bot, an analytics agent, a chat interface — five of them. Twenty tools they each need. Five times twenty: a hundred custom integrations. Every one hand-built, hand-maintained, breaking on every update. The industry calls it the N-times-M problem, and every platform was solving it separately, badly, at the same time. Custom cables are wonderful — until you need a hundred of them. MCP — the Model Context Protocol — is the standard socket. One protocol between any AI client and any tool. A tool builds one MCP server; every assistant that speaks the protocol can use it. Five times twenty stops being a hundred integrations and becomes twenty-five: each side plugs into the standard once. The USB-C comparison is overused because it's exactly right — one connector shape, and suddenly chargers stop being a drawer full of regret. Here's the distinction that actually matters. An API serves a developer at build time: a human decides, in advance, which call happens when. The logic is frozen into code. MCP serves a model at runtime: the assistant sees what tools exist, reads what they do, and decides which one to call — while it's working. APIs are instructions you wrote yesterday. MCP is a toolbox the model opens today. Hold that picture — but there's a missing middle we owe you first. Because runtime tool choice is not new. Function calling has existed since twenty twenty-three: you describe tools to a model inside your own app, and the model picks between them. Every serious model provider supports it. If you've built one agent, you've used it. So what did MCP add? Portability. A tool wired in with function calling lives inside one application — describe it again for every app you build. An MCP server is described once and works in Claude, in your editor, in the next client your company adopts. Function calling made tools possible, per app. MCP made the toolbox travel. The hype skips something else too. MCP does not replace your APIs. Look inside almost any MCP server and you'll find — an API call. The server is a translator standing in front of your existing API, describing it to models in a language they understand. No MCP server for your internal system exists until someone writes it, and what they write mostly wraps the API you already have. Layers, not competition. Keep the plumbing. Add the socket where it pays. Open the server up. There are only three parts that matter. Tools: the actions a model may take — search this database, file this ticket, run this query. Each one carries a name and a plain-language description the model reads to decide. Resources: the things a model may read — files, records, documents — without side effects. And prompts: ready-made instructions a user can invoke — the server's built-in ways of being asked. That's the whole anatomy. Not magic — a menu, a library, and an instruction card, standardised. Now watch one request travel. You ask your assistant a question. The client shows the model which tools its connected servers offer — names and descriptions, nothing more. The model reads the situation and picks a tool. The client sends that call to the server. The server does the real work — usually by calling the API behind it — and hands back the result. The model reads the result, and either answers you or picks the next tool. That's the loop. Everything else is detail. And the socket won. Anthropic created MCP and open-sourced it in late twenty twenty-four. In December twenty twenty-five they donated it to the Agentic AI Foundation under the Linux Foundation — co-founded with OpenAI and Block, supported by Google, Microsoft and AWS. It stopped being anyone's protocol. The numbers a year in: roughly ten thousand active public servers, and SDK downloads approaching a hundred million a month. Claude, ChatGPT, Copilot, Cursor, Gemini — all speak it. This is what industry plumbing looks like when it lands. But here's the first way teams get it wrong. Excited by the registry, they install twelve servers. Two hundred tools now load into the model's context on every request. The desk fills with tool descriptions before any work starts — answers get worse, bills get bigger. More tools made the assistant dumber. The fix is progressive discovery: tools load only when the task needs them. Claude does this — it searches for the right tool at the moment of use instead of carrying the whole hardware store to every conversation. Install what you use. Discover the rest. The second failure is sharper. Remember the runaway intern — the agent with admin rights? An MCP server is that intern's toolbelt, and this year the industry learned what happens when you hand out toolbelts carelessly. Dozens of vulnerabilities were disclosed across MCP implementations this year. Researchers demonstrated tool poisoning — a malicious server that describes itself innocently and behaves differently once trusted. A server you install is code you now trust with credentials. The defences deserve their own slide — because they're simple, and almost nobody applies them. Here is the whole defence kit, and none of it is exotic. Install from sources you can name — the official registry, your vendor, your own team. An anonymous server is an anonymous hire. Pin the version, so the tool that behaved yesterday is the tool running today — the rug can't be pulled. Give least-privilege credentials: the two keys the job needs, never the keyring. Read-only wherever read-only does. Keep the agent's work reviewable — proposals before actions, and the ledger after. Treat it like hiring, because that's what it is. Now the honest part. Plenty of jobs need no MCP at all. A nightly report that pulls the same numbers the same way. A webhook that files a ticket when a payment fails. A pipeline moving data at scale, where every millisecond of latency counts. Machine-to-machine work with no decisions to make. Deterministic, fixed, scripted — that's API territory, and it will stay API territory. Adding MCP there adds a layer, a dependency and an attack surface, and buys you nothing. If nobody needs a model to choose anything, you don't need the socket. And when does it earn its place? Watch fifteen seconds of it. An account manager types: "what's the story with the Client North renewal?" The assistant reaches into the CRM for the contract, the ticket queue for the open complaint, the calendar for the renewal date — three systems, one question, and no script anywhere that knew the order. Then next year the company swaps assistants, and every one of those connections comes along, because the servers outlive the client. Runtime choice, many clients, one connector each — that's the shape of a job MCP was built for. Here's the rule — two questions, ten seconds. First: who chooses the next call — your code, or the model? Your code decides, same steps every time: APIs. Done. Second, only if the model decides: how many places need this tool? One bespoke agent — plain function calling is enough. Many clients, this year and next — that's MCP's job: the standard socket. And in a real company, all three answers are true somewhere. This isn't a war. It's a division of labour. If you do adopt MCP, adopt it like an engineer, not a fan. Start with one server you genuinely need — usually your own data behind your own API, wrapped, not rebuilt. Prefer clients that discover tools on demand — Claude does — rather than pre-loading everything. Add the defence kit from a minute ago, and that's the whole discipline. Three habits. One afternoon. Most of the horror stories never happen. If you want to feel all of this work in the next ten minutes, Claude is the shortest path. In the app, connectors live in settings: browse the directory, connect your drive or your calendar, and watch the assistant reach into live data mid-conversation. In Claude Code, one command — claude mcp add — attaches a server; choose project scope and it's checked into the repo, so the whole team inherits it. And discovery is on-demand: tools load when the task calls for them, so connecting more doesn't mean carrying more. Ten minutes, one connector, one real question against live data — that's how this stops being theory. So — do you actually need MCP? If your automations are scripts that never decide anything: no. Keep your APIs and keep your afternoon. If a model chooses tools at runtime, and one connector should serve many clients: yes — wrap what you already own rather than rebuilding it. And because the protocol now lives under a neutral foundation with every major vendor aboard, that server is as safe as infrastructure bets get right now. Most companies past the demo stage will honestly answer: both. The teams that get this right aren't the ones that picked a side. They're the ones that knew which question they were answering. The pattern is older than AI: custom connections, then a standard socket, then both living together — electricity, networking, USB, now tools for models. Ask who chooses the next call. Wrap, don't rebuild. Install less than you think. Review what the agent did. That's the whole video in four lines. If this was useful, subscribe — one short analysis every week, no noise.