When someone searches for what an MCP server is, there is usually a more concrete question behind it: how do we get company mail, calendar and documents to Claude without creating a security problem. An MCP server is the answer. It is a small program that sits between Claude and one system, speaks both ways, and carries the identity of the person doing the asking.
The work nobody wants
In a twenty-person company, answering a simple question often takes half an hour of searching. When did we send that client the last quote? Who on the team spoke to them most recently? What did we promise at the March meeting? The answer exists. It is just spread across Outlook, a shared SharePoint folder and two threads in Teams.
Nobody logs that time. It is not a meeting and not a project, it is looking for things. Yet across a whole team it adds up enough that you only notice when the person who "knows where it is" goes on holiday. Then the search takes twice as long and the reply goes out a day late.
I am sure we saved it somewhere. I have no idea where.
— Thursday afternoon, any of them
What an MCP server actually does
MCP (Model Context Protocol) is an open standard Anthropic published in late 2024. It solves one plain problem: how a model can reach into a system it does not know, without a new one-off integration for every pairing of tool and model. An MCP server is the concrete piece of that standard. One system, one server.
Over Microsoft 365, that server talks to Microsoft Graph, the single interface through which Microsoft exposes mail, calendar, files, contacts and people. The mechanics matter less than the question of whose name the request carries. Graph distinguishes access on behalf of an application from access on behalf of a signed-in user. We build the second kind, so every request carries one person"s name and one person"s permission scope all the way down.
Concretely: Microsoft 365
Nothing changes inside Microsoft. Nobody migrates anything, no company content is indexed into an outside cache, no second copy of your data appears. What gets added is one server running in your environment, with an application registered in your own tenant and a permission list that fits on half a page. We usually build it for one department first and widen it later.
- Finds the last thread with a given client in Outlook and pulls out what was agreed and what is still open.
- Reads the calendar and prepares a pre-meeting brief: who is coming, when you last met, what happened since.
- Opens the latest version of the quote on SharePoint and compares it with what was written in mail since.
- Drafts the reply and attaches links to the exact messages and files it drew from.
- Writes the meeting notes straight into the project folder as a draft for someone to confirm.
An illustrative example: a twelve-person Czech agency with clients in Outlook, contracts on SharePoint and notes in Teams could put this on a single role first. One person asks one question in the morning instead of opening six windows. The rest of the company watches for two weeks and then asks for the same thing.
What an MCP server over Microsoft 365 will not do, and why that is good
It will not send mail for you. It will not quietly rewrite a document somebody is working on. It will not change who a file is shared with. And it will not reach into a mailbox the signed-in person cannot open themselves, because Microsoft Graph simply will not return it.
That boundary is not a limitation, it is the whole reason the pattern is trustworthy. A system allowed to do everything has to be watched on every request. A system allowed exactly as much as the person at the keyboard is set up once, at the permission level, and after that you only read the audit log.
What it would take
Not a year-long programme. The first version is usually a matter of days: an application registered in your tenant, a short list of the permissions genuinely needed, a server running on your own infrastructure, and an audit trail from the first request onwards. Then one department, two weeks of real use, and a decision about what to connect next. Accounting in Pohoda, the CRM and the e-shop are usually next in line, and the bridge is built the same way.
What is left
The model is not the bottleneck. Claude handles your mail and your documents fine. The bottleneck is the distance between it and the data your company already has, and that distance is exactly what we build across: small, dull, well-bounded bridges that carry a person"s identity all the way to the end.
If you want to see what that bridge would look like in your company, write to us. A short call is usually enough to pick the first system and agree what a first version could do within two weeks.