How to Connect Claude to Your Business Tools With MCP

What does MCP actually do for a business?

MCP lets Claude reach your business systems directly, so it answers from your real data instead of from whatever you remembered to paste in. MCP stands for Model Context Protocol. It is an open standard for describing what a tool can do and how an AI assistant may use it. Practically, it means the difference between exporting a CSV, uploading it, and asking a question - versus just asking the question and having Claude go and look.

The reason this matters more than another integration announcement is that it removes the copy-and-paste tax from every single AI task. Most business use of AI dies at that tax. You know Claude could draft the follow-up, but pulling the deal history out of your CRM takes four minutes, so you write the email yourself. A connector removes those four minutes permanently, and the AI task you kept skipping becomes the default way you do the job.

• A server is the piece that exposes one system, such as your file storage, your project tracker, or your database.
• A tool is a single named action that server offers, such as search files, read issue, or create record. Claude picks the tool that fits the request.
• A connector is what you actually add and sign in to in the app. One connector usually brings several tools with it.

Where do I set connectors up?

In the Claude desktop app, under its settings, in the connectors section. That is the default path and the one to use unless you have a specific reason not to. You add a connector, sign in to the underlying account when it asks, and it is available in your conversations from then on. There is no code and no config file to hand-edit.

People assume this is a terminal job because the early writing about MCP was aimed at developers. It is not, and framing it that way costs owners weeks. The desktop app is the front door. The terminal is optional, useful mainly when you are building your own server or wiring MCP into an automated job that runs without you. If you are connecting Claude to tools you already pay for, you will never need it.

1. Open the desktop app settings and find the connectors section.
2. Add the connector for the system you want, then complete the sign-in it prompts for. You are authorising it against your own account, with your own permissions.
3. Ask a small read-only question first, such as finding one recent document, so you can see it reach the system and come back.
4. Approve the tool call when the app asks. Read what it says it is about to do before you approve it, especially the first few times.

Which connectors are worth adding first?

Start with the system you copy out of most often. That is the whole selection rule. Not the most impressive integration, not the one with the best demo - the one whose data you keep pasting into a chat window by hand. Every business has one, and it is usually obvious the moment you look at your week honestly.

If your first connector is a document store, it doubles as the fastest route to a working internal knowledge layer. [How to build an AI knowledge base](/blog/how-to-build-an-ai-knowledge-base) covers how to organise what it will be reading, which matters more than the connector itself. A tidy folder answers well. A dumping ground answers badly, connector or not.

What is the Read-Write Line?

The Read-Write Line is our rule for deciding what a connector is allowed to change. You write two lists before you add anything: systems Claude may read, and systems Claude may write to. The read list can be generous. The write list should be short enough to say out loud, and everything on it should be somewhere a mistake is visible and reversible.

1. Read side: documents, tickets, records, project state, analytics. A wrong read produces a wrong answer, and you will notice a wrong answer.
2. Write side, acceptable: drafts, comments, internal notes, a row in a staging sheet, a task in a list a human reviews. A mistake here sits there looking wrong until somebody fixes it.
3. Write side, not acceptable: anything that sends to a customer, moves money, changes a price, deletes records, or publishes. These stay on your side of the line permanently, not until you trust it more.

The reason the line is drawn at visibility rather than importance is that Claude will occasionally be confidently wrong, and the only question that matters is whether you find out. A wrong draft is caught by the person who sends it. A wrong email is caught by the customer who received it. Same error, completely different cost, and the difference is entirely in where you drew the line.

How does this change day-to-day work?

The change is that context stops being something you assemble. Today you decide what Claude needs to know, go and find it, paste it in, and hope you did not leave out the part that mattered. With connectors, you ask the question and it goes and gets the context itself, including the parts you would not have thought to include.

The second-order effect is the one people underestimate. When context is free, you ask smaller questions. Rather than one big weekly analysis, you ask five specific things across the day, because asking now costs nothing. That is a different working relationship with the tool, and it is worth setting up one connector properly to find out whether it fits how you work.

What are the real risks of connecting Claude to live systems?

The risk that deserves your attention is instructions hiding inside the content Claude reads. If a connector pulls in a document, a ticket, or a web page, and that text contains something written to look like an instruction, the assistant may treat it as one. This is a known and unsolved class of problem across every AI system that reads untrusted content, and it is exactly why the Read-Write Line exists.

• Content you do not control is the dangerous input: inbound support tickets, forwarded email, shared documents, anything fetched from the open web.
• The damage requires write access to be real. Reading a poisoned document produces a bad answer. Reading it with permission to send email produces an incident.
• Approve tool calls consciously in the first weeks rather than clicking through. The prompt tells you what it is about to do, and reading it is the cheapest control you have.
• Only add connectors from sources you would trust with the underlying account credentials, because functionally that is what you are doing.
• Remember that a connector inherits your permissions in that system. If your account can see everything, so can it.

None of this is an argument against connecting. It is an argument for connecting deliberately, with reads open and writes narrow. [How to keep business data safe when using AI](/blog/how-to-keep-business-data-safe-when-using-ai) covers the broader question of what should be in reach of an AI tool at all, and it is worth settling that before you add a connector to anything holding customer data.

Local server or remote server?

Remote for the software you already pay for, local for your own machine and your own data. A remote server is hosted by the tool vendor and you connect to it by signing in. A local server runs on your computer and reaches things only your computer can see, such as a folder on disk or a database on your network.

When no connector exists for something you depend on, writing a small one yourself is a genuine option and no longer an exotic one. The protocol is deliberately simple. [How to use Claude Code for your business](/blog/how-to-use-claude-code-for-your-business) covers the desktop-first way to do that kind of build without becoming a full-time developer about it.

How do I test a new connector in the first week?

Test it against answers you already know. The failure mode of a connected assistant is not that it refuses - it is that it answers confidently from an incomplete read, and you cannot tell the difference from a correct answer unless you knew the answer beforehand.

1. Ask five questions you can verify yourself in under a minute. Not interesting questions - checkable ones.
2. Ask something the connector should not be able to answer, and confirm it says so rather than inventing a plausible response.
3. Ask the same question two days running to see whether it is reading current state or something cached.
4. Check the scope it received when you signed in. If it asked for more than it needs, that is worth knowing on day one rather than at an audit.
5. Write down, in one line, what this connector is for. If you cannot, remove it. Unused connectors are risk without return.

Confident wrong answers are the failure to design around, and connectors change their shape rather than removing them. [How to stop AI hallucinations in your business](/blog/how-to-stop-ai-hallucinations-in-your-business) covers the verification habits that keep a connected assistant honest once it is reading real records.

When should I use a connector instead of an automation platform?

Use a connector when a person is asking. Use an automation platform when nobody is. That single distinction resolves most of the confusion, and it saves people from rebuilding scheduled workflows they already had working.

• Connector: you are in a conversation, the question varies each time, and judgment is being applied by you as you read the answer.
• Automation platform: the same steps run on a trigger or a schedule, the same way, with nobody watching. That is a job for n8n, Zapier, or Make, not for a chat window.
• Both: increasingly common. The scheduled job assembles and delivers, and you use a connector to interrogate the result when something looks odd.

If your need is really the second one, start there instead. [How to connect your apps with automation](/blog/how-to-connect-your-apps-with-automation) covers the unattended side properly, and a connector added to solve a scheduling problem will quietly disappoint you.

Start with one read-only connector this week

Pick the system you paste out of most, add its connector in the desktop app, keep it read-only, and use it for a week on questions you can verify. That is the entire first step. Do not connect five things, do not grant write access to anything, and do not open a terminal. You are testing one thing: whether removing the copy-and-paste tax changes how often you actually reach for the tool.