MCP vs API Explained: Do You Really Need MCP?

MCP vs API — main technological ideas

What an API is (baseline)

APIs are how programs communicate. For example, an app can call Slack endpoint URLs and receive responses.

Direct API integration problem (with LLMs)

With an LLM-based app:

• The model doesn’t directly call APIs.
• Instead, the model outputs an instruction, and an execution layer (normal software you write) performs the API calls.

In practice, teams often implement execution logic per app and per external service, including:

• authentication
• API call sequences
• error handling and retries

As you build multiple AI apps, you often duplicate the same integrations across apps (e.g., app #1 implements integrations A–J, and app #2 repeats the same work).

What MCP (Model Context Protocol) is positioned as

Goal

MCP aims to reduce duplicated “execution layer” code by standardizing how AI apps interface with tools/services.

Core structure

• Each AI app uses an MCP client (a standard component per app).
• Each service (Slack, Gmail, Jira, Notion, databases, etc.) has an MCP server next to it.
• The client and server communicate in a common language, enabling apps to discover and use service actions consistently.

Discovery workflow (important detail)

1. The MCP client connects to MCP servers and asks what actions are available (discovery).
2. The model sees a menu/toolbox of labeled actions and chooses one.
3. The client+server perform the real work; the model only decides and returns text.

End-to-end example round trip

• A support app detects: “payment failed twice.”
• The model selects an action like “Create Jira ticket” with fields such as title and priority.
• The MCP client sends a request to the Jira MCP server.
• The Jira MCP server calls Jira’s existing API and returns results (e.g., a ticket number) back to the app/model.

Key claim: MCP does not replace APIs

MCP is described as a common AI-facing layer in front of APIs:

• If you already have an API, the MCP server acts as a translator/wrapper.
• The underlying API and normal code still perform the actual calls.

Comparison: “Give the agent OpenAPI docs” vs “Use MCP” (execution layer focus)

Approach 1 — Direct API docs route

The agent receives:

• full API documentation
• a sandbox (e.g., a locked environment where it can run code like Python)

The model then generates code to do tasks such as:

• look up channel IDs (e.g., “incident” name → ID)
• convert “yesterday” into Slack’s expected timestamp format
• transform raw user IDs into readable names

Maintenance burden:

• the sandbox/script and integration logic must be maintained by the team
• sharing/reusing across multiple AI apps becomes work

Approach 2 — MCP route

The agent does not get raw API docs.

Instead, it connects to a Slack MCP server that provides an AI-friendly menu of actions, such as:

• read messages
• search messages by date

The MCP server handles:

• channel ID lookup
• authentication
• time formatting
• pagination
• returning clean readable messages

Key difference: service-specific knowledge moves into the MCP server, enabling reuse across apps.

“Why not just OpenAPI?”

OpenAPI helps the model understand available web API methods, but it still doesn’t provide a standardized execution layer. You still must build:

• secure calling
• authentication
• retry/error-handling logic

MCP standardizes the execution layer in a way AI apps can discover and reuse.

Extra note: OpenAPI primarily covers web APIs, while MCP can wrap local resources too (terminal, files, database, etc.) that don’t naturally fit OpenAPI docs.

Practical tradeoffs / warnings

• Context cost: Large API specs or loading many MCP actions can increase token/context usage. Newer apps may need action discovery/search only for what’s needed.
• API key security: The model should never see API keys. Execution layers must securely store keys; MCP can add protections (e.g., approval/permissions), but teams must configure it correctly.

When to use which (decision guidance)

Direct integration is reasonable if:

• only one app needs a few operations
• it’s a one-off task
• no suitable MCP server exists (or it lacks the needed actions)

MCP pays off when:

• multiple AI applications need the same underlying systems
• you want a standard reusable execution layer rather than duplicating integration code

Main speakers/sources

• Unclear from subtitles: no named person or channel mentioned; the video appears narrated by an unspecified speaker.