What is MCP? Model Context Protocol Explained. A practical guide for engineers building with AI.
I’ve been building with AI tools for a while now. And for a long time, I kept running into a frustrating pattern.
The model would understand my question perfectly. It would give me a thoughtful, well-reasoned answer.
And then I’d go actually do the work myself.
Not because the AI was wrong. But because it couldn’t reach anything. It couldn’t see my GitHub repos. Couldn’t check my Jira board. Couldn’t tail the logs from production. Couldn’t restart a service or pull up a runbook.
Every AI assistant I used understood the shape of engineering work. None of them could participate in it.
That gap has a name now. And there’s a protocol designed specifically to close it.
The Wall Every AI Model Runs Into
Ask any AI assistant an operational question — something real, something you’d actually ask a teammate — and you’ll see the pattern immediately.
“List all open PRs waiting for review.”
“Check whether the payment service has failing logs.”
“Read the deployment runbook and tell me the next safe step.”
These aren’t exotic requests. They’re the kind of questions developers and platform engineers ask a dozen times a day.
The AI’s answer will usually be something like: “You should check your pull requests” or “Look at your monitoring dashboard.”
That’s advice, not action.
The model understands your workflow. It just can’t touch it.
Before we had a standard way to fix this, teams tried to solve it on their own. And things got messy fast.
The Integration Problem Nobody Wanted to Admit
If you wanted Claude to read your GitHub data, you built a custom GitHub connector.
If you wanted it to pull Jira tickets, you built a different connector.
If you needed AWS access, Confluence, a database, and observability data — that was four separate integration projects, each with its own authentication logic, data format, error handling, and security review.
The same work kept getting rebuilt. Different teams, different AI products, same problem.
And as the number of AI applications grew, the cost of this approach compounded. It wasn’t a technical limitation exactly. It was the absence of a standard.
Every AI application was speaking its own language to every external system. There was no common vocabulary.
The problem wasn’t that AI was too limited. The problem was that every team was solving the same integration puzzle with no shared pieces.
That’s the condition MCP was built to address.
What MCP Actually Is
MCP stands for Model Context Protocol.
It’s an open standard for connecting AI applications to external tools and sources of context.
The operative word is standard.
Instead of every AI product inventing a different way to talk to every system, MCP defines a shared communication layer. An AI application can speak MCP. An external system can expose an MCP server. And the two sides can communicate through a consistent protocol.
No custom one-off bridges. No per-product integration sprawl.
The model gets a common way to discover capabilities, request information, and call approved actions — regardless of what’s on the other side.
The USB-C Analogy That Actually Works
Before USB-C became common, devices used a mess of connectors: USB-A, Micro USB, Mini USB, Lightning, and a few others I’ve already forgotten the names of.
Each one solved a similar problem. In a different shape. With different adapters.
USB-C didn’t make every device identical. It standardized the connection point.
MCP does the same thing for AI integrations.
GitHub, Jira, AWS, your internal database, your documentation system — these are all wildly different tools with different data models and different operational logic. MCP doesn’t pretend they’re the same.
It just gives AI applications a standard port for communicating with them.
So instead of asking “how does this assistant connect to this specific tool?” you can ask a simpler question: does this tool expose an MCP server?
That shift is what makes the ecosystem scalable. Build the server once. Any MCP-compatible client can use it.
How the Architecture Actually Works
Here’s the basic layout.
At the top is a user — you — asking a question or giving an instruction inside an AI application. That could be a desktop assistant, an IDE, a chat interface, or an agent framework.
Inside that application is an MCP client. The client handles the protocol side: discovering what servers are available, understanding what capabilities they expose, and helping the AI make structured requests.
On the other side is an MCP server. The server connects to some external system — a repo, a ticketing platform, a cloud account, a database, an internal service — and exposes what that system can do through the protocol.
The request flows from the AI application through the MCP client to the MCP server. The server performs the operation or retrieves the context. The response comes back through the same path.
The AI application doesn’t need to know the internals of every tool. The tool owner exposes capabilities through a server, and the AI interacts through the protocol. Clean separation. Clear responsibilities.
Tools vs. Resources: The Core Distinction
MCP has two fundamental building blocks: tools and resources.
They’re different in a way that matters.
Tools Are About Actions
A tool represents something the AI can do.
A GitHub MCP server might expose a tool called list_pull_requests. A Jira server might expose create_ticket. A cloud ops server might expose restart_service or deploy_application.
The AI can see these tools, understand their input schema, and decide when one is relevant to a request.
But tools aren’t free-form commands. They’re structured, named, and controlled. That makes them auditable. You can log every tool call. You can gate approval on sensitive actions. You can test and review them the same way you review any other interface.
That’s the shift that opens the door to real AI agents: not “I can suggest what to do” but “I can perform an approved action for you.”
Resources Are About Information
A resource gives the AI something to read.
That could be a runbook, a knowledge base article, a log stream, a schema, internal documentation, or a configuration file.
The distinction matters more than it might seem.
Not every integration should be an action. Sometimes the most useful and safest thing an AI system can do is read the right context and explain what it means — before doing anything.
Before restarting the service, read the runbook. Before answering the platform question, retrieve the documentation. That’s the difference between a capable AI and a reckless one.
MCP supports both patterns: actions through tools, information through resources.
What This Looks Like in the Real World
Once teams start exposing their existing systems as MCP servers, the operational picture shifts quickly.
A GitHub MCP server gives the AI access to repositories, issues, branches, commits, and pull requests. A Jira server surfaces tickets, priorities, sprint status, and workflow state. An AWS server exposes cloud resources, service health, and approved operational actions. A database server can expose schemas, safe queries, or read-only business data. An observability server connects logs, traces, metrics, alerts, and dashboards.
Each server speaks the same protocol. Each one represents a completely different domain.
MCP doesn’t replace your tools. It creates a standard way for AI systems to interact with the tools your team already depends on. The ecosystem grows without requiring every team to rebuild the same bridges.
Why This Is Bigger Than It Looks
AI is moving through phases.
The first phase was chatbot: ask a question, get an answer. Useful, but limited.
The second phase was assistant: help me write, summarize, and reason. More useful, still detached from real systems.
The phase we’re entering now is different. AI systems that can participate in actual workflows.
An AI engineer that doesn’t just explain code — it inspects a repository.
A platform assistant that doesn’t just describe an incident response process — it reads the runbook, inspects the logs, and prepares the next action.
An AI agent that doesn’t just talk about work — it coordinates with tools.
For that version of AI to exist at scale, and to be safe, integrations need a common foundation. One that’s auditable. One that doesn’t require each team to maintain a pile of custom connectors.
MCP provides that foundation.
It gives AI applications a consistent way to access context and capabilities. It gives tool owners a standard way to expose what they build. It gives platform teams a clean interface to govern, log, and secure what AI can reach.
That’s not a small thing. That’s the infrastructure layer the next generation of AI-native engineering tools is built on top of.
The Short Version
If you want to walk away with one clear mental model:
MCP is a standard protocol for connecting AI applications to external systems.
MCP clients live inside AI applications and handle the protocol.
MCP servers expose capabilities from tools, platforms, and data sources.
Tools are actions the AI can call.
Resources are information the AI can read.
Together, they make AI integrations reusable, understandable, and easier to govern. They turn the many-to-many connector problem into a many-to-one protocol pattern.
That’s why MCP is becoming a foundational part of the AI engineering stack — not as a feature, but as a shared language.
What’s Next
In the next video on the Integrations Ninjas channel, I’m building an MCP server from scratch — connecting it to a real AI application, exposing a tool, exposing a resource, and walking through the full request flow end to end.
If this explanation helped, I’d genuinely like to know: do you think MCP will become table stakes for AI tooling in the next 12 months, or will teams keep building custom connectors out of inertia? Drop your take in the comments.
Top comments (0)