MCP servers that let Claude reach your systems without reaching past your permissions.
Pexon builds MCP servers that give Claude access to internal systems: SAP modules, document management, ticket queues and databases. Each server exposes a named tool list, authenticates the end user rather than a service account, and carries the source system's own permissions through, so a request returns only what that person could already read.
The starting point
The pilot answers beautifully, from nothing you own.
It reads what a person pastes in and what is on the public web, and it is genuinely useful for about a fortnight. Then someone asks it about a contract, a ticket, a batch record or a part revision, and the honest answer is that the system holding it was never connected. Every proposal to connect it arrives as a request to open a service account, and that is the point where a security review stops the project.
An MCP server is not an integration. It is a permission boundary with a tool list attached, and the tool list is the easy half.
What we build
What the server consists of
01
A named tool list, not a database connection
The server publishes a small set of explicit operations — search the contract archive, fetch this ticket, run this named report — each with a typed input and a documented result. Claude can call those and nothing else. A tool list is reviewable by someone who does not read code, which is what makes it the artefact a security team signs rather than argues with.
- Model Context Protocol
- typed tool schema
- no ad-hoc SQL
02
The end user's identity, carried through
The server authenticates the person asking, not itself. Their token is exchanged for the source system's own authorisation, so a query returns exactly what that person could already open and nothing their role does not cover. Where the source system cannot express per-user access — some older modules genuinely cannot — we scope the server to the subset that can be shared, and say which subset that is before the build.
- OAuth 2.1
- Entra ID
- per-user scoping
03
The parts that make it survivable
Audit logging of every tool call with the identity attached, rate and cost limits per workload, a test suite that runs the tool list against a fixture of your data, and a runbook. It is your code in your repository, deployed into your environment, so the integration outlives both the pilot team and us.
- audit log
- eval fixtures
- runbook
- your repository
Before you brief anyone
Which of these is your system?
The question that decides the work
Does the system you want Claude to reach already speak the protocol, and can it tell you who is asking?
- The vendor ships an MCP server
- Use theirs. A growing number of SaaS products now publish one, and a vendor-maintained server is a dependency you do not have to keep alive through their next release. Bring us in only if the permission model does not survive contact with your directory.
- It has a modern API and a real identity model
- This is the straightforward build. A server in front of the existing API, tools scoped to the operations you actually want exposed, user identity exchanged at the boundary. Weeks, not quarters, and the tool list is agreed before anything is written.
- It is old, proprietary, or has no API worth the name
- Still reachable, and this is where most industrial systems sit. Custom tools against whatever interface exists — an RFC, a database view, a SOAP endpoint, a nightly export — presented to Claude as the same named tool list. The protocol is the shape at the top; it is not a requirement of the system underneath.
What changes
- A question about a contract, a ticket or a part revision is answered from the system of record instead of from whatever someone remembered to paste in.
- The security review is about a list of named operations rather than about a service account with broad read access.
- Revoking one person's access in your directory revokes what the assistant will answer for them, without a change to the server.
- Every tool call is attributable to a person and a workload in a log your team already reads.
- The next system takes a fraction of the effort, because the identity and audit work is done once and reused.
Start with the Readiness Blueprint.
Two weeks, €4,900 fixed price: we take one system, agree the tool list with the people who own it, test whether the identity model can be carried through, and hand back a costed build plan. It is yours to keep, whoever builds it. All prices are net and exclude VAT.
Questions about MCP integration
What is an MCP server, in one paragraph?
The Model Context Protocol is an open standard for connecting an assistant to a system. An MCP server is a small service you run that publishes a list of named tools — search_contracts, get_ticket, run_report — and executes them against one of your systems when Claude calls them. The point of the standard is that the same server works with any client that speaks it, so the integration is not tied to one vendor's product.
Does an MCP server mean Claude can read everything in the system?
It should not, and that is most of the engineering. A server built to authenticate a service account will happily return anything that account can reach, which is how a retrieval pilot fails its security review. We build servers that carry the end user's identity through to the source system, so the answer is bounded by what that person could already open. Where a system cannot express that, we say so before the build rather than after.
Our system has no MCP server and no modern API. Is it out of scope?
No, and that is the common case. Older SAP modules, home-grown CRMs and proprietary line-of-business applications rarely have either. Those are reached with custom tool definitions against whatever interface does exist — a SOAP endpoint, a database view, a file drop, an RFC — wrapped so Claude sees the same named tool list it would see from any other server. The protocol is the shape at the top, not a requirement of the system underneath.
What does an MCP integration cost?
The two-week Readiness Blueprint is fixed at €4,900 and returns the tool list, the identity model and a costed build plan for the first server. Build work is scoped from that plan; a first production server is typically a use-case pilot from €15,000. Model consumption is billed to you by Anthropic or your cloud provider at their published rates — we do not resell tokens. All prices are net and exclude VAT.
Who runs the server afterwards?
You do, unless you would rather not. It is your code in your repository, deployed into your own environment, and the handover includes the tool definitions, the tests and the runbook. If you want us to keep operating it, monitoring and on-call start at €3,000 per month.
Next step
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.