Why MCP is needed

When we talk about MCP and a new standard, we need also to look at current problems to understand why we even need a new standard. Meaning without a shared standard like MCP, you had to build a custom set them for each task. For example, to get an AI to fetch today's closed deals, which we have seen before, you needed a script for your CRM's API, like HubSpot AI. Then you need another script to send the summary to Slack. And so on, you get the idea. And every tool needs new code, new APIs, and often copying and pasting IDs or text between all the charts or systems. And if you work in a team setting or in a company, then you have to imagine for every tool you use, you need to create a separate integration. That means you have to code the API, you need to integrate the API, you need to test it, you need to care about the security, authorization, authentication. And one of the big drawbacks is if you want to switch a tool like you want to switch from Microsoft Teams to Slack, you need to begin from scratch, you need to create a new integration and so on. Without MCP, scaling such systems and scaling a company with all the tools is pretty expensive. If anything changes in such of these tools, you need also to change the underlying code. And yeah, this never ends. And that's also the reason why MCP as a standard is good because for the integration part, this is solved. Every app needs to be integrated in the same way. And that also means we can use a predefined or finished server integration. Another problem is that we often talk with chat GPT and copy paste the results into another agent and the other agent is processing all these requests. And yeah, it gets messy. If you don't get this workflow like you wish with MCP, you can just create, for example, one company interface chart or for each department, you can create one company chart and give them access to each service you want. And all the services are using the same protocol and standard and your devs can rely on the standard. So if you need to switch something, it's easy. If you need to new a new service, you can integrate an existing one like in a marketplace. But we will talk about this in the next slides. All these tools and services and all these agents are pretty powerful. But to get the most out of it, you need to wire them together to kind of one company brain. And this was pretty difficult to solve with your own integrations because you need a lot of developer work and you have to care a lot about security. And with MCP, you have the standard and just can plug and play in all your tools into one setup. And this is the idea to the current problems we tackle here. If we narrow this down to in the developer context, it's quite similar. If you're using, for example, Superbase or Postgres as well, then you need to open the database in a new window. You need to look all at the roles, find selected and then go back to your code editor and insert the results or look at the tables, whatever you want to achieve. With MCP, you just work inside the code editor. You don't have to leave the code editor. You just have to call it, read the latest 500 lines in the sales table and find kind of some occurrences or some new users or not active users. And cursor, for example, can answer you everything about your database. This is pretty useful. So you don't have to leave cursor. You can live in cursor and also for new developers, they don't have to learn all the user interfaces, open all the browser stuff, have 500 tabs open. You can just call everything from one interface. This makes it pretty simple to work with. And if there is a new database, for example, you switch from Postgres to SQLite, you can just switch the MCP servers and then just access your SQLite in cursor too. That's all for this part. Let's move on to the next slide.