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.

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.

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

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 applications is changing and becoming more standardized. By learning and using MCP, all your apps will be able to communicate with each other and share data in a standardized way. That means you will spend less time worrying about how to connect or glue your app to other apps and more time building the features that matter.

We’ll dive more into the details of these concepts in the next chapter, but for now, we understand at a mile-high level what the MCP is and how it works, and what major components are involved.

We understand the problem, the solution, and the possibilities, which are endless, and we even know some core concepts of the MCP. But we probably need to know a bit more about it before we can start building our own MCP servers. We’ll look at that in the next chapter.

Unlock this book’s exclusive benefits now Scan this QR code or go to https://packtpub.com/unlock, then search this book by name.
Note: Keep your purchase invoice ready before you start.