An MCP server is a small thing: a bridge between Claude and one system your company already runs. Accounting, the CRM, the shared drive, mail. The first question in most meetings is not what MCP is. It is how many of these servers we will need. The honest answer is usually two or three, not twenty.
The work nobody wants
Monday morning. The owner wants three things: how much was invoiced last week, what is overdue, and what happened to the big quote from March. Three questions, three systems. Someone opens the accounting software, someone opens the CRM, someone digs through mail for an attachment a colleague sent a month ago.
None of it is hard. It just takes time, and it keeps coming back. Twenty minutes here, twenty minutes there, five times a week, across five people. The work never shows up in a report because it is scattered. It is still one of the most expensive parts of the week, because the people doing it were hired to do something else.
Three systems, four logins, one question.
— A Monday morning, abridged
What an MCP server actually does
MCP, the Model Context Protocol, is an open standard Anthropic published at the end of 2024. It describes how Claude and a system exchange data and which operations Claude is allowed to run against that system. Because it is a standard, a connection stops being a private invention that one person in the company understands.
The server itself is small. It has no opinions, keeps no copy of your data and pushes nothing into anyone elses database. It exposes a handful of specific operations over one system: find an invoice, list what is unpaid, read a customer record, prepare a draft. And it runs them under the identity of the person asking. If a salesperson cannot see payroll, Claude cannot see payroll while that salesperson is the one asking.
So how many to start with
The recommendation we give in the first meeting: start with two, three at the most. Not for budget reasons. Before the third bridge you are still guessing what people will ask most often. After the third one you know, and the next bridges get picked by the work rather than by a slide.
- Where the money sits: invoices, payments, overdue balances. Cash questions come up daily and have one correct answer.
- Where the customers sit: the CRM, the history of a deal, open quotes. That is where the most people ask, and where they ask the same thing twice.
- Where the context sits: the shared drive and mail, contracts, notes, the attachment nobody can find.
- One write path, not twenty: a single operation that creates something (an invoice draft, a note on a deal), so the saving covers writing too, not only searching.
The rest can wait. Not out of caution, but because operations will write the list for you. A few weeks in, the questions people actually ask make it obvious whether the next bridge is the e-shop, the time sheets or the ad accounts. That list tends to be shorter than it looked at the start.
Concretely: accounting, the CRM and the shared drive
The systems stay where they are. A company that invoices in Pohoda, runs sales in a CRM and keeps its documents on a shared drive changes none of that and migrates nothing. Two or three bridges get added, and Claude asks them the same things a person would ask by clicking. The scope of a first bridge is usually a handful of operations, not hundreds.
A twelve-person construction company might use it like this: on Monday, which invoices are more than two weeks overdue and which jobs they belong to; on Wednesday, whether anyone has replied on the quote that has been sitting since March; on Friday, how many hours were logged on the three biggest jobs. Three questions, three bridges, no new logins. The example is illustrative. Every company puts its own numbers in.
What MCP servers will not do, and why that is good
They will not pay anything. They will not send an invoice to a client. They will not change a price in a quote or sign a contract. The bridge prepares, a person approves. This is not a temporary restriction we relax in six months.
The reason is practical. The moment a system can move money without a person, you need a control apparatus around it that costs more than the work you were trying to save. A boundary at reading and drafting is cheap, easy to explain and easy to audit. That is why it can be in place in weeks rather than a year.
What it would take
A short call, and an hour spent on what people in your company ask most often. The first bridge falls out of that conversation. It runs on your infrastructure, in your tenant, under your identity, with an audit trail you read, not us. If the second bridge does not earn its place, we will not build it.
What is left
The model is not the bottleneck. Claude can read an invoice, summarise a meeting and draft a brief. The bottleneck is the distance between Claude and the data your company already has. Bridges close that distance, and at the start you need fewer of them than it looks.
Write to us. A short call is enough to pick the first two bridges together and say what they would cost and how long they would take. If the answer turns out to be one bridge, we will say that too.