MCP vs API Explained: Do We Need API After MCP?

Author: Cloud DevOps with Ana · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: MCP vs API Explained: Do We Need API After MCP? · Channel: Cloud DevOps with Ana · 10:46 · Watch on YouTube

Topics: AI agents, Task and workflow automation, Cybersecurity and software security, AI infrastructure and hardware

Summary

The video explains how APIs provide access to real systems and how MCP offers a shared protocol for AI applications to discover and use selected tools and context. It follows a support-assistant request to show that the model proposes tool calls, while the application executes them and controls access. MCP does not replace APIs or automatically provide credentials, permissions, or correct decisions. The speaker recommends exposing only task-relevant tools, validating actions, and choosing direct API integration or MCP based on reuse and compatibility needs.

Key points

APIs let software retrieve data from or perform operations in another system; production integrations must handle authentication, permissions, validation, errors, and limits.
APIs can use different styles and patterns, including REST, GraphQL, gRPC, SOAP, WebSockets, and webhooks.
In tool calling, the model proposes a tool and arguments, while the application executes the call and returns the result.
MCP provides a shared protocol for compatible AI applications to discover and interact with exposed tools and data.
An MCP server may expose tools, resources, and prompts, and can work with APIs, files, databases, or local programs.
MCP does not eliminate the need for implementations, credentials, permissions, or reliable handling of underlying system behavior.
More tools can make an agent less reliable; expose task-relevant tools with clear descriptions and keep authorization checks in the execution system.
Direct API integration may be sufficient for one fixed application and service; MCP is more useful when several compatible AI applications can reuse an interface.
For real deployments, validate inputs, record tool use, handle failures without duplicate actions, and begin with observation before operational actions.

Chapters

Start	Chapter	Summary
00:00	Why AI assistants need connected systems	The video introduces the limits of model-only answers and sets up a support assistant that needs access to tickets and company policy.
01:01	APIs and the basics of tool calling	The speaker explains API requests, production integration concerns, common API styles, and how an application executes tool calls proposed by a model.
04:04	What MCP adds	MCP is presented as a shared connection protocol, with a walkthrough of its host, client, server, and tools, resources, and prompts.
07:09	Limits, safety, and choosing an approach	The video covers MCP’s limits, the risks of too many tools, engineering safeguards, when to use direct APIs or MCP, and a learning project.
10:14	Conclusion	The speaker summarizes the distinct roles of models, APIs, MCP, and the application that controls access.

Quotes

The model doesn’t usually take your API key and start making network requests by itself. — 03:33

MCP, the model context protocol, provides a shared protocol for connecting AI applications to external tools and data. — 04:35

The model proposes and the software executes. — 05:37

More choice does not automatically produce better decisions. — 07:39

Connecting the tool is a step one. Making the workflow dependable is the engineering job. — 08:42

Concepts and entities

API, MCP, tool calling, REST, GraphQL, gRPC, WebSockets, Webhooks, JSON

Full transcript (original language)

00:00 Your AI can explain Kubernetes. It can write a beautiful email. It can even give you a very confident answer that is completely wrong. But ask it to check a real support ticket, find the company’s refund policy, and prepare a reply. Suddenly, being good with words isn’t enough. It needs access to your systems. That’s where APIs come in. And now, there’s another piece everyone is talking about, MCP. You have probably heard that MCP is replacing APIs. That explanation misses the most interesting part because the real challenge is how

00:30 we connect an API application to the tools it can use. [music] We’re going to follow one request from a user all the way to a real action. You will see what an API does, what MCP adds, and where the model actually fits. And by the end, you will understand why giving an agent more tools can sometimes make [music] it worse. So, let’s get into it. The problem, your model cannot see your business. Imagine you’re building a support assistant. You ask, “Find Sarah’s latest support ticket, check our refund policy, and draft a response.” Without connected tools, the model

01:01 doesn’t have those records. It might explain how to handle the request. It might ask you to paste the information. Or if your application is poorly designed, it might invent an answer. Knowing what a refund policy usually looks like is very different from reading your company’s actual policy. So, your assistant needs three things: access to tickets, access to the policy, and a way to prepare a response. Let’s start with the foundation, APIs. APIs without the jargon. An API is an interface that lets software use another system’s functionality. For this

01:32 example, we will use a web API. Think about your banking app. When you open it, your phone doesn’t magically know your account balance. It asks a back-end system for that information. That API defines how to ask and how the answer comes back. In our support assistant, a request might look like this. Get [music] means we are asking to retrieve something. The path tells the server what resource we want, and the customer ID narrows the search. The response might contain the ticket number, subject, status, and latest message,

02:02 commonly as JSON. If we want to create a ticket, we might use post and send the details in the request body. For updates, you will often see put or patch. For removal, delete. But the method and URL are only part of the story. The system also needs to know who is making the request, whether they are allowed to access that customer’s data, and what happens if the request fails. That’s why real integrations involve authentication, validation, error handling, and limits. A demo can work with one happy path request, but production has to work when the ticket

02:32 service is slow, the token expires, and somebody clicks the button twice. Not every API works the same way. REST is a common style for web APIs, often using HTTP methods and JSON. GraphQL lets clients request a specific fields, useful when different screens need different combinations of data. gRPC uses defined service contracts in commonly protocol buffers. You will often encounter it in communication between back-end services. You may also see SOAP in established enterprise systems. And then, there are

03:03 communication patterns around those interfaces. WebSockets keep a connection open for messages in both directions. Webhooks let a service notify another system when something happens, like a payment completing or a ticket changing. You don’t need to memorize every acronym today. The useful question is, does this workflow need to fetch data, run an operation, receive an event, [music] or maintain a live connection? Now, let’s put AI into that workflow. How a model uses a tool? Here’s the part that gets blurred in a lot of explanations.

03:33 The model doesn’t usually take your API key and start making network requests by itself. Your application gives it descriptions of available tools. For example, [music] search tickets finds tickets for a customer. It requires a customer ID. The model can then propose [music] a tool called with the appropriate arguments. Your application executes it, returns the result, and lets the model continue. For our support assistant, that might [music] mean finding the ticket, retrieving the policy, and then generating a draft based on the return information. That’s tool calling, and tool calling existed

04:04 before MCP. So, if models could already use tools, what does MCP actually solve? The integration problem MCP targets. Imagine you have built your ticket connector for one AI application. Then, you want to use it in another assistant and another. Without a shared interface, you may need different adapters, registration formats, and integration code. Now, repeat that for documents, calendars, monitor systems, and internal services. The pain isn’t simply that an API exists. It’s that every AI application may expect to connect to those tools differently.

04:35 >> [music] >> MCP, the model context protocol, provides a shared protocol for connecting AI applications to external tools and data. Here’s my analogy. Imagine every device on your desk needs a different connector. You spend half your time looking for adapters. A shared connector reduces that mess, but it doesn’t create electricity, and it doesn’t make every device do the same thing. Similarly, MCP standardizes part of the connection. The underlying system still has to do the work. A ticket API still manages tickets, and an MCP server can expose selected ticket operations

05:06 through an interface an MCP compatible application understands. [music] And that server can also work with files, databases, or local programs. It doesn’t have to wrap a web API. [music] Follow one request through MCP. We go back to Sara’s support request. There are three names to know. The host is the API application the user interacts with, the client is the component that communicates with an MCP server, and the server exposes functionality or data. The client can [music] ask the server what tools are available. The server might describe a search tool, its name,

05:37 what it does, and the structure of its inputs. That discovery information helps the host decide which tools to make available to the model. The The a call, the host applies its controls and the client sends the request to the server. The server performs the operation and the result returns to the application. Then the model uses that result to continue. In our example, it reads the ticket and policy, then drafts set as response. Notice the separation. The model proposes and the software executes. MCP provides the communication protocol between client and server. It

06:07 doesn’t become the model’s brain. MCP is more than tool calls. MCP servers can expose three important building blocks: tools, resources, and prompts. Tools let an application perform operations, for example, searching tickets or creating a draft. Resources provide context, such as a document or a file the application can read. Prompts offer reusable templates that users or applications can select for a task. For our support workflow, think of a ticket search tool, a refund policy resource, and a template for drafting customer replies. Not every

06:37 server exposes all three and hosts differ in what they support and how they present it. [music] That’s why supports MCP is the beginning of a compatibility check, not the end. The protocol can run locally using standard input and output or remotely using >> [music] >> streamable HTTP. You don’t need to master those transports to understand the architecture. Just remember that an MCP server can be a local process, not necessarily another cloud service. What MCP does not magically remove? Here’s when the hype gets ahead of reality. MCP

07:09 doesn’t actually give your assistant access to every service. You still need a suitable server configuration, credentials, and permissions. Somebody still implements the operations behind the tools. If the ticket API has pagination, rate limits, or changing fields, your integration still has to handle them. And ordinary APIs aren’t necessarily mysterious or undocumented. Many already have machine-readable contracts. The difference is that MCP gives compatible AI applications a shared way to discover and interact with exposed capabilities. It also doesn’t

07:39 guarantee that the model will choose the correct tool. A perfectly valid request can still be the wrong action. You can successfully create a ticket in the wrong project. You can successfully send an email to the wrong person. Successful execution and correct behavior are two different things. More tools can mean more confusion. Remember the question at the beginning? Why might more tools make an agent worse? Imagine handing [music] someone a toolbox with five clearly labeled tools. Now imagine handing them 500 tools, several with almost identical names. More choice does not

08:10 automatically produce better decisions. That’s my engineering takeaway. Expose the tools the task actually needs and describe them clearly. Compare run query with find open tickets for customer. The second name gives the model a much clearer clue about the intended use. Start our support assistant with reading tickets and preparing drafts. Add sending later with an explicit confirmation step and keep authorization checks in the execution system. A sentence [music] in a prompt is not a substitute for a permission check. Retrieve content carefully. A malicious instruction inside a support ticket is

08:42 still customer content, not an instruction your assistant should obey. For a real deployment, record which tools run, validate inputs, and make sure failures don’t trigger duplicate actions. Connecting the tool is a step one. Making the workflow dependable is the engineering job. Should you use an API directly or use MCP? If you have one fixed application calling one known service, direct API integration may be all you need. You don’t have to add MCP just to retrieve a balance or submit a form. If you want to expose a useful set of operations to several compatible AI

09:13 applications, MCP becomes more interesting. For example, you might build a server that exposes read-only deployment status, recent >> [music] >> status, and recent errors, and approved runbooks. Different assistants could reuse that interface instead of each team building its own connector. The decision is about reuse, compatibility, and control, not whether one acronym is newer. What I would build to learn this? Here’s a practical project. Create a small ticket API with sample data. Test it directly so you understand the request and responses. Then expose two

09:44 MCP tools, search tickets and create a draft reply. Connect a compatible AI application, ask it to find a customer’s ticket and prepare a response. Then inspect what actually happened. Which tool did it choose? What arguments did it send? Did it use the return information? What did it do when no ticket existed? That project teaches you APIs, tool calling, MCP and failure handling in one workflow. For cloud and DevOps engineers, adapted to incidents. Read service status, retrieve recent errors and draft an incident update.

10:14 Begin with observation before giving the assistant operational actions. So, for closing, a model can generate a convincing answer. Connected tools let an application check real information and perform real work. APIs expose the system’s functionality. MCP provides a shared protocol for connecting compatible AI applications to tools and context. And your application still decides how that access is controlled. Once you see those pieces separately, the architecture becomes much easier to understand. Now, I’m curious, what’s the first tool you would connect to an AI

10:46 assistant? GitHub, your monitoring stack, or your support system? Tell me in the comments. And if you like the video, please like and subscribe, and see you in the next one.