Artificial intelligence models are becoming more capable every day. But one big challenge has always been: how do you connect AI to real-world systems like databases, APIs, or file storage without writing lots of custom code for each integration?
This is exactly what Model Context Protocol (MCP)—a new system introduced by Anthropic—aims to solve.
MCP is an open standard (also runs as an open-source project) that makes it easier for AI models to connect to different tools and data sources in a consistent way.
The Core Idea Behind MCP
Think of MCP as a universal connector for AI systems.
Instead of writing one-off scripts every time you want an AI model to work with PostgreSQL, Google Drive, or an external API, MCP defines a standard way of connecting.
It uses a client-server model where the AI model communicates with a middle layer that handles the complexity of talking to external systems. This keeps integrations consistent and much easier to manage.
The Three Key Components of MCP
MCP works by breaking down responsibilities into three main parts as shown in the diagram below:
Let’s look at each one in more detail.
1 - Host
The Host is the environment where AI interactions happen. In practice, this could be an application like Claude (Anthropic’s AI assistant).
The Host provides the space where tools and data sources can be accessed, and it runs the MCP Client inside it.
2 - MCP Client
The MCP Client is the part embedded inside the AI model. Its job is to format requests and responses in a structured way so they can be sent to MCP Servers.
For example:
If Claude needs sales data from PostgreSQL, the MCP Client prepares a structured request.
This request is then passed to the appropriate MCP Server (in this case, the PostgreSQL server).
The MCP Client is like a translator that makes sure the AI speaks the correct “language” when asking external systems for information.
3 - MCP Server
The MCP Server acts as the connector between the AI model and the external system.
Each external tool—like PostgreSQL, Google Drive, or a weather API—can have its own MCP Server. The server knows how to talk to the external system and fetch or update the data the AI needs.
For example:
If Claude is analyzing sales data, the PostgreSQL MCP Server connects to the database, runs the query, and returns the results to the MCP Client.
This separation of responsibilities makes MCP very flexible—you can add new integrations simply by adding new servers.
Why MCP Matters
The beauty of MCP is that it decouples the AI model from the specific integrations. Instead of hardcoding connectors for each new tool:
Developers can build MCP Servers for new systems once.
Any MCP-compatible AI model can then use those servers immediately.
So, have you explored MCP in more detail?
Shoutout
Here are some interesting articles that I read this week:
The 10 BIG Questions of System Design by
Stop trying to be the best at one thing. Do skill-stacking and become a T-shaped developer instead by
Clean Code: 8 Tips to Write Clean Functions by
That’s it for today!
Enjoyed this issue of the newsletter?
Share with your friends and colleagues.
I checked MCPs early, and I was able to build a small prototype that proved useful in my team very early.
Our MCP provided a couple of tools to access logs and query the read-only endpoints of our service. It was just a very early prototype without even including prompts to let the MCP client know how to use these tools, but even that scrappy prototype was useful for my team's on-call debugging issues that people reported.
A small prompt like "The device with id 123 has failed setting up in the beta environment. Check why", and I would go for a glass of water and have a well-identified error message from logs.
It's definitely a technology to learn soon. Thanks also for the mention of my article!
Precise and to the point! Loved it.