What Is MCP, And Why Can’t You Just Use an API?

You’re chatting with an AI assistant. You type: “Use the Stripe API to check if my last three invoices were paid.”

Seems totally reasonable since Stripe has an API, and the AI seems smart.

The truth is, it can’t do that. Not really. Not without a lot of invisible infrastructure doing heavy lifting around it.

Infrastructure that, until recently, every developer had to build from scratch, every single time, for every single service.

That infrastructure now has a name: MCP (Model Context Protocol).

If you’ve seen “MCP” floating around and felt your eyes glaze over, this post is for you.

Note: We’re talking about MCP not MVP (neither gaming or engineering kind). It’s a letter difference, please note it!

We’re going to break it down properly:

• What MCP actually is
• Why a plain API isn’t enough for AI agents
• Why APIs aren’t going anywhere despite all the MCP hype

By the time you’re done reading, you’ll be able to explain this to someone else confidently. No Googling required.

Let’s get into it 👇

First: What Is an API, Really?

You’ve probably heard the waiter analogy: you (the customer) make a request, the waiter (the API) takes it to the kitchen (the server), and brings back a response.

It’s a nice analogy, but let’s make it even more concrete.

Say you’re building a weather app. You want to show users the current temperature in their city.

You’re not going to build your own global weather infrastructure; you call a weather service’s API instead.

You’d make a request like this:

GET <https://api.weather.com/current?city=Lagos&apiKey=YOUR_KEY>

And you’d get back something like:

{
  "city": "Lagos",
  "temperature": 31,
  "unit": "Celsius",
  "condition": "Partly cloudy"
}

Clean and predictable. You asked for something specific; you got exactly that back.

That’s the fundamental nature of an API: it’s a contract between two pieces of software.

One side says, “Here’s what I can give you, here’s how to ask, here’s the format you’ll get back.”

The other side makes the request, gets the response, and does something with it.

APIs are written for developers. They assume you, a human, will:

• Read the documentation
• Understand the endpoints
• Handle the authentication
• Manage errors
• And write the code to make it all work

They’re brilliant for this. In fact, the entire modern web is stitched together by APIs 🌐

But here’s where things get interesting.

Enter the AI Agent, and the Problem

So, back to that Stripe request. The API exists, and the docs are great. Surely the AI can just go use it, right?

Here’s what would actually have to happen for that to work:

1. The agent needs to know Stripe’s API documentation—all of it
2. It needs to figure out which specific endpoint handles invoice data
3. It needs your API key (where is that stored? Is it safe to access?)
4. It needs to construct the correct HTTP request with the right headers, auth tokens, and query parameters
5. It needs to handle errors—what if the request fails? What if it returns a 401?
6. It needs to parse the response and extract the three invoice records
7. It needs to do all of this without accidentally exposing your credentials or making unintended requests

That’s a lot of steps.

And here’s the brutal truth: AI models can’t do most of this by themselves.

Not because they’re not smart, but because of fundamental limitations in how LLMs work.

An LLM, at its core, is a text predictor. It reads text in and writes text out.

Though it might surprise some of you, an LLM can’t actually make network requests. It can’t securely store your API keys. It can’t handle OAuth flows.

Nor can it execute code without an external runtime.

So when you say “Use the Stripe API,” the AI can write code that would do this, but it can’t actually do it.

Not without serious infrastructure built around it.

And even if you build that infrastructure, you’d have to rebuild it every single time, for every service, for every AI system.

That’s the problem MCP was created to solve.

Explore: The Ultimate Guide To Re-Engineering My Portfolio’s RAG Chatbot

What Is MCP?

MCP—Model Context Protocol—is an open standard introduced by Anthropic in November 2024 to standardize how AI systems connect to external tools, data sources, and services.

The best analogy floating around developer communities right now is USB-C.

Before USB-C, you had a bag of different cables for every device. Think micro-USB, Lightning, proprietary connectors, you name it.

Every new device meant a new cable.

MCP changes that by creating a universal plug-and-play layer that works across different AI models and data sources.

But let me make MCP concrete with a scenario rather than just a definition 💁‍♀️

The Restaurant Analogy, Upgraded

Imagine you’re running a restaurant (your AI application).

Your chef (the AI model) is brilliant, but has no idea what’s in the pantry, what tools are available, or what suppliers you work with.

In the old world (no MCP), every time you hired a new chef, you’d have to:

• Manually tell them about every single ingredient
• Write custom instructions for every tool in the kitchen
• Build a new communication system with every supplier
• Repeat the entire process if you hired a different chef

With MCP, it’s different. You install a standardized kitchen system (the MCP server).

The chef can walk up to a panel and ask: “What tools do I have access to? What ingredients are available? What can I order from suppliers?”

And the kitchen answers back in a language the chef perfectly understands.

Switch chefs? Same kitchen, same panel, and same communication.

No rebuilding everything from scratch.

That’s MCP. It’s the standardized system that lets any AI model query any external tool or data source using a common language without the AI needing to know the underlying plumbing of each service.

The Architecture: How It Actually Works

Let’s look at what MCP actually looks like structurally, because this is where a lot of the confusion clears up.

MCP has three main pieces:

1. The MCP Host. This is the AI application: Claude Desktop, Cursor, your custom-built agent.

It’s the thing the user actually interacts with.

2. The MCP Client. This lives inside the host. It’s the part that speaks the MCP language and handles communication with servers.

3. The MCP Server. This is a lightweight program that wraps an external service or data source (like Stripe, GitHub, or a database) and exposes its capabilities in an AI-friendly way.

When an MCP client connects, the server can answer: “Here’s what I can do, here’s how to ask me, here’s what I’ll give back.”

So when you say “check my Stripe invoices,” the flow looks like:

You → AI Host → MCP Client → MCP Server (Stripe) → Stripe API → back up the chain

Notice that last step: the MCP server still calls the actual Stripe API under the hood.

MCP doesn’t eliminate APIs. It’s a layer above them that makes them usable by AI agents safely and consistently.

The Critical Difference: Who It’s Built For

Here’s the sentence that unlocks everything:

APIs are written for developers. MCP is written for AI models.

An API assumes a human developer will read the docs, understand the system, and write code.

An MCP server assumes an AI agent needs to:

• Discover capabilities dynamically
• Understand what tools do from machine-readable descriptions
• Operate across multiple tools in a connected workflow

Let me show you the contrast side by side.

With a raw API, a developer might read docs that say:

“To retrieve invoices, send a GET request to /v1/invoices with your Bearer token in the Authorization header, and pass customer as a query parameter to filter by customer ID.”

A human developer reads that, writes the code, tests it, and handles errors. Done.

With an MCP server, an AI agent asks the server: “What tools do you have?”

And the server responds with something like:

{
  "tools": [
    {
      "name": "list_invoices",
      "description": "Retrieve recent invoices for a customer. Returns paid/unpaid status.",
      "parameters": {
        "customer_id": { "type": "string", "required": true },
        "limit": { "type": "number", "default": 10 }
      }
    }
  ]
}

The model doesn’t need separate documentation or prompt tuning. It knows exactly how to call each tool.

More: All You Need To Know About AI Workflow Files And How To Use Them

No docs required. No human in the loop.

Why You Can’t Just “Pass It the API Docs”

“Okay, but,” I hear you thinking, “couldn’t I just dump the Stripe API documentation into the AI’s context and let it figure it out?” 😌

In theory? Maybe.

In practice? Several painful reasons why this breaks down:

1. Documentation is written for humans, not machines.

API docs use natural language, examples, and context that make perfect sense to a developer reading linearly.

An AI trying to reason about 200+ endpoints from raw docs will get confused, mix up endpoints, or confidently choose the wrong one.

An enterprise API can easily have 75–100 endpoints, and LLMs are surprisingly bad at choosing correctly from a long, unstructured list.

Give an AI too many choices, and it slows down, second-guesses itself, or picks wrong.

Note: Enterprise APIs are also notoriously badly documented and, often, poorly structured for anyone not consuming with serious context. It’s reality (trust, I’ve seen it first-hand).

2. The AI still can’t actually execute anything.

Even if the AI perfectly understands the Stripe docs, it cannot make an HTTP request.

It outputs text that looks like a request.

Something external has to actually run that code.

MCP safely provides the runtime and execution environment.

3. Credentials are a nightmare.

Your Stripe API key shouldn’t be floating around in an AI’s context window.

The MCP server holds and manages credentials on the server side, so the AI never sees them.

4. There’s no state or memory between calls.

If an AI needs to call three different endpoints in sequence (get customer → find invoices → check payment status), a raw API gives it no mechanism to track that it’s mid-workflow.

MCP maintains sessions that remember context across multiple operations, something a raw API simply wasn’t designed to do.

Is MCP Just Middleware?

This is another question that comes up a lot, and it’s a smart one.

The simple answer: yes. And that’s a good thing.

APIs remain the foundation of data access, while MCP servers become the interpreter and coordinator that make this access AI-ready.

Think of it like this: a translator at a business meeting isn’t replacing the two executives having a conversation. The translator makes the conversation possible.

MCP is the translator between AI agents and the APIs that power the real world.

More technically, MCP sits between the AI model and the actual service.

The MCP server calls the service’s API on behalf of the agent, with proper credentials, error handling, and structured output that the AI can understand.

The API still does the actual work. MCP makes it accessible.

AI Agent
   ↓
MCP Server  ← this is the "middleware" / translator
   ↓
Stripe API / GitHub API / Your Database / etc.

This matters because it keeps responsibilities clean:

• The API handles the actual data operations
• The MCP server handles AI-friendly discovery, context, and safety
• The AI handles reasoning and decision-making

So, Why Are APIs Still Necessary?

APIs are not replaced by MCP; they’re complemented by it.

Without APIs, you’d be left with scrapers and custom scripts: brittle, slow to sync, and riddled with security problems.

APIs are the official, authenticated, reliable channel to a service’s data.

MCP servers wrap those APIs.

If you remove the API, there’s nothing for the MCP server to call.

Here’s why APIs remain essential:

1. Direct API use still makes sense in many workflows.

If you have a static, predictable integration, like syncing data from a CRM to a database on a schedule, you don’t need MCP at all.

Direct API calls are more efficient, cheaper, and simpler for automations that don’t need AI reasoning.

2. MCP and APIs are a stack, not a competition.

A well-architected AI system looks like this:

• Your business logic and data live behind APIs
• MCP servers wrap those APIs and expose them to AI agents
• The AI reasons over what’s available and takes action

Each layer does what it does best.

Before MCP Existed: What Did This Look Like?

Let me paint you a picture of life before MCP, because it makes the value land harder than any definition.

Plus, it’s what helped me understand this better!

Before MCP, developers had to build custom connectors for each data source and tool, which Anthropic called an “N×M” data integration problem.

Imagine you’re building an AI assistant that needs to access:

• Slack (to read messages)
• GitHub (to check pull requests)
• Notion (to write notes)
• Google Calendar (to check your schedule)

Without MCP, you’d have to:

1. Build a custom integration for Claude ↔ Slack
2. Build a custom integration for Claude ↔ GitHub
3. Build a custom integration for Claude ↔ Notion
4. Build a custom integration for Claude ↔ Google Calendar

Now imagine you want to switch from Claude to GPT-4. You’d rebuild all four from scratch 🙈

That’s the N×M problem: N models times M tools equals an explosion of one-off, incompatible, fragile integrations.

With MCP, you build a Slack MCP server once. That server works with Claude, GPT-4, Gemini, or any other model that speaks MCP.

Same for GitHub, Notion, and Calendar. Build once, use everywhere.

Tip 👀
This is why “there are now thousands of MCP servers available” is such a big deal. Every server someone contributes, the whole ecosystem benefits from because you don’t have to rebuild what already exists!

A Real-World Example: Putting It All Together

Let’s run through a scenario that ties everything together.

The request: You ask your AI assistant, “Check if the payment for invoice #1042 came through, and if it did, send a Slack message to the #billing channel confirming it.”

Without MCP (old world):

• The AI writes you Python code to call the Stripe API
• You have to run that code yourself
• The AI writes you more code to call the Slack API
• You run that too
• You verify the results
• You report back to the AI what happened so it can continue

That’s not agentic. That’s you doing all the work 💪

With MCP: The AI connects to both a Stripe MCP server and a Slack MCP server.

It asks each: “What can you do?”

The Stripe server says it can retrieve invoices.

The Slack server says it can post messages.

The AI:

1. Calls get_invoice with invoice_id: "1042" → gets back { "status": "paid", "amount": 200 }

2. Sees status is "paid," decides to proceed

3. Calls send_message with channel: "#billing" and text: "Invoice #1042 confirmed paid ✅"

4. Reports back to you: "Done! Invoice #1042 was paid, and I've notified the #billing channel."

No code written. No running scripts. Nor any back-and-forth.

The AI reasoned over what tools were available, used them in sequence, and completed the workflow.

That’s what MCP enables.

Note📍
The MCP servers in this scenario are still calling Stripe and Slack’s APIs internally. The APIs never went away. MCP just made them accessible to the AI.

Explore: This Is How To Build A Visual LLM Agent Workflow

The Short Summary (So You Can Explain It to Anyone)

Let’s go over a version you can tell a non-technical friend over coffee:

APIs are like instruction manuals for developers. They tell you: here’s what our system can do, here’s how to ask for it, and here’s what you’ll get back.

They’ve been running the internet for decades (#reliable).

But AI agents can’t read manuals the way humans can. They can’t make network requests on their own, can’t safely store passwords, and get confused by too many choices.

MCP is a new layer that translates between AI agents and APIs.

It wraps APIs in an AI-friendly format where the agent can ask ‘what can I do here?’ and get a structured answer.

MCP doesn’t replace APIs. It makes APIs usable by AI.

And if someone pushes you with “so it’s just middleware?” tell them: Yes, and that’s exactly what it needs to be.

It sits between the AI and the real world, handles the messy parts safely, and lets the AI focus on reasoning about what to do next.

It’s a Wrap

MCP is one of those things that seems complicated until the right frame clicks, and, hopefully, this was that frame for you.

There are so many “What is MCP” explanations out there that don’t tell you what the heck it is. At the end of it, you’re still wondering: “So, what is MCP?”

Here’s the quick recap:

• APIs are written for developers: reliable, structured, stateless, and powerful. But not designed for AI agents to use autonomously.
• AI agents can’t call APIs on their own: no built-in networking, no credential management, and no dynamic tool discovery.
• MCP is an open standard that wraps APIs and external services in an AI-friendly layer. It handles discovery, context, credentials, and execution safely.
• MCP is middleware, and that’s a feature, not a limitation. It sits between AI and APIs, so each layer does what it’s best at.
• APIs are still necessary. MCP servers call them under the hood. They’re the foundation; MCP is the bridge.

The beautiful thing about where we are right now is that thousands of MCP servers already exist for tools you use every day, like Stripe, GitHub, Slack, Notion, Google Drive, and more.

As a developer, understanding this stack early puts you ahead of the curve.

If you want to go deeper, I’d recommend exploring the official MCP documentation and checking out MCP.so for a directory of servers you can actually use.

I hope this was helpful and de-mystified MCP for ya.

‘Till next time ✌️