MCP vs traditional APIs

Hey, welcome to this video. In this video, we're looking at the Model Context Protocol, MCP, and why APIs don't get vibes. First, you've probably already heard about MCP as a standardized way for models to talk to tools like database and external services. And there is a lot of confusion about MCP, especially when compared to the traditional API approach. And what is MCP anyway? And why don't APIs get vibes? So grab a drink and let me take you to your party. As the night goes on, you approach the DJ booth, "Hey, play something that gets the crowd going. This is our prompt, by the way." And the DJ, a shiny robot, is taking the song request from you. But with its fixed playlist and rigid programming, it just responds "Error. Request not recognized. Please specify a song title or choose from the playlist." What does it mean? It doesn't understand the vague high-level request you gave. We grab another drink and we give it another try. Play "Whiskey in the jar". Because it seems that it can't interpret your mood or intention, and even if it could, it's limited to its own preloaded songs. So this specific song request doesn't work and it's not in the database, so the system can't play it. With no way to search external sources, understand what the user needs, or offer alternatives so it can't fulfill the request when the song's missing. To summarize, the classical robot or more precisely classical APIs are form-based, rigid and require exact instructions. The party ends with unhappy guests and an empty dancefloor. The DJ lost his reputation. The DJ's broke, his old tightly coupled CD collection API setup feels outdated now. And the crowd wants fresh mixtapes. And to become relevant again and rise back to Star DJ status, he needs access to more sources he can play from. But every new integration costs a lot of money. And he's already broke. So the DJ walks home, broke and frustrated, carrying his old controller. And it stumbles across something new. MCP, Model Context Protocol. A growing directory of tools, each one ready to work out of the box, each one following the same rules. With MCP, the robot doesn't need to spend all his money, which he doesn't have anyway, on writing tools. And there is more. No guessing what a service can or can't do. And every tool speaks the same language. He just connects and plays. And after some while, the DJ returns to its workplace. Now equipped and upgraded with MCP, the DJ is back. And again, you repeat. Can you play something to cheer me up or to cheer or to get the crowd going? And this robot pauses for a moment as it processes your request in a more human way. It understands you're asking for an upbeat mood-lifting song, even though you didn't name a specific track. Behind the scene, it's using MCP to access multiple music sources. The MCP DJ Robot is now able to interpret an abstract prompt, like your question, and figure out what you really want, look up options across different sources, and then choose an appropriate response. It's now not limited anymore to one playlist or one set of instructions. It can mix and match tools, like search databases and all the sources we mentioned before. And remember, our classic API failed because that exact track isn't in the playlist, like playing "Whiskey in the jar" or like another song. But with MCP, the DJ can say, let me check other sources, then find it from an external library and start playing with no extra coding. It's like giving the DJ access to every music store in the world. Instantly. Let's break this down with a real actual MCP architecture. On the left, we have the MCP host with its client, like Curza, Cloudy and so on. And the client receives a user prompt, like "play something that gets the crowd going". And then it decides which tools to involve, like "play a track on SoundCloud or on Spotify". And these services handle the actual work, searching for songs, playing tracks and more. And the MCP servers, we can have multiple MCP servers, acts as translator, converting the standard MCP requests into API calls. That specific services understand, meaning we have no glue code and no weird formats, just one shared transport for every tool. It's actually JSON RPC 2.0. And that's the point of MCP. It lets the model use tools on the fly. Your AI system becomes a flexible operator. It picks up whatever tool is available, as long as it follows the same playbook. On the fly means you can swap YouTube for SoundCloud, for example, which we can see here. Some might argue that you could build the same functionality with an AI agent and traditional APIs. That's true. Let's look at the next slide. But the point of MCP as a standard isn't that it suddenly unlocks something we couldn't do before, to be honest. The difference is how much work it takes to make that agent actually useful across tools. Traditional API setups often need custom logic, specific endpoints, hardcoded tools, it lacks context, and even we have higher dev costs, because we need to integrate and code every API separately. You basically hand-coding every skill the agent has, and with MCP you skip most of that. If there is already an existing MCP server available, you don't need to cope with all of that. And any tool that follows MCP can be connected instantly, without extra code. The agent doesn't care if it's calling a database or a web scraper. You just can do plug and play. And with traditional APIs, you need to do a custom integration. The agent can handle ambitious follow-ups like "play something like before" without human help. For example, if a task involves summarizing a file in Dropbox and posting it to Slack, the agent chooses and sequences the tools on the fly. Every tool declares what function it offers, the input schema and examples. The agent can reason about new tools without ever reading their external docs. That makes it extremely powerful and the MCP standards give us a way to fulfill this. And our DJ, he can play whatever the crowd wants. He is no longer stuck and he can upgrade his system anytime. Everything is now standardized. Same interface, same protocol and no custom integrations. Both approaches, traditional APIs with agent support and MCP works, but MCP gives us a standardized way to talk with our external tools and services in natural language. That makes it so powerful and gives our DJ a shot at the comeback he deserves. I hope this high-level explanation helped you to get a better sense of what MCP is and how it's different from the traditional approaches. Feel free to ask any questions. I'm happy to help. Thanks for watching. I will see you in the next video. Bye.