Hi there!

Welcome to the 29th edition of Work in Beta.

In this edition, we take the word everyone is throwing around and make it simple. What MCP actually is. Who made it. And why your AI can suddenly reach into the apps where your work already lives.

So, let’s dive in!

Someone in a meeting says it first. “We should just hook up the MCP for that.”

Two people nod. So you nod, holding a word you cannot define. Then you start seeing it everywhere. MCP. MCP server. Connector. And the quiet thought that comes with it: everyone seems to get this but me.

You are not behind. This word did not exist two years ago. It went from a niche developer term to something in your meetings faster than almost anything in AI, and nobody stopped to explain it in plain English.

So here it is, the way it should have been explained the first time. In plain English.

Before we define it, let’s take the fear out of it.

MCP is not a new chatbot. It is not a new AI. And it is not something you will ever build or code.

Those three words you keep seeing? MCP, MCP server, connector. Treat them as the same family for now. The differences do not matter yet, and they may never matter to you.

So hold the word loosely. We will tell you what it really means in a minute. First, you need to see the problem it fixes.

Think about how you used to work with AI some time back. You pasted in the email, you uploaded the deck from your desktop, you copied the numbers from a spreadsheet, you carried the answer back into a Slack thread.

AI was not touching your apps. You carried everything back and forth between your AI tool and your work app. That was not a small annoyance. It was a constant back and forth that was eating a lot of your time.

So why did the apps not just talk to each other?

They did. They do. But look at what it cost to build. If you wanted ChatGPT to reach your CRM, OpenAI had to build that connection. If you wanted Claude to reach the same CRM, Anthropic had to build its own, separately.

Each AI tool needed a separate connection to each app. Fifty AI tools and fifty apps means 2,500 connections, each built by hand. Nobody builds 2,500 of anything. So you got a short list: whatever the big company had gotten around to. Everything else, you carried by hand.

Here is the fix, and it is almost too simple. Instead of building 2,500 connections individually, each app describes itself just once, in a way any AI can read.

That is MCP. Anthropic built it and published it, free and open, in November 2024.

A shared format only works if everyone actually uses it, so watch what Anthropic’s rivals did. OpenAI took it up in March 2025, Google in April, Microsoft in May. Then Anthropic gave it away, handing MCP to a neutral group that Google, Microsoft, Amazon and OpenAI all help pay for now.

No single company owns it. That is the whole reason it works. A format controlled by one AI company is a format every other app would refuse to write for.

So here is the definition, now that it can mean something.

MCP is an agreed format for an app to tell any AI two things. One, here is what you can read. Second, here is what you can do.

That is also why you cannot stop hearing about it. The UK AI Security Institute counted the public MCP tools built in the first fifteen months: about 5,000 near the start, more than 177,000 by early 2026.

So what does an app actually hand your AI through MCP? A menu.

It is a list of the two things from that definition: what your AI may read, and what it may do. Slack’s menu offers search messages, find a channel, send a message. Your AI can only pick from these options. If “delete a channel” is not on the menu, no AI is deleting your channel, however nicely it is asked.

But reading and doing are not the same. Reading is safe: searching a drive or finding a thread changes nothing. Doing is not: sending a message or updating a record leaves your name on something new.

So the app writes the menu, but you decide what your AI may order from it. For every item, Claude lets you choose among ‘always allow’, ‘ask me first’, or ‘blocked’. The simple rule: let it read freely, and make it ask before it does anything.

You decide what your AI does with a connector. But there is a question that comes before that one: should you add the connector at all?

Because MCP is open, anyone can write one. That is why there are 177,000 of them, and it is also the catch. Connecting one hands its menu to your AI and points it at your real work: your email, your files, your messages. Slack wrote Slack’s connector, and you can trust Slack with Slack. But plenty of connectors come from people you have never heard of.

So before you connect anything, one question matters most: how much did anyone check it?

Every connector carries a label that answers exactly that. In Claude:

And even a verified connector is not an endorsement. Anthropic does not run these connections, and it does not control how they handle your data. The label is not a guarantee. It just tells you how hard someone looked, so you can decide how much to trust it with your work.

Found a connector you trust? A few habits keep you out of trouble.

Working with AI has meant being its courier. You carried the email in. You carried the answer out. Then you did it again for the next app, and the next.

MCP is what ends that. Not a tool you have to learn. Not a thing you will ever build. Just the agreed way an app hands your AI a menu: here is what you may read, here is what you may do. Now you ask once. It finds the thread, opens the deck, pulls the numbers, and drafts the reply, right where the work already lives.

So do one thing this week. Connect one app. In Claude that is Settings, then Connectors, and every other big AI tool has its own version of the same list. Then ask your AI what it can now read, and what it can now do. It will read you the menu. That is this entire edition, on your screen, in ten seconds.

You do not write the menu. You just decide what your AI is allowed to order from it.

- PD & Sonali

Most professionals know AI can do more for them. The gap isn’t awareness - it’s knowing where to start, what to change, and how to make it stick.

That’s what we work on through Work in Beta.

For individuals, we run working sessions, not teaching sessions. You bring a real problem from your actual work; we build the solution with you, live. You’re borrowing our learning curve instead of grinding through your own. You walk out with something that works and the muscle to keep going. When you get stuck later, we’re a message away.

You probably have a version of at least one of these:

Bring that. We’ll build it with you.

For organizations, AI adoption is a people problem, not a technology problem. Your teams have the tools, what’s missing is the translation layer between AI capability and daily work. Which processes to redesign, which habits to break, how to build genuine fluency, not just awareness. We help close that gap through hands-on training, process redesign, and deep adoption engagements. Not advisory, forward-deployed.

If any of this resonates, email us at [email protected] / [email protected] and we will figure out how to work together.