In February 1904, a fire broke out in downtown Baltimore. Companies raced in from as far as New York and Philadelphia to help. When they got there, their hoses didn’t fit the local hydrants. Every city had settled on its own thread pattern, and Baltimore’s happened to be one of hundreds of incompatible standards in use across the country. The fire burned for more than a day and destroyed roughly 1,500 buildings while trucks full of water and crews ready to work sat useless at the curb.

That’s what most businesses run into when they try to give an AI agent real work to do. The agent can write an email, summarize a call, or draft a proposal all day long. Ask it to actually book the appointment in your scheduling system, pull a customer record from your CRM, or check what’s in stock, and it hits the same problem Baltimore did: the connector doesn’t fit. MCP, the Model Context Protocol, is the fix. It’s a standard coupling for AI tools and business software, and it’s worth understanding even if you never touch the technical details yourself.

MCP in plain English

MCP stands for Model Context Protocol. Set the name aside — you’ll never type it into anything. What matters is what it does: it gives an AI application a standard way to discover what a piece of software can do and to actually call on it to do those things, instead of just reading about it.

The people who built it describe it this way: “Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.” Before USB-C, every device needed its own cable and its own port. MCP is doing the same job for AI tools and business software — one connector standard instead of a drawer full of incompatible cables.

Anthropic, the company behind Claude, created MCP and released it as a free, open standard in November 2024. It didn’t stay Anthropic’s alone for long. OpenAI and Google DeepMind have both since added MCP support to their own AI tools, which is the part that actually matters for you: it means an integration built to the MCP standard isn’t locked to one AI vendor. Anthropic has also since handed day-to-day governance of the protocol to an independent open-source foundation, so it isn’t run as one company’s private project going forward.

The problem it actually solves

Before a standard like MCP existed, connecting an AI tool to a business app meant custom-writing that one connection. A developer had to study your CRM’s particular API, handle its particular authentication, and build code that translated between “what the AI wants to do” and “what this specific piece of software expects.” Then a different AI tool came along, or the CRM changed vendors, and that work started over.

Multiply that out and the math turns ugly fast. Say your business runs a CRM, a scheduling tool, and accounting software, and you want two different AI tools to be able to reach all three. That’s not five connections — it’s six, because each AI tool needs its own link to each app. Add a fourth business system and you’re at eight. Every new tool on either side multiplies the work, not adds to it.

MCP turns that multiplication into addition. When a software vendor builds one MCP server for their product, any MCP-compatible AI tool can use it without a custom build. The vendor does the integration work once; everyone downstream inherits it. That’s the entire point of a shared standard, and it’s why an ecosystem of ready-made connectors for common business tools has grown quickly since MCP’s release.

How it works, without the jargon

You don’t need the technical details to use MCP, but the shape of it helps when you’re evaluating a vendor or a project. Four pieces, each with a plain-language job:

• Host: the AI application itself — Claude, or whatever tool your team is using.
• Client: the part of that AI application that opens and manages a connection to one outside system.
• Server: a small program that sits in front of a specific tool — your CRM, your calendar, your inventory system — and exposes what that tool can do in a format the AI understands.
• Tools: the specific actions the AI is allowed to call through that server — “create a contact,” “check availability,” “look up an order.” This is the part that matters most for security, because a tool is an action, not just a piece of information.

MCP servers also generally distinguish between resources, which the AI can read, and tools, which the AI can use to actually change something. An agent that can read your calendar and one that can move appointments on it are two very different levels of trust, even though both might connect through the same MCP server. That distinction is worth asking about directly whenever someone sets up a connection for you.

Real examples, not hypotheticals

This isn’t a future-tense technology. Software vendors are already publishing their own MCP servers so their products work with AI tools out of the box:

• CRM: HubSpot runs an official, HubSpot-hosted MCP server that gives AI tools read and, where authorized, write access to contacts, deals, and tickets — respecting whatever permissions the connecting account already has.
• Everyday business tools: Anthropic’s own Claude Connectors directory is built on MCP and covers Google Workspace (Gmail, Calendar, Drive), Slack, Microsoft 365, and hundreds of other services, each with its own scope of what Claude is allowed to read versus change.
• Developer and data tools: GitHub and common databases were among the first MCP servers built, since software teams were the earliest adopters.

For mainstream business software, there’s a decent chance someone has already built the connector. Where the gap still shows up is niche, industry-specific software — a field-service platform built for one trade, a practice-management tool with a small user base. Nobody has built an MCP server for software like that yet, which is exactly where a custom integration project still makes sense.

When this matters for your business

You don’t need to think about MCP at all if your AI use is limited to drafting text, summarizing documents, or answering questions with no connection to your live systems. It starts to matter the moment you want an agent to do something in a system of record: log a lead, check inventory before quoting a job, pull a customer’s order history mid-conversation, or update a record instead of just describing what should change.

At that point, the practical question isn’t “should we use MCP” — it’s “does our software already have an MCP server, and if not, is building one the right move.” For popular platforms, the answer is usually to use what the vendor already ships and focus your effort on deciding what the agent should be allowed to do with it. For niche or in-house software, a purpose-built connector may still be the only path, and it’s a smaller, more contained project than wiring that same system to every AI tool separately by hand.

The security consideration that actually matters

Here’s the part worth taking seriously: an MCP server doesn’t invent its own permissions. It inherits whatever access the account you connect it with already has. Connect a CRM’s MCP server using an admin login, and the agent has admin-level reach into that CRM, whether or not it needs it for the task at hand.

The right mental model is simple and not new: treat an AI agent’s tool access exactly the way you’d treat a new employee’s system access. You wouldn’t hand a new hire the owner’s login on day one “to keep things simple.” The same logic applies here.

• Use a limited account, not an admin one. Connect tools with the least access that gets the job done, the same way you’d set up any employee’s permissions.
• Prefer read-only where you can. An agent that can look things up but not change them removes most of the downside while still saving real time.
• Know whether it runs locally or remotely. A remote server means your data is leaving your building and passing through a vendor’s infrastructure. That’s often fine, but you should know it’s happening.
• Ask what happens when it gets something wrong. Is there a log of what the agent did? Is there a confirmation step before anything irreversible, like deleting a record or sending a payment?
• Know who built the connector. A researcher-documented risk category called tool poisoning involves a malicious or compromised server hiding instructions inside the data it returns to the AI. It’s a real, studied risk category, and the practical defense is the same as vetting any other vendor: use servers from software companies you already trust, not obscure third-party listings.

None of this is a reason to avoid MCP. It’s a reason to treat “connect the agent” with the same care you’d give “grant system access,” because that’s functionally what you’re doing.

Where this leaves you

MCP isn’t a product you buy, and you’ll probably never see the term again once it’s set up correctly. It’s the plumbing that lets an AI agent stop describing what it would do in your systems and start actually doing it. The standard exists now, which means the hard part of an AI agent project usually isn’t the wiring — it’s deciding which systems an agent should touch, what it should be allowed to change, and who’s watching what it does.

If you’re weighing which of your own tools an agent should connect to, and what permissions make sense for your business, that’s a scoping conversation worth having before any building starts. Our AI agent development work covers exactly that, or you can get in touch and describe your stack and we’ll tell you where the real work is.

Frequently Asked Questions