MCP: The Quiet Standard Making AI Actually Useful
About a year ago, Anthropic released something called the Model Context Protocol. Most people scrolled past the announcement. I almost did too. Twelve months later it has been adopted across the industry, and it is quietly the reason my AI tools stopped being a chat window and started being coworkers.
I am not a protocol engineer. I am a communications guy who has spent twenty years in video, branding, and church production, and the last stretch of my career building AI workflows for myself and for the organizations I serve. So this is not a spec walkthrough. It is a field report from someone who actually runs his week on this stuff, written for the person who keeps hearing the letters MCP and nodding politely.
The plain-English version
An AI model on its own can only talk. It cannot see your email, your project board, your community platform, or your file storage. Every vendor used to solve this with one-off integrations that broke and did not transfer.
It is worth pausing on how bad the old way actually was, because the improvement only makes sense against it. Before a standard existed, connecting an AI to a tool meant somebody built a custom bridge between that one AI and that one tool. Switch models, rebuild the bridge. The tool updates its interface, the bridge breaks. Want the AI to use two tools together, and you were mostly out of luck, because the bridges did not know about each other. I lived this. I had automations held together with the digital equivalent of gaffer tape, and I spent more time repairing them than benefiting from them.
MCP is a standard plug. Think USB. A tool exposes what it can do through the protocol, and any model that speaks it can pick those tools up. Write once, connect everywhere.
The USB comparison is more exact than it sounds. Before USB, every device had its own port and its own cable, and the back of your computer looked like a junk drawer. USB did not make any single device better. It made every device compatible, and compatibility turned out to be the feature that mattered. MCP does the same thing for AI: the tool describes what it can do in a standard way, the model reads that description, and suddenly they can work together without anyone building anything custom in the middle.
One more piece of vocabulary and then I promise we are done with jargon. The thing that exposes a tool through the protocol is called a server, and the AI application that picks it up is called a client. Your email can have a server. Your task manager can have a server. Your community platform can have a server. The assistant is the client that connects to all of them at once. That "all of them at once" part is where this stops being a tech story and starts being a work story.
Why a communications person should care
Here is what this looks like in my actual week. My assistant can read the community platform I manage, draft posts in our voice, check the content calendar, and stage email drafts for my review. Not because someone built a custom integration for my exact stack, but because each of those systems has a connector and the model can use all of them in one conversation.
Let me walk through one real morning, because the abstract version undersells it. I manage communications for ministry organizations, which means a normal week involves a community platform, an email tool, a scheduling calendar, and a task board, each of which used to be its own tab and its own context switch. On a recent Monday I asked my assistant to check what had been posted in our community spaces over the weekend, summarize the conversations that needed a response from me, draft two of those responses in our established voice, and add the follow-ups to my task list. One request. Four systems. The assistant read from the community, wrote drafts I could review, and filed the tasks, and I did not copy or paste a single thing.
None of those individual steps is impressive. I could do each of them myself in a few minutes. What I could not do myself is have them already done by the time I sat down with my coffee. The value is not that any single action got automated. The value is that the connective work between systems, the swivel-chair labor that eats communicators alive, went away.
The compound effect is the point. One tool connected is a convenience. Eight tools connected is a workflow. The model can carry context from a meeting transcript into a task list into a draft announcement without me copying and pasting between tabs like it is 2019.
Here is the pattern I keep noticing: every additional connected tool makes the previously connected tools more useful. Calendar alone is a nice lookup. Calendar plus email means drafts that know about upcoming events. Calendar plus email plus the community platform means an announcement pipeline that starts from real dates and lands in real channels, in the right voice, waiting for my approval. The math is not additive. It is closer to multiplicative, and that is why the organizations experimenting with this now are going to be hard to catch later.
What I learned setting this up for a real organization
Theory is nice. Here is what actually happened when I wired this into working ministries, with the scrapes still visible.
First lesson: the voice work comes before the plumbing. An assistant with access to your community platform can post in it, but making it sound like your organization takes deliberate effort. I spent time up front writing down what our voice actually is, the phrases we use, the ones we never use, the way we open and close things. That document does more for output quality than any technical setting. If you skip it, you get generic content delivered efficiently, which is arguably worse than no content at all.
Second lesson: start read-only, and stay read-only longer than you think you need to. For the first stretch, my assistant could look at everything and touch nothing. It summarized, it drafted, it flagged. Every actual send, post, and publish went through me. That period is where you learn the failure patterns: where the model misreads context, which tasks it handles cleanly, which ones it fumbles. You want to learn those lessons while a human is still between the assistant and your audience.
Third lesson: the assistant is a very fast intern, not a deputy. It does excellent first drafts and terrible final judgment. The moments it gets something subtly wrong are exactly the moments a seasoned communicator earns their keep: the announcement that is technically accurate but tone-deaf to something happening in the community that week, the reply that is correct but cold. I keep a human, usually me, on every send button, and I have seen nothing in a year of daily use that makes me want to change that.
Fourth lesson, the happy one: maintenance has been almost boring. The custom automations I ran before needed constant repair. The standardized connectors mostly just work, and when a tool improves its connector, my whole setup gets better without me doing anything. That is what a standard buys you. The gaffer tape era of my workflow is over and I do not miss it.
Where to start
If you lead communications for an organization, you do not need to write code to benefit. Check whether the tools you already pay for offer MCP connectors. Start with read-only access, let the assistant summarize and draft, and keep a human on every send button.
If you want a concrete first project, here is the one I recommend to every comms lead I talk to: the Monday morning brief. Connect your assistant to two or three systems in read-only mode, your inbox, your calendar, your community or social platform, and ask it every Monday for a summary of what happened, what is coming, and what needs your attention. It is low risk because nothing gets sent anywhere. It is high value because it replaces the ninety scattered minutes you currently spend gathering that picture yourself. And it teaches you, gently, what this technology is and is not good at, which is the education you actually need before you automate anything that touches your audience.
From there, expand one permission at a time. Drafting next. Then maybe scheduling. Each step earns the next one. The organizations that get burned by AI tooling are almost always the ones that connected everything and authorized everything in week one, because the demo looked great.
The organizations that figure out this plumbing in the next year will look unreasonably productive from the outside. A three-person communications team will ship like a team of eight. A solo church communicator will run a content operation that used to require a staff. People will ask what they are doing differently, and the answer will be unglamorous: their tools can finally talk to each other, and a tireless assistant sits in the middle doing the connective work nobody ever wanted.
It is not magic. It is plumbing. But plumbing is what makes a city work.