The need for a standard

All of these formats are great in their own right, but they all have their own problems. Also, the problem isn’t often of this nature, but rather a string of questions that we need to ask ourselves when building applications:

• What does this app/API do? How do we easily expose the capabilities of our applications in a way that is easy to understand and use? Of course, no one has really agreed on a standard for this yet, until now.
• How do we build apps if prompts are the new way to interact? Add to that that users are becoming accustomed to using prompts to interact with applications, and you start wondering what part is the generative AI part, and what part is the capabilities of the application itself?
• Should large language model (LLM) and other capabilities be kept separate? Also, do I really need the generative AI part and the capabilities of the application to all be in the same place?
• If they were kept separate, what could we gain? If we could separate the two, in a client and server part, then maybe we could easily consume servers built by others – Hello agentic era.

These are some good questions to ask yourself. But this doesn’t answer why we need a standard. Let’s look at that further:

• We, as developers, are too good at programming: Here’s the problem: as developers, we’re almost too good at programming, meaning that we’re used to gluing different things together. We can build applications that use multiple AI models, and we can make applications talk to each other that use different protocols and formats. This is not always easy, but we can do it.
• We can do it, but at what cost? As mentioned, just because we can glue virtually anything together doesn’t mean we should. Yes, we can wrap anything into a REST API and make it talk to anything else. But how much time and effort does that take?
• The solution, a standard: Now, you see the need for a standard, hopefully. The great news is that there is a standard that is being developed to solve this problem. It’s called the MCP. This enables you to not only describe your resources and capabilities in a standardized way, but also describe how to interact with them.

That means that you can literally throw the MCP on top of any app and suddenly any client that talks MCP can interact with it. Imagine the following scenario: you have a client, and that client can talk to a number of MCP servers that run both locally and remotely. All of this is made possible because you listed these servers in an mcp.json file.

Suddenly, you have access to tools to access anything you can imagine, from databases to cloud providers to any other service that exposes an MCP server. You’re becoming agentic with little to no effort. Imagine the possibilities!

Let’s talk about some of the possibilities that the MCP opens up for us.