What Is MCP? A Plain-English Guide for Small Businesses

The three parts

The specification describes three roles. The names are a little technical, but the picture is simple:

• The host is the AI application you actually use: a desktop chat app, an assistant inside your email, or a developer’s code editor. It runs the conversation and decides what to ask you.
• A client is a connector inside that app. Each client talks to exactly one server.
• A server is a small program that exposes one system to the assistant: your calendar, your CRM, a folder of documents, your email. It can run on your own computer or as a service on the internet.

So one assistant can hold several connections at once: one to the calendar, one to the CRM, one to the documents. Each connection is separate, and that separation matters for safety (more below).

What a server can offer

The spec gives servers three main kinds of things to offer:

• Tools are actions the AI can ask to run: “find open appointments next Tuesday”, “create a job”, “draft a reply”. The model decides when a tool would help, which is why the spec says there should always be a person able to say no (more on that below).
• Resources are information the assistant can read for context: a document, a customer record, a price list. The app decides how and when to include them.
• Prompts are ready-made instructions you pick on purpose, often as a menu item or a slash command, such as a “summarize this customer’s history” template.

A well-built server for a business tool usually offers a small set of clear tools and the data needed to use them well, nothing more.

What this could look like in a small business

These are examples of the kind of thing MCP makes possible, not promises about any particular product. What you can do depends on which assistant you use and which of your tools have an MCP server:

• “What’s on my schedule Thursday, and do any of those customers have an open invoice?” The assistant checks the calendar through one connection and the accounting system through another.
• “Draft a reply to this request using our current service-area page and price sheet.” The assistant reads the documents you’ve shared with it and writes a draft you review.
• “Turn this email into a job.” The assistant fills in a new job in the CRM and shows you exactly what it’s about to create before anything is saved.

The pattern is the same each time: the assistant does the looking-up and the drafting, and you stay in charge of anything that changes a record or reaches a customer.

What MCP doesn’t do

It helps to be clear about the limits, because some of the marketing isn’t:

• It doesn’t make answers correct. The assistant can still misread a record or pick the wrong tool. Connecting it to real data helps it be specific; it doesn’t make it infallible.
• It doesn’t make anything safe by itself. The specification sets out principles: you consent to what data is shared, you approve the actions taken, and tools are treated with caution. But it says plainly that MCP can’t enforce those principles at the protocol level. The apps and servers have to build them in, and you have to set them up sensibly.
• It isn’t automation on its own. MCP connects an assistant to tools. Whether that becomes a reliable, repeatable process depends on how the work is designed around it: what gets checked, what needs approval and what happens when something fails.

Safety is part of the design

The good news is that the people who wrote the standard thought about this. A few principles from the specification are worth knowing as a business owner:

• You consent, you stay in control. People should understand and agree to what data is accessed and what actions are taken, and the app should make that easy to review.
• A person can say no. For tools, the spec says there should always be a human in the loop with the ability to deny a tool call, and apps should ask before sensitive operations and show what’s about to be sent.
• Servers stay in their lane. The design keeps servers from reading the whole conversation or seeing into other servers. The calendar connection doesn’t get to see what the CRM connection returned. That’s the design. A server’s tool descriptions still reach the AI model, though, so a badly written or malicious server can try to steer it, which is why the next point matters and why you only install servers you trust.
• Descriptions aren’t trusted blindly. A server describes its own tools, and the spec says those descriptions should be treated as untrusted unless the server itself is trusted.

I go through the practical side of this, including permissions, where servers run and what data leaves the building, in Connecting an AI Assistant to Your Business Tools Safely.

Is it ready to use?

MCP is in active use. Its documentation lists support in assistants like Claude and ChatGPT and in developer tools like Visual Studio Code and Cursor. It’s also still evolving, and the specification is versioned by date. The current revision, dated 2026-07-28, made some significant changes under the hood (each request now stands on its own, without a separate setup handshake) and marked a few older features as deprecated. Those keep working for now; the specification says they can’t be removed in any revision released before 28 July 2027.

For a business owner, that means two things. Choose well-supported assistants and servers from publishers you can identify, and expect updates. A connection set up today may need attention when the software on either end changes, the same as any other integration.

Where I’d start

Don’t start with “connect the AI to everything.” Start with one task that comes back every week and touches one or two tools:

1. Pick the task, such as sorting incoming job requests, answering the same three questions from your documents, or preparing tomorrow’s schedule.
2. Connect read-only first. Let the assistant look things up before it’s allowed to change anything.
3. Require approval for every action that changes something, like a new record, a calendar hold or an email to a customer.
4. Write down what “working” means before you begin, so you can tell whether it helps.

If you want a concrete example to follow, A Practical First Automation: From Inbox to Booked Job walks through one from start to finish.

If you’d like help deciding whether MCP fits a process in your business, that’s the kind of thing I work through with owners on business automation. Sometimes the answer is an assistant with a couple of connections. Sometimes it’s an ordinary workflow with one AI step, and sometimes it’s a spreadsheet change. I’ll tell you which.

Sources

• Model Context Protocol specification, revision 2026-07-28: overview, and the security and trust principles
• Architecture, revision 2026-07-28: hosts, clients and servers, and the design principles
• Tools, Resources and Prompts, revision 2026-07-28
• Key changes in revision 2026-07-28 and the versioning policy
• What is the Model Context Protocol?, official documentation
• Local server security, official documentation: tool descriptions from one server can steer how the assistant uses another