What Problem Does The Model Context Protocol Solve?

If you want to get your LLM to do useful things in the world, you will quickly hit a problem.

All the useful things in the world, like Slack, GitHub, or even your local filesystem, provide their own unique API to access them.

LLM's can call these API's using tools - but these tools require you to write code to connect the LLM to the API.

And if the LLM is inside a desktop application, like Cursor or Claude Desktop, you can't manually add new tools yourself.

Wouldn't it be nice if you could quickly get access to a set of pre-made tools?

And even better, could they work with my existing desktop apps?

The Model Context Protocol

The Model Context Protocol lets you build toolsets which can be plugged into existing applications. It's an open standard, maintained by Anthropic.

It can specify a bunch of tools which the LLM can call. For GitHub, that might be 'fetch repository', or 'comment on PR'.

MCP clients - either an existing desktop application or your own code - will be able to speak to the server to call the tools.

This lets you add useful tools to your apps in a way that feels frictionless. Marketplaces of MCP servers are springing up - thousands of companies are rushing to release their own.

Soon, you'll be able to pick and choose from a huge range of pre-built options to power up your LLM workflows.

What MCP Servers Are Available Right Now?

Anthropic maintains a set of MCP Servers which can be plugged into existing applications. They're at this GitHub repo.

Some interesting examples include:

• A GitHub server, which can handle issues, pull requests and much more.
• A Slack server, which can write messages, view chats, and more.
• A Postgres server, which can write SQL queries to a database.
• A Google Maps server, which can plan journeys and search for places.

There's also an open source repository which has over 1,500 MCP servers at the time of writing: awesome-mcp-servers. They also have a web interface for searching.

FAQ

Let's look at a few frequently asked questions I often get at this point:

Why Not Just Give The LLM The API?

A common rebuttal to MCP is: "Why do we need a custom protocol for this? Aren't LLMs smart enough to learn the API themselves?".

In theory, the answer could be yes. Most publicly available APIs provide some sort of documentation for how to use them. In theory, you could feed that into an LLM, and it would work out how to achieve its goals using the documentation.

But in practice, this approach is slow. As user-centric developers, we want to provide the fastest experience we can. And having the tools available to the LLM in a format that's easily consumable reduces latency.

Isn't This The Same As Tool Calling?

Another comment I got when I posted this article online was "how similar is this to tool calling?"

Tool calling is a way for LLMs to invoke functions to do things in the real world. The LLM is paired with a tool executor of some kind, which calls the tool and returns the result to the LLM:

However this pairing usually happens from within the same process. In other words, within the same server, or the same desktop application.

MCP is a way to provide tools to the LLM which it can call from a seperate process. This can be running locally, or on a remote server:

The key difference is that the MCP server is completely decoupled from the client.