Before MCP, every AI-to-tool integration was custom-built. Want Claude to talk to Jira? Write custom code. GitHub? Different custom code. A database? Yet another integration. MCP (Model Context Protocol) is an open protocol by Anthropic that replaces all of that with one standard. Think of it as USB for AI — a universal plug that lets any AI app talk to any service through a standard interface.
The Core Idea
MCP standardizes how AI applications connect to external tools, data sources, and services. Instead of every AI app building its own integration for every service, there’s one protocol that sits in between:
AI App (Host/Client) ←— MCP Protocol —→ MCP Server ←→ External Service
(e.g. Claude Code) (adapter) (Jira, GitHub, DB, etc.)
The AI app speaks MCP. The MCP server translates that into whatever the external service needs. Build the adapter once, and any MCP-compatible AI app can use it.
“Server” Is Misleading
The word “server” in MCP server trips people up. It doesn’t mean a remote machine someone has to manage. It’s just a local program or script that:
- Listens for instructions from the AI client
- Translates those into API calls (e.g., Jira REST API)
- Returns results back to the AI
It’s called a “server” only in the protocol sense — it serves capabilities to the AI. Most MCP servers are just a Node.js or Python script running on your machine. Nothing to deploy, no infrastructure, no cloud costs.
What MCP Servers Expose
An MCP server can provide three types of capabilities:
- Tools — Actions the AI can take (create a Jira ticket, run a query, send a message)
- Resources — Data the AI can read (file contents, database records, API responses)
- Prompts — Reusable prompt templates for common workflows
This separation matters. Tools are for doing things. Resources are for reading things. Prompts are for templating things. The AI knows which is which and can use them appropriately.
Two Transport Modes
MCP supports two ways for the AI client and server to communicate:
stdio (local) — The server runs as a local process on your machine. Communication happens via standard input/output (piping data between processes). This is the most common setup and the simplest to configure.
SSE/HTTP (remote) — The server runs on a remote machine. Useful when the server needs access to resources not on your machine, or when sharing a server across a team.
For most individual setups, stdio is all you need.
A Practical Example
With a Jira MCP server configured locally, the flow looks like this:
Your machine Atlassian Cloud
┌─────────────────────────────┐
│ Claude Code │
│ ↕ (stdio) │
│ MCP Server (local process) │ ── HTTPS ──→ Jira API
│ (Node.js script) │
└─────────────────────────────┘
No intermediary. Your machine runs the MCP server, which talks directly to Jira’s API. The AI says “create a ticket with this summary,” the MCP server translates that into the right Jira REST API call, handles authentication, and returns the result.
Why It Matters
Composability. Snap together servers like building blocks. Need Jira + GitHub + Slack? Add three MCP servers. Each one is independent — you can add or remove them without touching the others.
Standardization. One protocol to learn. Tool developers build once, and it works everywhere MCP is supported. No more writing the same integration for every AI app.
Security. The user controls what the AI can access. Every tool call requires approval (or can be pre-approved). The AI can’t reach services you haven’t explicitly configured.
Separation of concerns. The AI doesn’t need to know how to talk to Jira’s API. It just calls create_issue. The MCP server handles auth, API details, error handling, and rate limiting.
Ecosystem. The community is building MCP servers for everything — databases, GitHub, Google Drive, Slack, file systems, browsers, and more. Most are open source and take minutes to set up.
MCP vs Plugins
These terms can be confusing because they overlap.
MCP is the underlying protocol — the raw standard for how AI talks to tools. Setting up an MCP server means editing JSON configs, specifying commands, and managing environment variables yourself.
Plugins (as seen on claude.com/plugins) are a packaging layer on top of MCP. A plugin bundles MCP servers, tools, skills, and configuration into a one-click install. Instead of manually writing JSON config, you just click “Install.”
Plugin = MCP server(s) + configuration + skills, packaged for easy install
Critically, plugins still run locally as MCP servers. The plugin system is a distribution/installation convenience, not a different architecture. Think of it like:
- MCP server = manually installing a package from the command line
- Plugin = clicking “Install” in an app store that does the same thing for you
How This Differs from ChatGPT Plugins
ChatGPT plugins (OpenAI) are a different model entirely:
| ChatGPT Plugins | Claude (MCP / Plugins) | |
|---|---|---|
| Runs where | Remote server (someone else’s) | Locally on your machine |
| Data flow | You → OpenAI → Plugin server → Service | You → Local MCP server → Service |
| Portability | ChatGPT only | Any MCP-compatible client |
| Protocol | Proprietary | Open standard |
| Control | Platform-controlled | You control everything |
Anthropic chose an open, local-first approach rather than a centralized plugin marketplace model.
Key Takeaway
MCP turns the N×M problem (every AI app × every service = custom integration) into an N+M problem (AI apps speak MCP + services have MCP servers). It’s the same pattern that made USB successful: agree on the plug, and everything just works.