1

Introducing the Model Context Protocol

Generative AI has rapidly become a force in today's technological landscape, reshaping industries and redefining how we approach problem-solving. From natural language processing to image generation, the integration of generative AI into various domains has opened up new possibilities for innovation and efficiency.

For us developers, integrating generative AI into app development workflows is not without its complexities. We must carefully evaluate factors such as model accuracy, ethical considerations, and computational efficiency.

It's in the process of building applications that we need to consider how we standardize the way we build our AI applications. Standardization means that everything looks the same, which should mean easier integration and collaboration across different teams and tools.

This is where the Model Context Protocol (MCP) comes in, to standardize how we ensure that AI-powered applications can easily find what they need from tools, content, and prompts; more on that shortly.

The chapter covers the following topics:

• How we got here, from SOAP to REST to GraphQL to gRPC to MCP
• The need for a standard
• Endless possibilities: know how to prompt, and a world of MCP servers is your oyster
• What is the MCP?

Free Benefits with Your Book

Your purchase includes a free PDF copy of this book along with other exclusive benefits. Check the Free Benefits with Your Book section in the Preface to unlock them instantly and maximize your learning experience.

How we got here, from SOAP to REST to GraphQL to gRPC to MCP

Before we dive into the details of the MCP, let's take a step back and look at how we got here.

One of my early memories of using web requests involved using XML to send and receive data. This was back in the days of Simple Object Access Protocol (SOAP), which was a protocol for exchanging structured information in the implementation of web services. It was great, but it was also very complex and felt heavy.

Then came Representational State Transfer (REST), which was a simpler way to build web services. It used HTTP and JSON, which made it easier to work with. REST was, and is, great.

There's nothing inherently wrong with REST, but you could argue that if you had a backend team and a frontend team, the frontend team would often be waiting for the backend team to finish their work before they could start building the frontend. This is where GraphQL came in, which allowed you to query only the data you needed and made it easier to work with APIs. Of course, that creates other problems, such as over-fetching and under-fetching data and what's known as the N+1 problem. The N+1 problem is a common performance issue in GraphQL APIs where multiple requests are made to fetch related data, leading to inefficiencies and increased latency.

There's also Google Remote Procedure Call (gRPC), which is a high-performance RPC framework that uses HTTP/2 and Protocol Buffers. gRPC is great for microservices and allows you to define your APIs in a more structured way, but it can be complex to set up and use.

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.

Endless possibilities: know how to prompt, and a world of MCP servers is your oyster

Endless is a big word, so what do we mean? Imagine this: there are skills that you may not have today. In a world with MCP servers, that's no longer a problem, because with APIs wrapped by the MCP, an agent will allow you to prompt to get what you need done.

Take the creation and management of 3D models, for example. Blender is a common tool for creating 3D models. To use it, you need 3D modeling skills. So, you will spend hours learning how to use the app, and I'm sure it's a skill worth having.

Due to Blender's MCP server, knowledge of 3D modeling is no longer needed as much. You can instead state what you want done through a prompt. It's like the movie The Matrix, where the protagonist, Neo, says, "I know Kung Fu" after having information uploaded directly into his brain. The future is here. If you know how to prompt, you're Neo.

Here's the link to the Blender MCP server and the capabilities exposed: https://github.com/ahujasid/blender-mcp.

Any client now, with its own LLM and speaking MCP, will be able to call any MCP server, because Blender isn't the only example; other major companies are leaning into MCP as well. Here are some examples:

• GitHub MCP
• Playwright MCP
• Google Maps

For a list of MCP servers, check out the following link: https://github.com/modelcontextprotocol/servers.

There are many more servers out there, and more are being added every day, so roll up your sleeves and start building your own MCP servers and use what's out there as well!

You're probably thinking what I'm thinking: we all get our own Jarvis, the AI assistant from the movie Iron Man, capable of doing anything. All we need to do is leverage existing MCP servers and build the ones that are missing; just use MCP.

Imagine having a personal assistant that can help you with anything you need, from scheduling appointments to managing your finances. With MCP, this is now possible.

The future is knocking on your door, loud and clear. Are you ready to answer?

What is the MCP?

Here's what the official MCP website has to say about it:

The Model Context Protocol, MCP is an open protocol designed to standardize how applications provide context to large language models (LLMs). Think of it like a USB-C port for AI applications, providing a standardized way to connect AI models to various data sources and tools.

What does that mean for app developers?

It means the way we build our...