What Is an MCP Server? A Plain-English Guide

If you have spent any time around AI tools in the last year, you have probably run into the acronym MCP — usually in a sentence that assumes you already know what it means. It stands for Model Context Protocol, and despite the intimidating name it solves a very ordinary problem: AI assistants are clever but they know nothing about your business, and pasting your data into a chat window is a miserable way to fix that. This guide explains what an MCP server is, why it matters if you run a service business, and the questions worth asking before you connect one to your company's data.

The short version

An MCP server is a translator that sits in front of a software system and offers an AI assistant a menu of things it can do — look up a customer, check a schedule, create a quote. Connect one and your assistant can work with live data instead of whatever you last copied and pasted. The security questions matter more than the technology does.

The problem MCP solves

An AI assistant on its own is a very well-read stranger. It can explain how maintenance agreements work in general, but it has no idea what yours cost, who is signed up, or who is due for a visit this month. For a while, the only workaround was manual: export a spreadsheet, paste it into the chat, ask your question, and repeat the whole ritual tomorrow when the data changed.

That is tedious, it goes stale immediately, and it quietly pushes you toward pasting far more data than the question actually needed. What people really wanted was for the assistant to just look things up.

So what is an MCP server?

Think of a restaurant. The AI assistant is the customer; your business software is the kitchen. The MCP server is the waiter with the menu. It tells the assistant exactly what can be ordered — "look up a customer", "list this week's visits", "create a draft quote from a template" — and what information each order needs. When you ask a question, the assistant picks an item off that menu, the server carries the request to the kitchen, and the answer comes back.

Three things follow from that arrangement, and they are the whole reason MCP caught on:

The answers are live. The assistant queries the system when you ask, so it sees today's schedule, not last Tuesday's export.
The menu is finite. The assistant can only call the tools the server actually offers. It cannot wander off and do something that isn't on the list.
Tools can do things, not just fetch things. If the server offers a tool that creates a record, the assistant can create the record — which is what turns a chat assistant into something that actually saves you time.

The reason it is a protocol rather than a one-off integration is that it works the same way everywhere. A vendor writes one MCP server; Claude, ChatGPT, and any other MCP-capable client can all use it. That is a meaningful shift from the old world where every AI integration was bespoke and every vendor built the same thing five times.

What this looks like for a service business

Concretely: your field service software publishes an MCP server. You connect it to the assistant you already use. Now you can ask things like "what's booked for Thursday and who has capacity?" or "which quotes from last month never got a follow-up?" and get a real answer from your real data. If the connection includes write access, you can go further — "start a draft quote for the Cedar Ridge job using our standard land-clearing template" — and the draft lands in your system where your crew and your accountant expect it.

The value is not that the AI writes prettier text. It is that the twenty-minute detour to go and look something up collapses into a sentence, and the answer is trustworthy because it came from the source.

You don't have to use MCP to use AI

Plenty of software now ships its own AI agent built directly into the product, which requires no connectors, no setup, and no second subscription. MCP is for people who would rather bring the business into the assistant they already live in. Both approaches can be good; they suit different habits.

The security questions that actually matter

You are considering giving an AI assistant a door into your customer list, your pricing, and your invoices. That deserves more scrutiny than a typical software integration, and the good news is there are only a handful of questions to ask. Any vendor with a properly built server will answer all of them quickly.

1. Whose permissions does it use?

This is the big one. If the connection runs under a company-wide service account, then anyone who connects can potentially reach anything — including payroll figures, margins, or customer records they have no business seeing. The right answer is that the connection runs under the individual user's own permissions, and that those permissions are rechecked on every call rather than frozen at the moment you connected.

2. Is it OAuth, or an API key?

An API key is a long-lived password. Once it exists it tends to end up in a settings box, a note file, and eventually a screenshot in a support ticket. OAuth is better: you approve the connection by signing in normally, the assistant receives short-lived tokens instead of a permanent secret, and you can revoke access without changing anything else. Ask about token lifetimes too — access tokens should expire in minutes, not months.

3. What can it never do?

A thoughtful vendor has a list. Sending messages to your customers, taking payments, and accepting contracts on someone's behalf are the classic three, because a mistake there costs money or a relationship. If a vendor cannot tell you what their server refuses to do, they probably have not thought hard about what happens when the AI misunderstands you.

4. Can you choose how much access to grant?

Read-only should be an option, and it should be the one you start with. A good server offers tiers — read, then some limited reversible writes, then full access — and shows you which one you are approving before you confirm.

5. Is there an audit trail?

You want a record of every tool call: who, which company, which tool, and what the outcome was. You also want the vendor to be clear that the audit trail does not store the record contents themselves — logging your customers' details into a second system is not an improvement.

6. Can you revoke it instantly?

Connections should be listed individually and killable on their own, without disturbing anything else. If an employee leaves, removing them from the company should shut their connection down on its next call.

Question	Good answer	Walk away if
Whose permissions?	The signed-in user's, rechecked every call	A shared company service account
How do you authenticate?	OAuth with short-lived, rotating tokens	A permanent API key you paste in
What's off-limits?	A clear list — messaging, payments, acceptance	"It can do anything you can do"
Access levels?	Read / limited writes / full, chosen at approval	All or nothing
Audit trail?	Per-call, without storing record contents	None, or a chat transcript
Revocation?	Instant, per connection	Support ticket required

One thing people forget: your automations still run

If your software fires an automation when a quote is created — a notification, an email to the office, a status change — that automation will fire for records created through MCP too. That is usually what you want, but it surprises people the first time. Review your automation rules as part of connecting rather than discovering the behaviour on a live customer.

Is it worth doing?

If nobody at your company uses an AI assistant day to day, probably not yet — you will get more from software with a built-in agent than from wiring up a tool you rarely open. But if you or your estimator already work in Claude or ChatGPT, connecting your business system is one of the highest-leverage hours you can spend. The lookup tax you have been paying without noticing simply disappears.

Start read-only. Live with it for a week. Move up an access level when the thing has earned it.