MCP: Why Model Context Protocol Is Becoming an Important Part of AI
Model Context Protocol connects AI applications to tools and data through a common open standard. I look at how MCP works, why regular APIs aren't enough on their own, and why it makes sense for practical AI agents.
Not long ago, most of my attention around AI was focused on which model was better. Today, I find another question increasingly important: what can the AI actually access, and what can it do?
A language model on its own cannot see my files, access a database, or work with the tools I use every day. This is where Model Context Protocol, or MCP, becomes interesting.
What is MCP?
MCP is an open standard for connecting AI applications to external tools and data. Instead of every AI application building its own integration for GitHub, databases, Google Drive, or internal company systems, they can communicate through a common protocol.
The idea reminds me a little of USB. Devices can be completely different, but as long as they use a common standard, computers don’t need a completely different way to connect to each one.
With MCP, there is an AI application on one side and an MCP server exposing certain capabilities on the other. Despite the name, an MCP server doesn’t necessarily have to be a remote server in the cloud. It can also run locally on your computer.
Tools, resources, and prompts
MCP has several basic building blocks. Tools allow AI to perform actions, such as searching for information, working with a database, or creating an issue on GitHub.
Resources provide information, such as files, documentation, or application data. Prompts are reusable instruction templates that a client can expose to users.
This makes MCP more than just another API for calling functions. It provides a common way for external systems to describe their capabilities to AI applications.
Why isn’t a regular API enough?
My first reaction to MCP was that it seemed to solve something REST APIs had already solved. To some extent, that’s true. MCP doesn’t replace REST APIs, and an MCP server will often use an existing API behind the scenes.
The difference is the standardized layer between the AI application and the service.
If a service provides an MCP server, multiple AI clients supporting the protocol can potentially use it. At the same time, an AI client doesn’t need hundreds of completely different integrations built directly into it.
What does this look like in practice?
Imagine asking an AI assistant:
Find the latest open bugs in the project, check the documentation, and prepare a proposed solution.
Without integrations, I would have to provide all of that information manually. With the appropriate MCP servers, the assistant can access the repository, issue tracker, and documentation and find the relevant information itself.
I already use MCP with GitHub, GitLab, Trello, Gmail, Google Drive, and Rohlík.cz. In practice, though, my experience has been much less polished than the idea of MCP itself suggests.
Most MCP integrations I have tried are very limited and sometimes close to unusable. GitHub, for example, cannot handle binary files through the integration I use, Trello cannot work with comments, and with Rohlík.cz I couldn’t even add a banana to the cart.
So MCP still strikes me as a great idea, but today’s implementations often lag far behind the promise. Providers frequently expose only a small subset of their service, leaving something closer to an unfinished prototype than an integration I can rely on for everyday work.
If it also has permission to write, it doesn’t have to stop at suggesting a change. It could create an issue, modify a file, or perform another permitted action.
This is where the difference between a traditional chatbot and an AI agent starts becoming genuinely useful to me.
Security becomes much more important
Once AI gets access to real tools, there is a significant difference between allowing it to read documentation and allowing it to modify data, send messages, or write to a repository.
I therefore think about MCP servers in much the same way as applications requesting permissions. I don’t want to give an AI access to everything simply because it is technically possible.
As AI agents become more capable, understanding exactly which data and actions they can access will become increasingly important.
Why MCP makes sense to me
What interests me most about AI right now isn’t another percentage point in a language model benchmark. The more interesting shift is from models that simply answer questions to systems that can work with the tools, data, and applications I actually use.
MCP doesn’t solve the entire problem. We still need integrations, sensible permissions, and AI capable of using the available tools correctly.
But a common protocol removes one important obstacle: we don’t have to build a completely new integration for every combination of AI application and external service. That’s why I expect MCP to become an increasingly common part of the AI agent ecosystem.