The Complete Guide to MCP for People Who Run Companies

Your CRM knows every deal in your pipeline. Your help desk knows every complaint from the last three years. Your finance stack knows exactly which customers pay late. And the AI your company pays for every month sees none of it, unless someone copies and pastes it in, one screen at a time.

That gap explains most of the disappointment founders share with me about AI. The tool writes a decent email but answers business questions like a smart stranger, because that's what it is. It has read the whole internet and none of your systems.

Then an acronym starts showing up in vendor pitches and board conversations: MCP. The vendor says "we support MCP," heads nod, and the meeting moves on. I've watched that nod happen with founders who admitted afterward they had no idea what they just agreed sounded good.

So this is the plain-language version, written for the person who signs the contracts.

Start with the picture most executives carry. AI integration means a custom build. Your team, or a hired one, writes code that wires the model to the CRM. Another build wires it to the help desk. Another to the accounting system. Every connection becomes its own project with its own budget, and if the company ever switches AI models, you redo every build.

Run the math on a normal mid-market stack. Say your company touches 3 AI models and you want them talking to 8 systems: CRM, help desk, email, file storage, accounting, ERP, calendar, and your data warehouse. Custom integrations mean 3 times 8. Twenty-four builds. Twenty-four things that break whenever a vendor changes an API, the connection point one piece of software offers another, and vendors change those constantly.

That math is why most companies never connect anything. They pay for a brilliant model and feed it screenshots.

MCP deletes that math.

What MCP actually is, minus the jargon

MCP stands for Model Context Protocol. A protocol is an agreed way for two pieces of software to talk, the same way HTTPS is the agreed way your browser talks to websites. Anthropic published MCP as an open standard in November 2024, and the major AI providers adopted it through 2025 and 2026. Open standard means no single company owns it and nobody pays a license to use it.

The cleanest way to picture it is USB-C. Ten years ago every device shipped with its own charger and its own port, and your drawer filled with cables that fit exactly one thing. Then the industry agreed on one port. Now one cable charges the laptop, the phone, and the headphones, and every new device works with the cables you already own.

MCP is that agreement, for AI. A software vendor builds one MCP server for their product. Server here means the adapter on the tool's side, the piece that speaks the standard. Once that adapter exists, any AI model that speaks MCP plugs into it. Your CRM vendor builds the connector once, and it works with Claude, with GPT, and with whatever model tops the chart next quarter.

Rerun the earlier math. 8 systems used to mean 24 custom builds across 3 models. With MCP it means 8 connectors, and the vendors themselves build and ship most of them. Switch models next year and the connectors don't care. I wrote a full piece on why your results shouldn't depend on which model wins the month , and MCP supplies a big part of the answer: the plumbing stays put while the models change.

One common misread deserves a correction here. People hear MCP and go looking for something to buy. There's nothing to buy. MCP is a standard your existing vendors either support or don't, the way a hotel room either has USB ports in the wall or doesn't. You made the purchase decision when you bought the CRM. The open question is whether that vendor wired the port.

What changes for the systems you already run

The abstract version sounds mild. The concrete version is where founders sit up. Walk through a normal stack at your scale.

The CRM. Today your head of sales exports the pipeline to a spreadsheet, pastes chunks into a chat window, and asks for analysis of data that went stale the moment it exported. With an MCP connection she asks the model directly: list every deal sitting in stage three past 30 days, group them by owner, and draft a follow-up for each in that rep's usual tone. The model reads the live pipeline, not a Tuesday snapshot.

The help desk. A support team at a $30M company clears thousands of tickets a quarter, and the patterns inside them die in the archive. Connect the help desk over MCP and the model reads the last 90 days of tickets on request: the three complaint themes growing fastest, the product line behind them, and the twelve largest accounts that filed them. That used to be a week of an analyst's time. Now it's a question.

The finance stack. At month-end your controller sees software spend jumped and wants the reason. Connected to the accounting system, the model pulls the ledger lines, compares them against last quarter, and names the four new vendors behind the jump, with dates and amounts. Nobody exported a report, and nobody pasted vendor data into a public chat window to get there.

The same pattern repeats across the ERP, the data warehouse, and the file store. Systems that used to hold answers hostage behind an export now answer in plain English, with the source data attached. That shift, questions getting cheap, sits under most of the results in our case studies: the data existed for years, and connecting it is what changed the cost of asking.

The pilot: one system, read-only, 30 days

Skip the company-wide rollout. The right first move is small and boring, and it follows the same five steps at every company I've helped run one.

1. Pick one system and one team. The CRM and the sales team make the most common pair, because pipeline questions come daily, carry money, and are easy to score.

2. Connect it read-only. MCP connectors carry permissions the same way user accounts do. Read-only means the model can look at data and change nothing. For the pilot, that's the whole setting.

3. Give access to five people and have them log every real question they ask for two weeks. Real questions from real work, in a shared doc, with a timestamp.

4. Score it on one number: minutes from question to usable answer, before versus during. A pipeline question that took a 40-minute export-and-format ritual and now takes 90 seconds is the whole business case in one line.

5. At day 30, decide. Expand to a second system, or stop and write down why.

The failure mode is skipping step 4. Without the logged questions and the timing number, day 30 arrives as a vibe, and vibes don't survive budget meetings.

What to ask a vendor who says "we support MCP"

The phrase now shows up in pitch decks the way "AI-powered" did two years ago, and it deserves the same pressure. Five asks separate real support from a checkbox.

1. Ask who builds and maintains the MCP server. The strong answer: the vendor ships it themselves, documented and versioned. The weak answer: someone in the community built one. Community connectors work, and they also break silently the day the vendor changes their product.

2. Ask what it can read and what it can write. A connector that reads reports sits in a different risk class from one that edits records or triggers payments. You want a vendor that offers both, with a switch that turns write access off.

3. Ask how permissions map to roles you already run. The connector should see exactly what the connecting user's account sees. If it runs on one all-access admin key for everyone, walk.

4. Ask where the data flows. Whether requests route through the vendor's servers, whether the vendor stores anything, and what their policy says about training models on your data. Get that last one in writing.

5. Ask for the audit log, the record of every request the model made, which user triggered it, and what data it touched. A vendor who can't show that log leaves you unable to answer "what did the AI access last month," and a regulator, an insurer, or a customer contract will eventually demand that answer.

One extra tell costs nothing. A vendor who describes MCP as their proprietary technology just told you they don't understand the thing they put in the deck. It's an open standard. The pitch should brag about what their connector exposes, never about the standard itself.

Where the security questions sit

MCP raises the stakes on a discipline your company already needed. Before connectors, your AI exposure stopped at whatever employees pasted into chat windows, and I wrote the paste rules for that earlier in this series . Those rules still stand. A connector opens a second, bigger door: the model no longer waits for someone to paste, it reaches into the system itself. That changes three habits.

Scope beats trust. Give every connector a dedicated service account, a login you create for software instead of a person, with the narrowest permissions the job needs. The help-desk connector reads tickets. It never touches the customer payment fields that live in the same tool, because nobody connected it with an admin key in the first place.

Read-only until write earns itself. Reading data answers questions. Writing data takes actions, and actions compound. An AI that drafts follow-ups for a human to send is a helper. The same AI writing straight into the CRM under a broad key is a day-one intern with edit rights to your system of record, the master copy of your business data. Grant write access per workflow, per system, after the read-only phase proves out and after your team has built the habit of checking AI output before it ships.

Someone owns the off switch. Name the person who reviews the audit log monthly, cuts connector access the day an employee leaves, and answers for every connection in your next security review. At NuVision Auto Glass, the $48M company where I run AI and growth, nothing connects to a system of record without a named owner and a revocation step in offboarding. The rule is dull on purpose. The exciting version of this story is the one you read in someone else's breach disclosure.

What to do this week

You need a list and four moves, and none of them require a budget line yet.

1. List your systems of record: CRM, help desk, accounting, ERP, file storage, data warehouse. At $5M to $100M the list usually runs 6 to 10 names.

2. Send each vendor the five asks from the section above. Their answers sort your stack into three piles: ready, not yet, and never.

3. Take the one ready system where questions burn the most team hours and run the 30-day read-only pilot, timing log included.

4. Write the access rules before anything goes live: service account, narrowest scope, named owner, offboarding step.

Do that and the acronym stops being a polite nod in a vendor meeting. The next pitch deck that says "we support MCP" meets a founder holding five questions and a pilot plan, and the AI you already pay for finally starts reading the business it works for.

Everything above works whether or not we ever talk. If you want a second pair of eyes on it, my team at NuroSparx maps this exact stack for US companies between $5M and $100M. Tell us what you run and we'll flag which systems are ready and which connectors to refuse, or book a call if talking beats typing. And if connectors feel early for where your company sits, start with the five automations every team should run first .