How to connect company data to Claude and other AI clients over MCP

Connecting takes a few minutes: paste an address, sign in, approve. Then you ask the assistant about open jobs and get an answer from current data.

In those few minutes you also make a decision nobody prompts you to think about: whose account the model acts on. This piece assumes you know what MCP is and starts from that decision.

The three sides of one connection#

The system exposes a server. The vendor of your system — job database, CRM, stock — publishes an MCP server: an address at which that system's operations are described. You do not build it — it either exists or not, and that is a question for the vendor before you buy.

The client adds the connection. The client is the AI application: Claude Desktop, Claude Code, any other tool that speaks MCP. You give it the server address and sign in: a redirect, a consent screen, a return, much like connecting an app through a Google account.

The model receives a list. The client pulls from the server a list of tools (operations to call) and resources (data to read). Every tool carries a name, a description and a parameter schema — what it expects as input. The list goes to the model as part of the conversation's context.

That last part matters: the model is not given database access, but a list of operations it can ask to have called.

What happens when you ask a question#

You ask how many open jobs a particular customer has.

The model picks the tool that looks right — a job search, say — and asks the client to call it with parameters. The client makes that call with the signed-in user's credentials, the server returns data, the model turns it into an answer.

The client makes the call, not the model. It sounds like a formality, and it is where every safeguard lives: the client knows who is signed in, and it asks for approval when required.

Returned data stays in the conversation. The server's response enters the context and stays there for the rest of the thread. Pull five hundred records to count one, and five hundred records sit in the thread — hence the case for tools that filter and count on the system's side.

What the model can and cannot do#

It can read. Fetch a record, a list, a document — if the server exposed a tool for it.

It can search. "Find this customer's jobs from last quarter" runs as a search inside the system, not a walk through everything.

It can write, if the server allows it. Create a job, change a status, add a comment. Sensible rollouts separate reads from writes and require confirmation on anything that changes data — see human approval for AI actions.

What it will not do:

Reach past the exposed tools. An operation the server did not publish does not exist for the model.

Step around the account's permissions. If the account cannot see payroll, a model asking on its behalf cannot either.

Remember previous conversations by itself. The connection holds no state between threads — each one starts again from the same list of tools.

Whose account the connection runs on#

The most important question when connecting, and the least asked — the configuration screen never raises it.

The protocol constrains nothing on its own: a connection's permissions are those of the account whose credentials were used. Two scenarios follow.

A service account. One broadly privileged account, set up once by an administrator and shared by everyone on the connection. Simpler, therefore more common. Share it with ten people and ten people hold that account's permissions, whatever each sees when signing in by hand.

The signed-in person's account. Everyone connects with their own credentials and the model operates strictly inside their access. A salesperson asking about salaries gets what they would get by opening the system by hand: nothing.

How many systems to connect at the start#

The temptation after one working connection is obvious: add mail, the calendar, the document drive. On a first rollout, resist it.

When answers start drifting from what you expected — and they will — one connected system tells you where to look. Four do not, and the model becomes the first suspect though it is rarely the culprit. What degrades as the tool list grows is covered separately in when AI has too many tools.

At this stage two questions are enough. For your AI client vendor: can you keep several connections without the model getting every tool at once. For your system vendor: can the tools exposed to one connection be narrowed.

The checklist before you connect production#

Whose permissions. First question and the decisive one. "A service account with full access" means your system's safeguards stop applying inside a conversation with a model.

Whether read-only is an option. A first week without writes shows data quality faster than any audit.

Which operations need approval. And whether you set that or the vendor does.

Where you will look afterwards. A call log should show who, when and which tool. Open it during your own test, not when it is finally needed.

Disconnect once as a drill. Check how long cutting a connection takes and whether the active ones are even listed — not a procedure to learn in a hurry.

Who may connect anything. With no rule, an employee with system access will wire it into a personal AI client on a Friday afternoon, in good faith. A separate question is where that data goes on the model vendor's side.

What you test against. A copy of the data or a walled-off area, not live customer jobs.

Summary#

Connecting a system to an AI client is short: the server exposes tools, the client adds them, the model receives the list and can ask for calls. Everything else comes down to which account it runs on, because the protocol restricts nothing by itself. Start with reads, check the log, decide who may connect anything, and only then let writes through.

The wider context is in the guide on connecting AI to company data.