Get Started 6 min read Updated Sep 14, 2026

What Is MCP? (Model Context Protocol, Explained)

Before MCP, if you wanted Claude to read your company's Notion docs, query your Postgres database, and check your Slack, someone had to write three separate custom integrations, one per model provider, and do it again for every other AI tool that wanted the same access. The Model Context Protocol exists to make that a one-time job instead of a combinatorial mess.

The short version

MCP is an open, standardized protocol - originally released by Anthropic, now used well beyond just Claude - that defines a common way for AI applications to connect to external tools, data sources, and services. Instead of building a custom integration for every combination of AI app and data source, you build one MCP server for your data source, and it works with any MCP-compatible app: Claude Desktop, Claude Code, LangGraph, n8n, and a growing list of others.

BEFORE MCP App A App B Custom integ. Custom integ. WITH MCP App A App B MCP server

Before MCP: N apps times M tools means N×M custom integrations. With MCP: one server per tool, works with any compatible app.

The "USB-C for AI apps" comparison, and where it actually holds up

MCP is frequently described as a USB-C port for AI applications, and the comparison is useful precisely because of what USB-C actually did: before it, every device needed its own proprietary cable, and a universal, standardized port meant any compliant device could plug into any compliant port. MCP does the same thing for AI apps and data sources - a data source that speaks MCP can be plugged into any app that speaks MCP, without either side needing to know the specifics of the other.

What problem this actually solves, concretely

Without MCP, connecting an LLM to your own systems means writing bespoke code for every pairing: a Slack integration for Claude, a separate Slack integration for your LangGraph agent, another for your n8n workflow, each one reinventing how to authenticate, fetch data, and format it for a model. MCP standardizes that: one Slack MCP server, built once, and any MCP-compatible app can use it immediately, with no per-app rework.

Rule of thumb: if you're building or maintaining more than one custom "connect the model to X" integration, and X is something other people might also want to connect to, it's very likely already an MCP server (there's a large and growing public directory of them) or worth building as one instead of a one-off integration.

Where MCP actually came from, and where it's headed

Anthropic open-sourced MCP in November 2024 as a specification, not a proprietary product - anyone can implement a client or a server, and the protocol itself is versioned and evolves through public spec releases (most recently 2026-07-28 at the time of writing). That openness is why adoption spread well past Claude: LangGraph, n8n, and most major agent frameworks and IDEs now support MCP as a first-class way to connect to external systems.

What this series assumes

Nothing beyond basic familiarity with the idea of an AI app calling a tool - if you've been through the n8n 101 or LangGraph 101 series on this site, you've already seen tool-calling agents in action, and MCP is simply a standardized way of wiring the "tool" side of that picture. The next guide breaks down the three pieces - host, client, server - that every MCP setup is built from.

Next up: MCP's architecture - hosts, clients, and servers, and how one host juggles several servers at once.
Share this guide

Was this guide helpful?

Thanks for the feedback!

Want more hands-on AI builds like this?

APA Mastery runs live, practical sessions on working with modern AI tools - not just theory.

See What's On →