The short version: The Model Context Protocol (MCP) is an open standard that allows any AI application to interact with any external system — files, databases, APIs, all of it. Anthropic first put it out at the end of 2024, and within roughly 18 months MCP became the industry-wide standard for plugging AI applications into the rest of the stack. This article walks through what MCP really addresses, how it works internally, and how it compares to function calling and RAG.Every AI application has the exact same issue. The model as presented is very smart, but completely unable to remember things, access your documents, send messages, or even know what events are scheduled on your calendar. In short, the entire game in 2024 and 2025 was figuring out how to integrate the model with everything outside of itself.Until late 2024, every team was solving this the brute-force way. Each AI application built a custom integration for every tool it wanted to talk to. If there were M different AI applications and N different tools, the result was M × N separate bespoke integrations. Every team that wanted to plug an AI app into their tech stack Slack wrote their own bindings. That is not engineering. That is a massive pile of unnecessary repetitive plumbingMCP — the Model Context Protocol — is the answer. It turns M × N into M + N. One protocol, one spec, and any compliant client can talk to any compliant server.The USB-C Analogy Is Not Just Marketing FluffThe official comparison between MCP and USB-C sounds like marketing fluff until you sit with it. USB-C did not just change the shape of the port on the back of your laptop. It represented a real improvement over the way devices used to talk to each other. Before USB-C, every device had its own port. Laptops had one charger. Phones had another. Headphones had a third. The connectors themselves worked well enough, but manufacturers still had to develop additional hardware (chargers, adapters, dongles) before consumers could use those devices together.USB-C did not make any device smarter. It made the connection between devices stop being a problem. Today you plug your phone into your laptop's video output port and it just works. No dongle. No driver hunt.The same thing is happening to AI. MCP did not make the model smarter — the model gets smarter every quarter regardless. What did not have a standard was the socket. MCP is the socket.The Three-Role ArchitectureMCP defines three roles:Host — the AI application the user actually works with. Claude Desktop, Cursor, VS Code Copilot, ChatGPT.Client — a lightweight connector inside the host that maintains a 1:1 link with a server.Server — an independent process that exposes capabilities: tools, resources, and prompts.A single host can spin up many clients. Each client talks to exactly one server. Servers can be local (a Python script running on your laptop) or remote (a hosted endpoint reachable across the network).Why split client and server? Because the server is what the capability owner writes — the Slack team, the GitHub team, your own internal data team. They ship one server, and every MCP-compatible host instantly knows how to use it. The client is boilerplate the host runs without having to think about it. It exists so the capability owner does not have to care which host is calling.The Three Primitives a Server ExposesThis is the part most explainers tend to gloss over, and it is what really makes MCP different from "yet another function calling specification."Tools — actions the model decides to invoke. sendslackmessage, querydatabase, createpull_request. Tools are how the model takes action, and they often have side effects.Resources — addressable data the model can read. A file, a database row, a webpage. Resources are cacheable.Prompts — pre-baked prompt templates the server suggests. If you are working with a Git repository, the Git server could expose a "summarize this PR" prompt. A meeting-notes server could expose an "extract action items" prompt.APIs for function calling provide tools. RAG provides resources. Prompt libraries provide prompts. MCP provides all three behind one interface, and includes the metadata to discover what is available at runtime.That last piece — runtime discovery — is really what makes MCP feel different in practice. The host does not need to know what a server can do at compile time. It connects, asks "what have you got?", and the server returns a typed capability surface. With that, new tools can appear without redeploying anything on the client side.A Real Example of How a Request WorksThe wire protocol is JSON-RPC 2.0 over a persistent bidirectional channel. Strip the formality away and an interaction looks like this:1. The host launches an MCP server (local subprocess or remote endpoint).2. Client and server complete an initialize handshake — they trade protocol version, capabilities, and names.3. The client requests tools/list. The server returns the catalog with JSON-Schema-typed inputs.4. The model decides it wants a tool. The host shows the end user a permission dialog. Security lives here.5. The user approves. The client sends tools/call with the arguments.6. The server runs the tool, optionally streams partial results, and returns the final output.7. The output goes back into the model's context as a tool result.Resources and prompts follow the same shape: resources/list, resources/read, prompts/list, prompts/get. The patterns stay consistent across primitives, which is one of the genuinely well-designed parts of the spec.MCP vs Function Calling vs RAGMany people ask which of these to use. The honest answer is: they are not substitutes. They each serve a different purpose.Function calling is a model capability. The model emits a structured message that says "I want to call X with these args." Function calling tells you that the model wants to invoke something. It does not tell you what tools exist, how to find them, or who will run them. MCP provides the layer below function calling — it is the communication protocol between a host and its MCP servers, allowing the host to retrieve a catalog of available tools and direct calls to the right destination.RAG is a method for placing relevant documents inside the model's context window. It works well when your data is indexable, static, and chunkable — docs, knowledge bases, codebases. RAG breaks down when the data is live: a Slack thread happening right now, an order status that changes every second, a database whose freshness matters.MCP is not a replacement for either. It is the connective tissue. You can build a RAG-backed MCP server (vector store exposed as a resource). You can build a function-calling host that uses MCP to discover what functions even exist. They compose.What You Can Actually BuildA handful of real-world patterns:An AI assistant on top of your own data. A Notion server, a Google Calendar server, a Gmail server, all plugged into Claude Desktop. Now your AI assistant can answer "what is stopping us from launching this week?" by reading three systems you already use every day.AI-driven CI/CD. A GitHub MCP server exposes PR data as resources and merge/comment actions as tools. An ops server exposes deploy controls. The model reads the PRs, makes suggestions, and — when granted permission — triggers deploys.Enterprise chat-over-data. Multiple database servers, each providing their schemas as resources and parameterized queries as tools. Users type "how much churn did we see this quarter by segment?" — the model picks the right server, pulls the schema, writes a query, runs it.Creative pipelines for niche applications. A Blender server. A 3D-printer server. The model designs an object and prints it. This is one of the examples Anthropic uses to highlight what MCP can do, and it serves as a good reminder that MCP is not only for productivity apps.What Is HardA few honest warnings, because most explainers skip past them:Permission UX is unsolved. Ideally, every tool call would surface to the user with enough context to grant or deny it. In reality, most hosts ship a blanket "allow X server" toggle, and users auto-approve almost everything. That is a security vector waiting to be exploited.Quality varies wildly across servers. Anyone can ship an MCP server. Some return clean typed schemas. Plenty return blobs of text that confuse the model. The community is still figuring out the conventions.Authorization is mostly aspirational. Local stdio servers run in user context — no problem. Remote servers need OAuth 2.1 with PKCE under the November 2025 spec revision, but adoption is a different story. A 2026 audit found only about 8.5% of public MCP servers actually implement OAuth 2.1. Roughly 25% have no authentication at all, and over half rely on long-lived static API keys. The spec is good. The deployments are not.Discovery is improving, but signal-to-noise is rough. There are real registries now — the official MCP Registry, Glama, Smithery, mcp.so — and together they catalog well over 13,000 servers. The problem flipped: it used to be hard to find a Slack server, now there are fifty and you have to guess which one is real. Security scans of large samples have found SSRF vulnerabilities in over a third of public servers. Treat unknown servers like unknown npm packages.Why This Matters Right NowWhy did MCP take off so fast? Within a year of launch, OpenAI, Google DeepMind, Microsoft, and most of the developer-tool ecosystem had shipped support. Because the alternative was unsustainable. Once you have one model that can do everything well, the bottleneck shifts to integration. The team whose model integrates with the most stuff with the least friction wins.In December 2025, Anthropic took the final step on this and donated MCP to the Linux Foundation, where it now sits under the new Agentic AI Foundation as a vendor-neutral, community-governed standard. That is the move that turns a protocol from "a thing one company shipped" into "infrastructure." It is the same arc HTTP and TCP went through.Anthropic understood exactly what OpenAI understood when they introduced function calling, and what the web understood when it picked HTTP as its integration layer: when the integration layer is closed, the ecosystem stalls. When it is open and governed by no one in particular, it compounds.We are in the compounding phase right now.If you are building: create a local stdio MCP server in the language of your choice. Official Python and TypeScript SDKs are the easiest path in. Expose the internal tool your team uses most. Plug it into Claude Desktop. You will have a working internal AI assistant by Friday.\If you are integrating: the official MCP Registry plus the bigger community catalogs (Glama, Smithery, mcp.so) collectively list well over 13,000 servers — Slack, Postgres, Stripe, AWS, Linear, you name it. Most are good enough to demo. The good ones — usually the first-party ones from the capability owner — are good enough to ship. Read the source before you run anything you do not recognize.The era where every AI application had to rebuild every integration is finally over. That is the headline.\\\\\