What Is MCP? The Standard Behind Your AI Connectors, Explained

"So what actually is MCP? It keeps coming up while I'm connecting things."

Short version: MCP is the common standard that connects AI to outside tools and data. It stands for Model Context Protocol, and the official docs describe it as "a USB-C port for AI applications." The Claude connectors and ChatGPT plugins you've used throughout this track all run on top of this same standard. Gemini's connected apps are a bit different, and we'll get to why below. There's nothing to install today and no code to memorize, just one concept to understand and this track is done. If you already put a connector to work in an earlier lesson, that was already running on MCP. If you only came here for the MCP explanation, this lesson stands on its own.

MCP (Model Context Protocol)

An open standard that connects AI applications to outside data and tools. The way charging ports used to differ from device to device before everything converged on USB-C, the way AI tools used to connect to each service in a different, one-off way before MCP gave them a shared standard. Anthropic released it in November 2024, and since December 2025 it's been governed as a shared standard under the Linux Foundation.

What is MCP, exactly?

Start with something familiar: the phone charger. Picture a drawer of cables from before USB-C took over. iPhones ran on the 8-pin Lightning connector. Android phones, Samsung included, mostly used micro-USB. Every phone had its own shape of port, so drawers filled up with cables nobody could identify anymore, and running out of battery away from home meant asking a stranger "what cable do you carry?" before anything else could happen.

Now the same cable charges an iPhone, a Galaxy, a laptop, and a tablet. Even the iPhone made the switch, starting with the iPhone 15. That happened because device makers and cable makers agreed on one shared spec instead of building a custom fit for every combination. Once the standard settled, one cable was enough.

AI connections had the exact same problem. There are several AI tools: ChatGPT, Claude, Gemini. There are several services you'd want to connect to them: Drive, Notion, Slack. Without a shared standard, every combination needs its own custom-built connection. Three AI tools and ten services means thirty separate connections to build and maintain. When Anthropic introduced MCP in November 2024, they framed it explicitly as replacing that fragmented mess with a single standard. The idea: a service only has to build one standard-compliant connection point, and every AI that supports the standard can plug straight into it.

So would competitors actually adopt a standard built by one company? Here's the twist: they did. On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation, a body under the Linux Foundation. Anthropic, OpenAI, and Block co-founded that foundation, with Google, Microsoft, AWS, and others joining as supporters. The company behind Claude and the company behind ChatGPT agreed on the same connection standard. By the numbers Anthropic shared in that donation announcement, more than 10,000 MCP servers had already been published, and the developer SDKs were being downloaded 97 million times a month. Instead of a standards war, this is one of the rare cases where everyone converged on a single approach, the way USB-C did.

How are connectors and MCP related?

So how does what you connected in this track relate to MCP? If a connector is the finished cable, MCP is the port spec that cable has to match. When you connected the Google Drive connector back in lesson 2, you didn't need to think about the standard underneath it, the same way you don't read a USB-C spec sheet before buying a cable. But that smooth connection was only possible because of the shared standard sitting underneath it.

Here's how it plays out tool by tool.

• Claude: Anthropic stated in its donation announcement that the connector directory is built on MCP. The custom connector menu, for adding a service that isn't in the directory, is described by the official docs as literally a way to register a "remote MCP server."
• ChatGPT: According to OpenAI's developer docs, plugins use an MCP server as the channel whenever they read live information from an outside service or take an action there.
• Gemini: Connected apps, covered in the last lesson, work differently, that's Google wiring its own services in directly. Gemini's developer API does support connecting to MCP servers, though.

What does a shared standard actually get you? Two things. A service builder only has to build one MCP connection point, and it works in Claude and in ChatGPT alike, so the number of services you can connect to keeps growing fast. And if a service isn't in any directory yet, having an MCP connection point at all means you can wire it in yourself through a custom connector. That door is open even on free accounts, capped at one custom connector. This is exactly the case we set aside in lesson 2's troubleshooting section as "if it's not in the directory, that's custom-connector territory."

Why "MCP server" keeps coming up

Search for MCP and one phrase follows you everywhere: MCP server. The word "server" tends to conjure up a server room, blinking green lights, and a small wave of intimidation, but the meaning here is much more modest. An MCP server is just the program on the other end of the connection that handles the AI's requests.

Think of a restaurant. The AI is the customer, the kitchen is a service like Notion or Drive, and the MCP server is the staff member who takes the order to the kitchen and brings the food back out. It's a server in the literal sense, the one doing the serving. Ask "find last month's meeting notes" and the MCP server is what goes into Drive, finds the document, and hands it back to the AI. Per the official architecture docs, the AI app making the request is called the host, and the program answering it is called the server. That program can run locally on your own machine, or remotely on the service provider's infrastructure. Most connectors you use on the web are talking to a remote server on the other end.

Worth drawing a line here: you're never going to build an MCP server. Search "how to build an MCP server" and most of what comes back, articles and YouTube tutorials alike, is written for developers setting up a brand-new connection point. A customer doesn't need to memorize the staff training manual. All you need to do is pick from the connection points that already exist and connect to them.

There's one safety rule worth keeping even as the customer, though: don't connect a custom connector to just any server. Custom connectors are a door to services Anthropic hasn't vetted. The official docs warn that a malicious MCP server could hide instructions that push the AI into doing something you didn't intend. Only connect to servers officially run by companies you trust, read the permission screen the way you learned in lesson 1, and approve from there.

How much of this does a non-developer actually need to know?

Your relationship to MCP splits into three layers: understanding the concept, picking and connecting a server someone else already built, and building a server yourself.

• Understand the concept: MCP is a shared standard, and connectors run on top of it. This lesson covers that, and you're done.
• Pick and connect: choosing a connector from a directory, or registering the official MCP server address for a service you trust. You've already done the directory version; registering one directly comes up hands-on in the next track.
• Build one yourself: developing a brand-new connection point for your own company's systems. That's development work, full stop.

As a marketer, the first two layers are all you need. Leave the third to a developer. Getting value out of a shared cable standard requires knowing how to recognize a port and plug into it, not owning a cable factory. Use that same line when you come across deeper MCP tutorials or YouTube videos: if the title says "build," "set up," or "develop," it's written for that third layer. You don't need it right now, so there's no reason to feel behind.

Track complete: next stop is the terminal

Let's look back at the steps this track walked through. Lesson 1 covered the connector concept and how to read a permission screen. Lesson 2 had you connect Drive to Claude yourself. Lesson 3 compared connecting ChatGPT and Gemini. Lesson 4 had you put those connections to work on Drive, Gmail, and Calendar, and today you confirmed the standard sitting underneath all of it. The hand that used to carry files around now manages connections instead.

The next track moves the stage outside the browser. You'll learn to use AI from the terminal, and in that track's last lesson, you'll use the claude mcp add command to register an MCP connection yourself, the same kind of connection you learned about today. That's where today's groundwork pays off.

One preview: the moment you move to the terminal, a new question shows up. AI in the terminal can already read your files and run commands without any MCP connection at all. So if the same job can be done either by command or by MCP, where's the line between them? Once you actually use it, you'll watch the AI handle some tasks with a command and others through MCP. That distinction gets covered in the last lesson of the next track.

I lived through the pre-MCP era. Connecting a service to AI meant getting an API key, going into the Google Cloud console to create credentials, downloading a JSON file, putting it somewhere the app could find it, and even then it often didn't work. Figuring out what went wrong could eat several days.

Once MCP showed up, that whole process disappeared. Recently, connecting a service just meant pasting in one address, and later even that step went away. Now it's just picking from a list.

What I didn't realize for a long time, though, was that this was MCP. I was using Claude Code in the terminal every day and still didn't put it together, because I thought of the connectors I used on the web and the MCP I set up in the terminal as two separate things. I found out by accident. I connected one connector on the web, and when I opened the terminal, it was already there too. It amazed me at the time. Now I know why, so it shouldn't. What amazes me now is that it ever did.

They're built on the same standard, so connecting on one side makes it show up on the other. Once you understand a single concept, there's one less thing you have to remember separately.