1

Introduction to 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?

Getting the most out of this book - get to know your free benefits

Unlock exclusive free benefits that come with your purchase, thoughtfully crafted to supercharge your learning journey and help you learn without limits.

Here's a quick overview of what you get with this book:

Next-gen reader

Figure 1.1: Illustration of the next-gen Packt Reader's features

Our web-based reader, designed to help you learn effectively, comes with the following features:

Multi-device progress sync: Learn from any device with seamless progress sync.

Highlighting and notetaking: Turn your reading into lasting knowledge.

Bookmarking: Revisit your most important learnings anytime.

Dark mode: Focus with minimal eye strain by switching to dark or sepia mode.

Interactive AI assistant (beta)

Figure 1.2: Illustration of Packt's AI assistant

Our interactive AI assistant has been trained on the content of this book, to maximize your learning experience. It comes with the following features:

Summarize it: Summarize key sections or an entire chapter.

AI code explainers: In the next-gen Packt Reader, click the Explain button above each code block for AI-powered code explanations.

Note: The AI assistant is part of next-gen Packt Reader and is still in beta.

DRM-free PDF or ePub version

Figure 1.3: Free PDF and ePub

Learn without limits with the following perks included with your purchase:

Learn from anywhere with a DRM-free PDF copy of this book.

Use your favorite e-reader to learn using a DRM-free ePub version of this book.

Unlock this book's exclusive benefits now

Scan this QR code or go to https://packtpub.com/unlock, then search for this book by name. Ensure it's the correct edition.

Note: Keep your purchase invoice ready before you start.

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...