July 4, 20262 min read#MCP#AI agents#Foundations

MCP, explained like plumbing

Model Context Protocol is the reason AI stopped being a chatbot and started being a workforce. A plain-English explanation for people who run businesses, not servers.

By Build Tech Deploy

Every explanation of MCP starts with the phrase "Model Context Protocol" and loses the reader by the second paragraph. Let's try plumbing instead.

The problem: smart, but sealed in a box

A language model on its own is a brilliant advisor locked in a room with no phone. It can tell you how to update your CRM, draft the email, plan the campaign — but it can't touch any of it. Every real action still routes through a human copy-pasting between the AI and the actual tools.

That gap — between knowing and doing — is why so many "we tried AI" stories end with a shrug. The thinking was automated; the work wasn't.

The fix: standard pipes

Before standardised plumbing, every building's water system was a custom job. Every fixture needed its own fittings; connecting anything to anything was a bespoke project.

MCP is standardised pipework for AI. It's an open protocol — originally introduced by Anthropic, now adopted across the industry — that defines one common way for an AI model to connect to external tools: your email, your database, your e-commerce platform, your design tools, your calendar.

The consequences are the same as with real plumbing:

  • Build once, connect anywhere. A tool that speaks MCP works with any AI that speaks MCP. No per-pair custom integration.
  • The catalogue compounds. Thousands of MCP servers already exist — Shopify, Notion, Slack, Google Workspace, Stripe, databases, browsers. Each one is a capability your AI gains by connecting, not by being rebuilt.
  • When something doesn't exist, you build the pipe, not the plumbing standard. We needed our AI to publish across social platforms through a scheduling service that had no MCP server. So we wrote one — a few hundred lines of TypeScript — and every AI agent we run gained publishing as a native ability.

What this looks like in a real business

The difference is between an AI that describes work and an AI that completes it.

Concretely, from systems we run daily: a content pipeline where the AI reads the content plan from Notion, generates the designs, and publishes to four platforms through that custom MCP server — with a human approving before anything goes live. An email program where the AI builds and pushes branded Klaviyo templates directly. An operations assistant that reads real files, updates real trackers, and answers from real data.

None of that is a chatbot with better answers. It's the same underlying model, given hands.

When you don't need it

Honesty clause: if your use of AI is drafting, summarising, and thinking-out-loud, you don't need MCP — a plain chat interface is fine, and adding infrastructure would be theatre.

MCP matters at the moment a repeated workflow crosses tools: read from here, decide, write to there. That's the trigger. If you can describe a task as "take X from system A, transform it, put it in system B, every week" — that's a pipe waiting to be fitted, and it's usually days of work, not months.

The businesses getting compounding value from AI right now aren't the ones with the cleverest prompts. They're the ones who connected the pipes.

One system a week, in your inbox

Architecture, trade-offs, and what it replaced. No fluff, unsubscribe anytime.